Payment Streaming Whitepaper
Payment streaming is one of key sub-graphs of the Mean Protocol
Payment streaming represents the idea of continuous payments over time. Block numbers are used to measure time in the blockchain and continuously update the balances of the parties in the contract.
When a payment is made to a payee in exchange for time (i.e., employment), an implicit debt obligation is established from the payer to the payee, which is (a) non-mutual, (b) carries 0% interest, and (c) financially favors the payer, in detriment of the payee.
The macroeconomic consequences of this status-quo in society are grossly misrepresented, and many attempts have been made to fix the issue.
The following describes a protocol whereby time is measured using block numbers, and the agreed-upon payment rate is streamed continuously to the recipient. The contractual terms are enforced by the Payment Streaming Protocol (PSP). The reference implementation for the MSP is made in Solana Blockchain due to its many benefits and, in particular, thanks to its ~400ms block times (a 3,000% improvement over Ethereum’s).
- 1.A user creates a Payment Stream by calling the MSP. We’ll refer to this user as the treasurer.
- 2.The Payment Stream is set up with specific conditions such as vesting schedule, rate, cliff, start time, and beneficiary, among other setup options.
- 3.One or more contributors can fund the Payment Stream with money (SPL Tokens).
- 4.Once the Payment Stream starts, the beneficiary can withdraw money from it based on its current solvency.
- 5.The amount of money available for withdrawal is updated in near-real-time (at every block height, or ~400ms in Solana). That is:
rate * (current_block_height - starting_block_height) - 6.The Payment Stream terms can be updated at any time and require the signatures of both the treasurer and the beneficiary to commit the update.
- 7.The Payment Stream can be closed by either the treasurer or the beneficiary unilaterally and without consensus.
- 8.In the event of closure of the Payment Stream, the MSP distributes any unvested funds back to the original contributors and all vested funds to the beneficiary automatically.
Payment streaming is beneficial in scenarios where money obligations are defined as a direct function of time in discrete terms. A job ($20/hour) or a pension plan ($1000/month from retirement and until death) are typical examples where money distributions are agreed upon as a function of time.
These types of time-based money contracts are common and stand in contrast to other scenarios where money is NOT a direct function of time, such as a clothing store ($25 for a pair of jeans). In these cases, the payment streaming utility is limited or not existing at all.
An alternative of one-time payments that works great for services received, such as handyman work, or to set up gifts over time.
Allocate funds regularly to help family members abroad and let them decide when they need to use them. Child allowances for college expenses also fit this use case well.
Pay only for the time you are occupying a parking spot.
SaaS subscriptions for products or services (i.e., Netflix, Cellular Service, etc.)
Pay your employees from the company treasury. Remove all payroll nightmares. Employees get paid by the second.
Retirement distributions from retirement age until death.
Employee Restricted Stock Unit benefit plans are commonly seen in tech companies in silicon valley.
Fundraising for a company or a project. Founders can give investors peace of mind proving they will not run away with the money unless they meet their milestones.
Pay Rent / Collect Rent without being bound to monthly installments. This also applies to hotels, motels, hostels where they can charge by the minute, etc.
Manage the escrow payments and distributions in a real estate sale transaction.
NGOs and Nonprofits can set up a stream that allocates the funds little by little and allow anyone worldwide to contribute to the stream.
Distributions to heirs over time to guarantee continuous access to the funds previously owned by the deceased over time.
Tax payments are received by governments and get distributed to serve different public services, such as Schools, Firefighters, Police, etc. Current systems to distribute collected tax funds require a significant amount of overhead and a lack of transparency in the process. A Payment Streaming Contract where multiple beneficiaries (School District, Firefighter Dept, etc.) are set up to receive a percentage of the stream automatically creates a great deal of automation and transparency in the tax distribution and benefits system.
There are two types of Streaming Accounts: Open or Locked.
With an open streaming account, you can create payment streams that run indefinitely (no end date). When the treasury runs out of money all streams stop running until it gets replenished. After replenishing the treasury, all paused payment streams can resume their operation.
With a locked treasury you can create streams that act like a vesting contract for reserved allocations, like the ones needed for investors. These payment streams usually have a fixed end date and may or may not guarantee funds through the use of Reserved Allocations.
Reserving an allocation from a Locked Streaming Account into a specific payment stream means the beneficiary becomes the OWNER of the allocation immediately. The owner is simply locked from accessing these funds as specified by the rate and frequency of the money stream. This is useful for investors or any kind of pre-paid contracts since the beneficiary has already paid for their tokens, and the intent is to delay their distribution.
This stands in contrast with Open Streaming Accounts, like those for Payroll, where work needs to be completed to EARN that allocation. The beneficiary is not the OWNER of their allocated tokens until they vest in the payment stream.
The payment streaming program specification defines how the different players, actors, and components interact with each other. The Solana Blockchain is used as a reference implementation, but the same concepts can be applied to other chains, such as Avalanche and Ethereum.
The basic premise of a payment streaming smart contract is that once it gets executed between a treasurer (sender) and a beneficiary (recipient), its terms are enforced by code instead of humans. The treasurer cannot run away with the money owed to the beneficiary, and the beneficiary cannot take the money he/she has not yet earned.
In order to stream money from A→B at a specific rate/flow over time, the following participants are defined.
- 1.Payment Streaming Program (PSP): A program deployed to a permissionless blockchain that uses this protocol as a reference implementation.
- 2.Treasury Account: An account (wallet address) used to escrow the money being streamed. This account is under the sole custody/ownership of the MSP Program.
- 3.Treasurer: The person creating a Treasury Account.
- 4.Contributor: Any person contributing money to the Treasury Account.
- 5.Beneficiary: A person who can receive money from a Treasury Account.
- 6.Payment Stream Terms: A set of terms and an amount of money, expressed as a rate over time, that should be streamed to a beneficiary from the Treasury Account.
- 7.Payment Stream: An account maintained by the MSP, and keeping state with terms, vested and unvested amounts for a Beneficiary.
A money stream is a finite-state-machine (FSM) with the following states and transitions:
Mean Money Stream States
Current State | Input | Next State | Output |
Scheduled | Pause CTA | Paused | Stops the money from streaming to the beneficiary. This is reversible. |
Scheduled | Planned time arrived | Running | Starts streaming money from the treasury to the beneficiary. |
Running | Treasurer or Beneficiary manually stops the stream | Paused | The Stream is paused, and money stops flowing to the beneficiary. |
Running | Treasury ran out of money | Paused | Since there is no money to stream, the stream is stopped, and the beneficiary does not get any more money. This is reversible if the treasury is reloaded. |
Paused | Treasury reloaded with money | Running | Resumes streaming money from the treasury to the beneficiary. |
The Money Stream can be closed by either the treasurer or the beneficiary unilaterally and without consensus. Closing a stream will result in all the vested amounts being distributed to the beneficiary and the unvested amounts and any rent returned to the treasury.
ERC-1620 is a protocol specification on Ethereum defining a standard for money streaming with similar motivations to those expressed here. The MSP builds upon this work to make a general-purpose protocol that can serve all time-bounded contracts, with or without a present end-date and upfront locks. The specification for ERC-1620 is here: https://eips.ethereum.org/EIPS/eip-1620
EIP-2100 is an improvement proposal expanding some of the concepts introduced in ERC-1620 by adding options related to the settlement of the funds in the stream. The proposal for EIP-2100 is here: https://github.com/ethereum/EIPs/issues/2100
Sablier Finance (https://sablier.finance/) is an implementation of ERC1620. The protocol focuses on the payroll use case and enforces a start and end time of the stream, which is a limitation to those use cases where the end date is unknown (such as a pension fund). Sablier was launched in 2019, in less than 12 months, had a Total Value Locked (TVL) of over $1M, and by Jan 2021, TVL was over $100M, showing the extreme demand for this money building block.
Circle’s CEO comments on streaming payments: https://www.pymnts.com/news/payment-methods/2021/circle-ceo-programmable-money-ushers-in-era-of-continuous-streaming-payments/
Hourly employees usually require to get paid by the exact number of hours or minutes they work. The process works like this:
- 1.Employer and employee agree on an hourly rate (i.e., $20/h)
- 2.The employer gives the employee a way to clock in and clock out, like a physical clocking card at a factory.
- 3.At the end of the month, the employer inspects the hours reported by the employee and pays him accordingly.
To support this use case with the Streaming Contract, we would need to:
- 1.Allow the treasurer to configure an auto_pause_in_seconds parameter on creation, such that he/she can set this value to something like 8 hours, assuming the factory shifts are at most that long.
- 2.Allow the beneficiary to ResumeStream to signal the contract that he/she is indeed “on the clock”, and therefore should be making money.
- 3.Allow the beneficiary to PauseStream to signal the contract that he/she is “off the clock”, and therefore should NOT be making money.
- 1.This API should also be allowed for the treasurer, to allow for overrides, in case a worker forgets to clock out or clock in.
The biggest challenge with these conditional on/off clock triggers is the timekeeping shenanigans calculating the escrow_vested_amount, and the formula to calculate this field already accounts for this.
Problem: Consider the following case.
- 1.A treasury is setup by treasurer John with one beneficiary Alice
- 2.John adds a stream guaranteeing Alice and pay rate of 1000/month
- 3.John then talks to contributors Bob and Jane to fund Alice’s operation through the treasury. Bob and Jane like Alice’s project and agree to fund the treasury with $1,000,000, knowing that Alice can only take $1,000/month, they feel they are giving the project long-term stability.
- 4.Now John goes rogue and secretly decides to add his accomplice Pepe as another beneficiary to the treasury, without asking Bob and Jane.
- 5.John sets up Pepe with a rate of $999,000 per minute.
- 6.The results next morning are catastrophic:
- 1.John is kaput, nowhere to be found.
- 2.Alice wakes up to an empty Treasury, and her project is toast.
- 3.Bob and Jane lost $1,000,000 and have no project to backup.
- 7.This is a classic rug pull.
Solution: Always force the treasurer to be a multi-sign wallet account address, and require a super-majority vote to add beneficiaries to a treasury.
- 1.Multi-sig treasury account OR treasurer = (no less than three addresses)
- 2.Super-majority votes required on certain operations (such as adding beneficiaries)
is_streaming = current_block_height >stream_resumed_block_height+ auto_pause_in_seconds/1000
Last modified 1yr ago