status-im
/
swarms
mirror of https://github.com/status-im/swarms.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
swarms/ideas/095-les-service-model/micropayment.md

3.4 KiB
Raw Blame History

Micropayment

Existing Solutions

Raiden

Concept
  • Off-chain solution for ERC20-compliant token transfers on Ethereum
  • Designed for many-to-many solutions
  • Transfer of tokens without global consensus
  • Previously setup on-chain deposits and balance proofs
  • Payment channels for bidirectional transfers between two participants as long as deposit isn't exceeded
  • Transfers require no fees
  • Funds can be added to existing channels
  • Blockchain isn't involved during transfers, only for channel creation and potential closing
  • As binding as on-chain due to smart contract containing tokens only accessable to both participants
  • Closing leads to payments to both participants based on balance
  • Network of channels with routing allow transfers between all peers, secured by hash-locks
  • Scaling with the number of peers
  • RESTful API
Links

µRaiden

Concept
  • Like Raiden but only between two parties: sender (client) and receiver (service provider)
  • Designed for many-to-one solutions
  • Creation of channel and settling leads to µRaiden Smart Contract and a deposit
  • Smart Contract enforces payment of deposit
  • Signing payments with balance-proofs between sender and receiver allows off-chain transactions
  • Once channel gets closed deposit is payed to receiver based on balance proofs and rest to sender
  • Typically only two on-chain transactions for opening and closing
  • If deposit of sender gets low it can increase it with an on-chain transaction
  • Own ERC20 and ERC223 compliant token
  • RESTful API
Links

SWAP

Concept
  • Swarm Accounting Protocol
  • Generic peerwise accounting
  • Long-term exchange of data chunks balanced by data chunks preferred
  • Relies on reputation system
  • Open for payment systems with issue and receive function
  • Issue results in a 3rd party proveable promise of payment
  • Issued cheques will be accumulated in cheque book
  • Only last one will be cashed in
  • Peer decides how often to cash in
  • Transactions costs motivate to minimize their number
  • Trust to peers grows with good behavior
  • SWAP^2 provides API to set triggers for automatic payments
  • SWAP^3 reduces transaction cost by debt swap
Links

API

Client

Query Conditions

Ask service provider about pricing and model (bandwidth, CPU, etc.).

Establish Business Contract

Establish a payed connection with an initial deposit.

Check Balance

Check balance of the deposit to increase fund early enough before connection potentially is dropped.

Increase Fund

Increase fund to keep connection with higher quality level. If fund is spent connection may not be dropped but changed into free connection. That may be dropped later.

Close Contract

Close contract so that used deposit is spent service provide and rest is refunded.

Service Provider

Book Token

Book a token based on provided service. If all tokens of deposit are used with a booking then close contract.

Close Contract

Close contract to retrieve used deposit and transform connection into a free connection.