Money Streaming Whitepaper

Abstract
Money 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.
Introduction
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 Money Streaming Protocol (MSP). 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 Money Stream by calling the MSP. We’ll refer to this user as the treasurer.
2.The Money 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 Money Stream with money (SPL Tokens).
4.Once the Money 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 Money 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 Money Stream can be closed by either the treasurer or the beneficiary unilaterally and without consensus. 
8.In the event of closure of the Money Stream, the MSP distributes any unvested funds back to the original contributors and all vested funds to the beneficiary automatically.
Motivation
Money 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 money streaming utility is limited or not existing at all.
Use Cases
Consumer Use Cases
Simple Payments
An alternative of one-time payments that works great for services received, such as handyman work, or to set up gifts over time.
Remittances & Family Allowance 
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 For Parking
Pay only for the time you are occupying a parking spot.
Business Use Cases
Subscriptions
SaaS subscriptions for products or services (i.e., Netflix, Cellular Service, etc.) 
Payroll
Pay your employees from the company treasury. Remove all payroll nightmares. Employees get paid by the second. 
Retirement and Fundraising
Pension Plan Payments
Retirement distributions from retirement age until death. 
Company RSUs
Employee Restricted Stock Unit benefit plans are commonly seen in tech companies in silicon valley.
IPOs, ICOs, IEOs, etc.
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. 
Real Estate Use Cases
Rent Payments
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.
Real Estate Sales
Manage the escrow payments and distributions in a real estate sale transaction.
Other Use Cases
Donations
NGOs and Nonprofits can set up a stream that allocates the funds little by little and allow anyone worldwide to contribute to the stream.
Inheritance
Distributions to heirs over time to guarantee continuous access to the funds previously owned by the deceased over time.
Tax Payment Distributions
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 Money 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. 
Treasuries & Streams
There are two types of Money Streaming Treasuries: Open or Locked.
With an open treasury, you can create money 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 money 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 money streams usually have a fixed end date and may or may not guarantee funds through the use of Reserved Allocations.
Reserving an allocation from the Treasury into a specific money stream means the beneficiary becomes the OWNER of the allocation right away. The owner is simply locked from accessing these funds as specified by the rate and frequency of the money stream. This is useful, for example, for investor contracts or pre-paid contracts, since they already paid for their tokens.
This stands in contrast with Non-Reserved money streams, which simply have an allocation from the Treasury, but work needs to be completed to EARN that allocation. The beneficiary is not the OWNER of their allocated tokens until they vest in the money stream.
Money Streaming Actors
The money 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 money 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.Money Streaming Program (MSP): 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.Money 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.Money Stream: An account maintained by the MSP, and keeping state with terms, vested and unvested amounts for a Beneficiary.  
State Machine
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.
Related Works
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/ ​
Considerations
Conditional Streams
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.

The Rogue Treasurer
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