〰️Token Streaming Whitepaper

An on-chain smart contract for vesting and real-time finance

Abstract

Token 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

1. non-mutual

2. carries 0% interest, and

3. financially favors the payer to the detriment of the payee.

The macroeconomic consequences of this status quo 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 Token Streaming Protocol (TSP).

The reference implementation for the TSP is made in Solana Blockchain due to its many benefits, particularly its ~400ms block times (a 3,000% improvement over Ethereum’s). Even though the reference implementation is built in Solana, the same concepts apply to most public permissionless blockchains with unique operational individualities.

The general use of the TSP goes as follows:

1. A user creates a Token Stream by calling the TSP. We’ll refer to this user as the manager (aka treasurer).

2. The recipient of the Token Stream is referred to as the beneficiary.

3. The Token Stream is set up with specific conditions such as vesting schedule, rate, cliff, start time, and beneficiary, among other setup options.

4. One or more contributors can fund the Token Stream with tokens (SPL Tokens).

5. Once the Token Stream starts, the beneficiary can withdraw tokens from it based on its current solvency.

6. The amount of tokens 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)

7. The Token Stream terms can be updated at any time and require the signatures of both the manager and the beneficiary to commit to the update.

8. The Token Stream can be closed unilaterally and without consensus by the manager or the beneficiary.

9. In the event of closure of the Token Stream, the TSP distributes any unvested funds back to the original contributors and all vested funds to the beneficiary automatically.

Motivation

Token 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 ($1,000/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 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 does not exist 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.

Token Streaming for Simple Contract Payments

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.

Token Streaming for Remittance and Family Allowances

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.)

Token Streaming for Subscriptions

Payroll

Pay your employees from the company treasury. Remove all payroll nightmares. Employees get paid by the second.

Token Streaming for Payroll

Retirement and Fundraising

Pension Plan Payments

Retirement distributions from retirement age until death.

Token Streaming for Retirement Accounts & Pension Funds

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.

Token Streaming for Investor Vesting Contracts

Real Estate Use Cases

Rent Payments

Pay Rent / Collect Rent without being bound to monthly installments. This also applies to hotels, motels, and hostels, where they can charge by the minute, etc.

Token Streaming for Rentals and Hotels

Real Estate Sales

Manage the escrow payments and distributions in a real estate sale transaction.

Token Streaming for Real Estate Escrow Transactions

Government Use Cases

Tax Collection

Tax payments are received by governments and distributed to serve different public services, such as Schools, Firefighters, Police, etc. Current systems to distribute collected tax funds require significant overhead and a lack of transparency. A token streaming contract where multiple beneficiaries (school district, firefighter department, etc.) are set up to receive a percentage of the stream automatically creates great automation and transparency in the tax distribution and benefits system.

Token Streaming for Government Benefits tax distributions

Government Program Distribution

Social programs from governments around the world must distribute money in the form of vouchers or direct deposits to their citizens. The traditional way of doing this is by delegating a portion of the funds to local governments with the hope they know how to get the money to the right hands and organizations. This creates a lot of redundancy and overhead, causing anywhere between 30% and 40% of the funds to be lost in bureaucratic middlemen overhead.

Program distributions can be easily solved with a Token Streaming Contract, whereby taxpayers are identified and registered with the contract and set up to receive their pre-approved vouchers or money directly in the form of NFTs or stable tokens. Using a TSP creates a direct-to-taxpayer route from central governments with ultimate transparency that has never been seen before.

Other Use Cases

Donations

NGOs and Nonprofits can set up a stream that allocates the funds little by little and allows 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.

Streaming Accounts

There are two types of Token Streaming Accounts: Open or Locked.

With an Open Streaming Account, you can create token streams that run indefinitely (no end date). When the streaming account runs out of tokens, all streams stop running until they get replenished. After replenishing the account, all paused payment streams can resume their operation.

With a Locked Streaming Account, you can create token 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 Reserved Allocations.

