API payment protocol

Assumptions

Possible protocol

Service discovery

Unfunded anonymous access

Establishing funding

API usage

Channel management

Channel operation

  1. The wallet creates a non-final prefunding transaction.
  2. The service runs a spent balance ideally less than or equal to the current prefunding.
  3. Each request from the wallet is accounted to the spent balance and a receipt returned in the response. If there are insufficient funds to complete the request, it may incur a 402 response or interrupt any streamed data.
  4. When the wallet wishes to finalise the prefunding transaction, it does so through an API on the hosting service.
  5. If the last prefunding transaction is finalised, the wallet needs to create a new one. This will ideally happen before the previous funding is completely spent to avoid 402 or more ambiguous interrupted responses.

More bits and pieces

Multiple balances?

Service discovery

Final thoughts

--

--

--

ElectrumSV developer

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The Monero Moon (Issue 9)

What is Algorand?

TGE SQT token is coming!

What Bitcoin’s dominance says about the state of the crypto market

Who bought CryptoPunk NFT #4156 for $10 million in Ethereum

Who bought CryptoPunk NFT #4156 for $10 million in Ethereum

GPUSKIN News — Hashrates Explained #Eth #Ethereum #Mining #GPU #Hashrates

Bitcoin mining energy consumption

Bitcoin mining energy consumption

Flowty Primer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Roger Taylor

Roger Taylor

ElectrumSV developer

More from Medium

Web3.js Explained!

Vite Runner Hackathon

Smart contract deployment on Hashgraph using JavaScript SDK

Using Neo for local blockchain development