A while ago, we introduced StarkPay, StarkWare’s prepaid-debit-card-style payment system. This post will describe our improved design and functionality supporting Instant Payments. With this functionality, a merchant such as Starbucks could offer a customer a cup of coffee instantly, knowing they are guaranteed to be paid in short order.
Introducing Instant Payments
Instant Payments is an improvement to StarkPay which offers merchants finality on receivables (i.e. payments received) at Lightning speed. There are no trust assumptions between any of the parties involved in a payment’s life cycle: customer, merchant, payment processor, and StarkWare which runs the StarkPay on behalf of the payment processor. Instead of trust, the payment processor offers the merchant a dedicated on-chain security deposit (roughly equal in value to the sum total of the merchant’s receivables during a proof cycle), and counter-signs customer payments. For counter-signed payments, the merchant is assured to receive the funds — either via the payment’s inclusion in a subsequent proof or by redeeming the payments directly from the security deposit. Much like a standard security deposit, in the normal course of affairs, it is left untouched.
For every merchant offered the Instant Payments system, the payment processor locks up a security deposit in a merchant-specific on-chain smart contract. As mentioned above, the deposit is roughly equal to the volume of payments to the merchant during a proof cycle.
Customer Interaction: a customer walks into a jewelry store wishing to buy an expensive item
- Customer provides merchant with a signed payment.
- Merchant verifies there are sufficient funds in the security deposit contract.
- Merchant forwards payment to payment processor.
- Payment processor checks customer has sufficient funds.
- Payment processor counter-signs payment and returns it to merchant.
- Merchant can serve customer instantly once it receives the counter-signature from payment processor.
Post Customer Interaction
- Standard Process: In the normal course of affairs, the merchant monitors the blockchain till it sees a proof that includes the customer’s payment. This means that the merchant’s off-chain balance was credited with this customer’s payment (alongside any other payments made to the merchant in this most recent proof cycle).
- Security Deposit Activation: If the merchant doesn’t see a proof including the payment within some reasonable timeframe, the merchant can send the counter-signed payment to their security deposit contract. The contract, after verifying that enough time has elapsed and that the merchant has yet to receive payment, pays the merchant.
Black Friday scenario: a merchant may experience activity that exceeds the value stored in their security deposit. In that case, they can do one of two things:
- Require the payment processor to increase the size of the security deposit.
- Delay processing of transactions till previous transactions processed are confirmed via a proof. Obviously this doesn’t always make commercial sense: Starbucks can’t delay the delivery of a cup of coffee for an hour, but Amazon can certainly delay the shipping of a package for an hour.
A Trustless System
In our system the merchant need not trust the payment processor (and StarkWare as a technology provider for the latter), and conversely, the payment processor need not trust the merchant.
Trustless Payment Processor: the merchant can always redeem an unpaid counter-signed payment (i.e. signed by both the customer and the payment processor) by sending it to the security deposit smart contract.
Trustless Merchant: the merchant can’t redeem from the security deposit smart contract a payment accounted for in a proof submitted to the blockchain. In fact, as long as the payment processor follows the protocol, the merchant can’t withdraw funds from the security deposit at all.
Comparison to Lightning
In light of Instant Payments, we should revisit our original comparison of StarkPay to Lightning.
Faster Finality: one advantage that Lightning had over our initial StarkPay design: faster finality. In our initial design, finality was a function of “proof cycle time”. In Lightning, finality is instant, in the sense that once you have the counterparty’s signature, your payment is guaranteed. StarkPay now matches Lightning’s speed of finality.
Lower Cost of Capital: With Instant Payments, the merchant needs to secure only the value paid to them during a proof cycle — that is all that needs to be locked up by the payment processor, in order to give the merchant peace of mind. In particular, StarkPay, with Instant Payments, is still much more capital efficient than Lightning.
StarkPay is a prepaid-debit-card-style system which offers scalable, inexpensive, trustless, capital efficient, payments over Ethereum. Now, with Instant Payments, StarkPay maintains all of these properties while offering merchants the ability to provide goods and services instantly, risk-free.
In our next blog post we will describe how we intend to have our cake and eat it too, by effectively eliminating the barriers between StarkPay and the blockchain universe.
Thanks to Dan Robinson for his comments.
Tom Brand, Avihu Levy, Uri Kolodny