Reserving an allocation from a Locked Streaming Account into a specific token stream means the beneficiary immediately becomes the OWNER of the allocation. However, the owner-beneficiary is locked from accessing these funds as specified by the rate and frequency of the token stream. This is useful for investors or any pre-paid contracts since the beneficiary has already paid for their tokens, and the objective 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.

Token Streaming Actors

The payment streaming program specification defines how the different players, actors, and components interact with each other.

The basic premise of a token streaming smart contract is that once it gets executed between a manager (sender) and a beneficiary (recipient), its terms are enforced by code instead of humans. The manager cannot run away with the tokens owed to the beneficiary, and the beneficiary cannot take the tokens he/she has not yet earned.

In order to stream tokens from A→B at a specific rate/flow over time, the following participants are defined.

1. Token Streaming Program (TSP): A smart contract or program deployed to a permissionless blockchain that uses this protocol as a reference implementation.

2. Streaming Account: An account (wallet address) used to escrow the tokens being streamed. This account is under the sole custody/ownership of the TSP smart contract.

3. Manager: A person or organization creating and managing a Streaming Account and its Token Streams.

4. Contributor: Any person or organization contributing tokens to a Streaming Account.

5. Beneficiary: A person or organization receiving tokens from a Token Stream.

6. Stream Terms: A set of terms and an amount of tokens, expressed as a rate over time, that should be streamed to a beneficiary from the Streaming Account.

7. Token Stream: An account maintained by the TSP, which maintains the state of a stream in near-real-time based on the terms encoded, along with the vested and unvested amounts on behalf of a beneficiary.

State Machine

A token stream is a finite-state-machine (FSM) with the following states and transitions:

Current State	Input	Next State	Output
Scheduled	Pause CTA	Paused	Stops the token from streaming to the beneficiary. This is reversible.
Scheduled	Planned time arrived	Running	Starts streaming tokens from the streaming account to the beneficiary.
Running	Manager or Beneficiary manually stops the stream	Paused	The stream is paused, and tokens stop flowing to the beneficiary.
Running	Streaming Account ran out of tokens	Paused	Since there are no token to stream, the stream is stopped, and the beneficiary does not get any more tokens. This is reversible if the streaming account is reloaded.
Paused	Streaming Account reloaded with tokens	Running	Resumes streaming tokens from the streaming account to the beneficiary.

The token stream can be closed unilaterally and without consensus by the manager or the beneficiary. 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 streaming account.

Related Works

ERC-1620 is a protocol specification on Ethereum defining a standard for money streaming with motivations similar 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 the stream's start and end time, which is a limitation to those use cases where the end date is unknown (such as a pension fund). Sablier was launched in 2019 and, 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 token 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/

Other Considerations

Conditional Streams

Hourly employees 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 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 Token Streaming Contract, we would need to:

1. Allow the token stream to be configured with 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 earning tokens from the stream.

3. Allow the beneficiary to PauseStream to signal the contract that he/she is “off the clock” and, therefore, should NOT be earning tokens from the stream.

   1. This API should also allow the manager invocation 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 Manager

Problem: Consider the following case.

1. A new streaming account is set up by John with one beneficiary, Alice

2. John adds a stream guaranteeing Alice a pay rate of $1,000/month

3. John then talks to contributors Bob and Jane to fund Alice’s operation through the streaming account.

4. Bob and Jane like Alice’s project and agree to fund the streaming account with $1,000,000. Knowing Alice can only take $1,000/month, they feel they are giving the project long-term stability.

5. Now John goes rogue and secretly decides to add his accomplice Pepe as another beneficiary to the streaming account without asking Bob and Jane.

6. John sets up Pepe with a rate of $999,000 per minute.

7. The results next morning are catastrophic:

   1. John is kaput, nowhere to be found.

   2. Alice wakes up to an empty streaming account; her project is toast.

   3. Bob and Jane lost $1,000,000 and have no project to back up.

8. This is a classic rug pull.

Solution: Contributors should take special care in ensuring the streaming account is managed through a multisig wallet (like Solar Shield) and require a super-majority vote to add new Token Streams.