Integrate with the Streamflow protocol

Streamflow is fully composable, supporting integration with various protocols via the Streamflow SDK. At the core of Streamflow is a protocol for programmable payments which acts like a time-lock escrow service for funds.

Streamflow Protocol allows the creation of scheduled Token Transfers from one account to another. This transfer may be done in the form of an actual token transfer on the chain to a Recipient address or as an unlock, meaning that after a certain time, the Recipient may claim tokens manually.

The schedule may be configured to send/unlock these tokens partially with some amount (absolute value) being unlocked every unlock period. The sender may also configure a cliff - a one-time unlock of a certain amount (different from the usual unlock amount configured in the contract) -that will be done as the first unlock.

Streamflow SDK

app.streamflow.finance is a React application that uses Streamflow's JS SDK directly.

  • Use the JS SDK to interact with the protocol => NPM package

    • It's possible to integrate with our JS SDK across all chains which Streamflow currently supports

  • Use the Rust SDK to integrate within a Solana program => Rust Crate


A protocol is a Program that lives on-chain. To interact with the Streamflow protocol you'll need to make use of pre-defined Methods, which are called within the blockchain transaction.


Authority: Anyone

Creates a Contract, usually accepts these parameters

	amount: u64,
        period: u64,
        amount_per_period: u64,
        start: u64,
        cliff_amount: u64,
        cancelable_by_sender: bool,
        cancelable_by_recipient: bool,
        transferable_by_sender: bool,
        transferable_by_recipient: bool,
        can_topup: bool,
        pausable: bool,
        can_update_rate: bool,
        automatic_withdrawal: bool,
        withdrawal_frequency: u64,
        contract_name: vector<u8>,
        recipient: address,
        partner: address,

All other parameters that are part of stream structure are calculated.


assert!(amount_per_period <= amount, EBAD_INPUT_AMOUNT_PER_PERIOD);
assert!(amount_per_period > 0, EBAD_INPUT_AMOUNT_PER_PERIOD);

if (cliff_amount > 0) {
    assert!(cliff_amount <= amount, EBAD_INPUT_CLIFF_AMOUNT);
assert!(period > 0, EBAD_INPUT_PERIOD);
assert!(withdrawal_frequency == 0 || withdrawal_frequency >= period, EBADINPUT);

assert!(now <= start, EBAD_INPUT_START);

Authority: Sender

Updates a Contract, usually accepts these parameters

				automatic_withdrawal: Option<bool>,
        withdrawal_frequency: Option<u64>,
        amount_per_period: Option<u64>,

All parameters are optional.

  • withdrawal_frequency is used only if automatic_withdrawal parameter is set to true

  • update allows only to enable automatic_withdrawal (disabling may be tricky because we also need to notify Worker for that, but in theory we can allow disabling AW)

  • amount_per_period is accepted only if can_update_rate is enabled


Authority: configured by cancelable_by_sender and cancelable_by_recipient flags

Cancel a Contract.

  • all unlocked funds by the time of cancellation are withdrawn (including fees)

  • all leftover funds are returned to the Sender (including fees)


Authority: Sender if pausable is enabled

Pause a Contract

  • when contract is paused, unlock calculation is halted

  • all already unlocked funds may be withdrawn


Authority: Sender if pausable is enabled and contract is in pause state

Unpauses a Contract

  • continue unlock calculation


Authority: Recipient or Withdrawor if automatic_withdrawal is enabled

Withdraw some amount to Recipient address, usually accepts these parameters

amount: u64
  • accepts 18446744073709551615 as magical number to withdraw all unlocked funds

  • can’t withdraw more than unlocked

  • fees are transferred according to withdrawn amount


Authority: configured by transferable_by_sender and transferable_by_recipient flags

Change Recipient address, usually accepts these parameters

				new_recipient: address
  • on transfer unlocked funds remain in a contract (so new recipient can withdraw them)

Last updated