This is a set of Smart Contracts on Ethereum. Reason to use is the ability to programatically (mathematically) ensure the outcomes of important interaction, such as:
- payment with conditions, such as acknowledge, locking, escrow and another examples of what is possible to automate money agreements.
A. Payment with condition: a) payer informs the payee, receives an acknowledgement, and confirms/releases the payment
I. Players:
- Originator - payer
- Destination - payee
- Proxy - business logic of the transaction, smart contract
II. Amount:
- Amount which Originator would like to send to Destination, using Proxy
III. Steps:
- Alice and Bob download the app from AppStore/Google Play, and fund it with Ether/ERC20/any other digital asset on Ethereum blockchain.
- Originator sends Amount to Proxy, specifying destination and timeout (Alice sends 1 ETH to Bob via Proxy, specifying timeout to 24h)
- Destination app receives a notification that payment was initiated, acknowledges the payment (see 2a to see alternative)
- Originator receives notification that payment was accepted, and has a choice to:
- Originator releases the funds
- Destinatior receives funds
or
- Originator rejects the payment
- Destination receives notification that payment was rejected
or
- In case if Destination has not acknowledged the payment before the timeout, funds are returned to the Originator
This use case is built on concepts of PullPayment introduced by OpenZeppelin.
B. Time lock
I. Players:
- Originator - payer
- Proxy - business logic of the transaction, smart contract
II. Amount:
- Amount which Originator would like to lock, using Proxy
III. Steps:
- Originator sends Amount to Proxy, specifying the locking time (Alice locks 1 ETH via Proxy, specifying time to lock: 1 month)
- After 1 month, funds are released back to the Originator
- Originator pulls the funds
C. Payment with confirmation: a) payer informs the payee, receives an acknowledgement, and confirms/releases the payment
The difference comparing to scenario A is that here multisig approach is used. Initially senders issues a payment, which requires extra signature (mimicking multisig approach). The main issue here is how to make sure that receiver is still the person who was intended to be paid. It could be mitigated by creting an address of smart contract by the receiver, as one of the options.
Smart contracts are heavily influenced by OpenZeppelin work which focuses on community standards driven source code in Solidity. In addition, transparency of Ethereum Blockchain is adding audiatibility of all the steps.
"If I had asked people what they wanted, they would have said faster horses" (H.Ford)
Probably instead of focusing how to make better (faster) payment mechanism (strong competitors, such as Visa and Mastercard), it is wiser to create scenarios which were not possible before, such as trivially easy to use smart contracts for non trivial use cases - such as escrow, pre-paid and other small (but important) payment related scenarios
Code released under the MIT License