Introduction​

Tagomi is a revolutionary asset streaming and distribution protocol bringing subscriptions, salaries, vesting, and rewards to DAOs and crypto-native businesses worldwide. This is made possible by the protocol’s smart contract framework which introduces the Super Token - an extension to the BEP-20 standard enabling the transfer of value in completely novel ways.

Super Tokens​

The Tagomi protocol is designed to be a "token-centric" protocol, in that all of its functionalities revolve around the concept of Super Tokens. The framework & Super Token standard can be used to add dynamic balances to tokens on chain, describing cash flows and executing them automatically over time in a non-interactive way. Any token can be transferred in Tagomi streams or distributions, which are programmable, composable, and modular. No capital is locked up, and all inflows and outflows are netted in real-time at every block without consuming any gas. The code is fully open source, while the protocol is non-custodial and permissionless.

The Tagomi Protocol has currently two main pillars that define its interactions with Super Tokens. These pillars (formerly called Agreements) are the following:

• Money Streaming - A set of features that enable the creation of money streams between two parties.

• Distributions - A set of features that enables the creation of a pool of funds that can be distributed to multiple recipients.

We go in further details about these two pillars in the next sections.

Money Streaming​

Definition​

Money Streaming is a continuous transfer of tokens from a sender to a receiver at a defined per-second rate, resulting in a "stream". This stream is perpetual and persists until it's canceled by either the sender or the receiver, or until the sender's Super Token balance is depleted.

Explanation​

Money Streaming is a novel approach to token transfers, offering a dynamic way of sending funds. Instead of one-time transactions, tokens flow from the sender to the receiver continuously, creating a stream. This method provides real-time financial transactions, enabling a more fluid movement of assets over time, reflecting real-world economic activities more closely.

Example​

A visualization of money streaming from the Tagomi dashboard

Consider Alice wants to pay Bob a salary of 1200 USDCx per year using Money Streaming. She sets up a stream with a flow rate of 0.038 USDCx per second. Bob's balance starts increasing every second, and Alice's decreases, ensuring a steady transfer of salary.

Distributions​

Definition​

Distributions in Tagomi refer to a scalable one-to-many fund transfer method. It involves creating pools with a pool admin managing units for members, who can receive funds instantly or through continuous streaming.

Explanation​

Distributions are a significant advancement in decentralized finance, enabling efficient and scalable fund transfers among multiple recipients. This method is especially useful for scenarios where funds need to be distributed among many parties, like dividends or rewards, ensuring equitable and automated distribution based on predefined units.

Example​

Imagine a DeFi project creating a reward pool for liquidity providers. The project sets up a distribution pool with a total of 1000 units. If a liquidity provider has 100 units, they receive 10% of the total funds distributed through the pool, either instantly or as a continuous stream, depending on the distribution method.

How to Stake TGM Tokens:

1. Access the Staking Platform: Go to the staking platform provided by Tagomi.

2. Connect Wallet: Connect your wallet that holds the TGM tokens to the staking platform.

3. Choose Pool: Select the pool you want to stake your TGM tokens in based on the amount you hold.

4. Enter Amount: Enter the amount of TGM tokens you wish to stake in the chosen pool.

5. Confirm Staking: Confirm the staking transaction and wait for it to be processed.

6. Staking Period: Your staked TGM tokens will be locked in the chosen pool for a period of 10 days.

7. Earn Rewards: During the staking period, you will start earning staking rewards based on the APR (Annual Percentage Rate) of the chosen pool.

Staking Pool Details and Benefits:

• Pool 1 - 1000 to 40,000 TGM:

  • APR: 20%

  • Benefit: Users staking between 1000 to 40,000 TGM tokens will receive an APR of 20%, meaning they will earn a 20% annualized return on their staked TGM tokens.

• Pool 2 - > 40,000 to 120,000 TGM:

  • APR: 40%

  • Benefit: Users staking between > 40,000 to 120,000 TGM tokens will receive an APR of approximately 40%, offering a higher annualized return compared to Pool 1.

• Pool 3 - > 120,000 to 400,000 TGM:

  • APR: 80%

  • Benefit: Users staking between > 120,000 to 400,000 TGM tokens will receive an APR of approximately 80%, offering the highest annualized return and significant rewards for staking a larger amount of TGM tokens.

Overall Benefits of Staking:

• Passive Income: Staking TGM tokens allows users to earn passive income through staking rewards without actively trading or participating in the market.

• Higher Returns: By staking larger amounts of TGM tokens, users can benefit from higher APRs, leading to potentially higher returns on their investment.

• Community Participation: Staking also contributes to the stability and security of the Tagomi network by incentivizing token holders to actively participate in securing the network.

By following these steps and understanding the benefits, users can effectively stake their TGM tokens and earn rewards while contributing to the Tagomi ecosystem.

Super Tokens extend the BEP20 token standard with additional functionalities like Money Streaming or Distributions, formerly known as Super Agreements. There are two types of Super Tokens: wrapper and custom.

Super Tokens can perform all the functions of a traditional BEP20 token, plus additional value transfer methods enabled by Tagomi, such as money streaming.

Wrapper Super Tokens​

Wrapper Super Tokens are existing tokens wrapped to gain Tagomi functionalities. Wrapping converts the underlying token into its Super Token version, while unwrapping reverses the process.

Drag the tokens together to create a SUPER TOKEN!Your TokenWrapper Super TokenYour token is normal - drag it to give it superpowers!

By wrapping the original token you obtain a SUPER TOKEN

For more informations, about the wrapping process, please refer to our Developers Section.

Pure Super Tokens​

Pure Super Tokens are natively Tagomi-enabled without an underlying token. They offer inherent ERC20 functionalities plus Tagomi's Super Agreement capabilities.

Click as quickly as possible on the Pure Super Token to create your first stream!Pure Super Token

A Pure Super Token has inherent superpowers such as Money Streaming and Distributions

Real-Time Balance​

Super Tokens track an account's balance dynamically, factoring in both regular transfers and impacts from Money Streaming and Distributions.

• Static Balance: The standard BEP20 balance affected by lump-sum transfers.

• Real-Time Balances: The ongoing impact of each Super Agreement on an account's balance, which can be positive or negative.

The actual current balance is a sum of these components.

Current Balance Formula: Current Balance = Real-Time Balances + Static Balance

Example Calculation​

• Account A's Static Balance: 1,000 USDCx

• Account A's Stream Out: -100 USDCx

• Account A's Instant Distribution Receipts: +200 USDCx

Current Balance: 1000 - 100 + 200 = 1100 USDCx

About Super Tokens balanceOf()

If you are familiar with the BEP20 standard, you are certainly familiar with balanceOf(). A Super Token balanceOf() function reflects this dynamic balance, unlike a regular BEP20's static approach.

Definition

Money Streaming is a process where tokens are continuously transferred from a sender to a receiver at a defined per-second rate. The result of this process is a "stream". A stream is perpetual and will continue until canceled by the sender/the receiver or the sender's Super Token balance is depleted.

Terminology

• Flow Rate: The rate at which the sender's balance decreases and the receiver's increases per second.

• Netflow Rate: The rate of change of an account's Super Token balance per second.

• Sender: The account initiating the stream, specifying a receiver and flow rate.

• Receiver: The account on the receiving end of a stream.

• : The timestamp when a stream is created, updated, or deleted.

• Real-Time Balance: The change in the account's Super Token balance since the last CRUD action.

• Static Balance: The Super Token balance at the last CRUD timestamp.

• Current Balance: The sum of Static Balance and Streaming Real-Time Balance.

info

NOTE: Flow rates are per second but can be represented in different time units for convenience. For example, "100 USDCx/mo." is approximately "0.0039 USDCx/sec."

Computation

The netflow for an account is calculated by netting its inbound and outbound streaming flow rates.

Example of Net Flow calculation

When a stream is modified, the following are updated in the Superfluid contracts:

1. New Netflow rate

2. New CRUD timestamp

3. New Static Balance: set to the Current Balance at the CRUD timestamp

4. Real-Time Balance reset to zero

The Real-Time Balance then adjusts by-the-second at the netflow rate.

Streaming Real-Time Balance

info

NOTE: Creating a stream is a one-time action. The balance is dynamically calculated and does not require continuous transactions.

• Static Balance: Initial balance at the latest CRUD timestamp

• Real-Time Balance: Netflow Rate * Seconds since the latest CRUD timestamp

• Current Balance: Static Balance + Real-Time Balance

Let's examine how Account A's balance changes with stream interactions.

Outbound Stream

• Initial Balance: 1000 USDCx

• Flow Rate to Account B: 0.01 USDCx/sec

• Time Elapsed: 1000 seconds

• Current Balance: 990 USDCx

Flow Rate Increase

• Static Balance: 990 USDCx

• New Flow Rate: 0.02 USDCx/sec

• Current Balance: 990 USDCx

Time Elapse

• Time Elapsed: 2000 seconds

• Current Balance: 950 USDCx

Inbound Stream

• Inbound Flow Rate from Account C: 0.04 USDCx/sec

• Current Balance: 950 USDCx

Post Inbound Stream

• Time Elapsed: 1000 seconds

• Current Balance: 970 USDCx

*Deleting Inbound Stream

• Static Balance: 970 USDCx

• Current Balance: 970 USDCx

Transferring, wrapping, or unwrapping Super Tokens, being lump-sum actions, only affect the Static Balance and not the Real-Time Balance.

Actions within Distributions have their own Real-Time Balance and are added separately to the overall account balance.

Accounts with negative net flow rates reaching zero balance are considered critical. Superfluid handles this with buffer deposits and Sentinels.

Buffer deposits are taken when opening a stream, serving as a reserve in case of a critical balance. If a stream is closed before hitting critical, the buffer is refunded. In cases where the account becomes critical, the buffer is used to continue outbound streams until Sentinels intervene.

Sentinels are external actors who monitor Constant Flow Agreements (Money Streaming), close streams of critical accounts, and earn buffer deposits.

For more details, see the Liquidations and Sentinels pages.

Introduction to the Trading Feature on the Tagomi App

Welcome to the trading feature on the Tagomi app – a powerful tool designed to help you optimize your trading of digital assets. By utilizing the latest market analysis and price trend technologies, Tagomi not only provides users with a smooth trading experience but also offers essential insights for making informed decisions.

1. Cutting-Edge Trading Features The trading feature of Tagomi allows users to execute transactions quickly and efficiently. Users can easily buy and sell thousands of digital assets across multiple exchanges from a single interface. Notably, Tagomi supports large-volume trading, helping you maximize profits without impacting the market. Additionally, for every successful trade, users will earn 5 Points, enhancing the rewards for their trading activity.

2. Modern Market Analysis Technology

   • Technical Analysis: Tagomi provides advanced technical analysis tools, including real-time price charts, technical indicators (RSI, MACD, Bollinger Bands, etc.), and candlestick patterns, enabling users to accurately capture market trends.

   • Sentiment Analysis: The app integrates sentiment analysis technology that gathers data from news sources and social media to evaluate market psychology. By analyzing community reactions, users can make informed trading decisions.

   • Price Prediction: Utilizing AI and machine learning technology, Tagomi offers predictions on future price movements. Predictive models are trained on historical data and current indicators, providing users with deeper insights into market trends.

3. User-Friendly and Intuitive Interface Tagomi features a user-friendly interface that makes it easy for both beginners and experienced traders to navigate and use. Users can quickly access analysis tools, place trades, and monitor their assets with just a few clicks.

4. Security and Reliability Tagomi is committed to providing a safe trading environment. All transactions are encrypted and validated through multiple layers of security. Users can trade with peace of mind, knowing that their information and assets are well protected.

5. Conclusion The trading feature on the Tagomi app offers users a powerful and flexible tool for engaging in the crypto market. With advanced market analysis and price trend technology, Tagomi not only helps you make informed decisions but also optimizes your trading profits. Experience and explore the world of trading potential with Tagomi today, and don’t forget to earn 5 Points for every winning trade!

Introduction to the Mini Game of the Crypto Tagomi Project

Welcome to the mini game of the Crypto Tagomi project – a unique entertainment experience that combines blockchain technology with gaming! Specifically designed to provide fun and excitement, this mini game not only helps players relax but also offers opportunities to earn rewards and learn about the crypto world.

1. Introduction to Tagomi

Crypto Tagomi is an innovative blockchain platform aimed at optimizing trading and managing digital assets. With the mission to provide users with the best tools and experiences, we have developed an engaging mini game to create interaction and connection within the crypto community.

2. Mini Game Content

The Tagomi mini game is an exciting strategy game where players take on the role of savvy traders in the volatile crypto market. Players must make smart decisions and strategies to optimize their profits, thereby enhancing their trading skills.

• How to Play:

  • Players will receive a certain amount of tokens to start trading.

  • Participate in virtual trading sessions where the values of cryptocurrencies change in real time.

  • Compete against other players to see who can achieve the highest profit within a limited time.

• Key Features:

  • Attractive Rewards: Players with the best performances will receive rewards in project tokens, which can be used in other activities on the Tagomi platform.

  • Ranking System: Players can track their achievements through a leaderboard and receive additional rewards for those who rank at the top.

  • Learning from Failures: The game not only entertains but also provides valuable lessons about trading and asset management.

3. Benefits of Participation

• Entertainment and Education: The mini game not only helps players relax but also equips them with essential knowledge about crypto trading.

• Community Connection: Participating in the mini game helps players connect with the crypto community, sharing experiences and strategies.

• Earning Opportunities: With attractive rewards, players can earn tokens and increase the value of their assets just by participating in the game.

4. Conclusion

The mini game of Crypto Tagomi is a fantastic opportunity to experience the crypto world in a fun and enriching way. Join today to explore, learn, and earn rewards in a creative and connected environment. We hope this game will provide you with relaxing moments and memorable experiences on your crypto journey!

This glossary provides a comprehensive overview of terms and concepts within the Tagomi ecosystem.

General Conceptual Terms​

Tagomi Ecosystem: The collective of users and Super Apps utilizing real-time finance through Tagomi.

Real-Time Finance: The movement of money on a second-by-second basis enabled by Tagomi's smart contract framework.

Super Tokens​

Super Token: Tokens used in all Tagomi operations. Types include BEP20 Wrapper Tokens, Pure Super Tokens, and Native Asset Super Tokens. Detailed information is available in our Super Tokens section.

Wrap: The process of converting BEP20 tokens into wrapped super tokens. This involves transferring BEP20 assets into the wrapper contract and receiving an equivalent amount of super tokens.

Unwrap: Converting wrapped super tokens back into their underlying BEP20 assets. This involves burning super tokens and transferring the underlying asset to the user.

Real Time Balance: A dynamic calculation of an account's balance, considering both Tagomi agreement logic and static token balances.

Agreements​

Tagomi Agreement: Additional functionalities for Super Tokens provided by the Tagomi protocol. Examples include the Constant Flow Agreement and the Instant Distribution Agreement, with potential for more in the future.

Constant Flow Agreement (CFA): An agreement allowing perpetual, second-by-second movement of Super Tokens between addresses.

Instant Distribution Agreement (IDA): An agreement for mass dispersion of Super Tokens to multiple addresses based on distribution shares or "units" at a fixed gas cost.

Flow: A continuous money stream from one address to another. A sender can maintain only one flow to the same receiver per token.

Flow Rate: The amount of tokens sent in a stream, denominated in wei per second.

Net Flow Rate: The net amount of tokens sent or received per second by an account for a specific token.

ACL (Access Control List): A feature enabling varying levels of control to operators for creating, updating, or deleting streams on behalf of an account.

Index: A pool created using the Instant Distribution Agreement.

Publisher: The creator of an Index.

Units: Shares denoting an address’s share of an IDA index, interchangeable with "distribution shares".

Distribution: The action of sending tokens to addresses owning shares in an index, proportionate to the number of shares held.

Protocol​

Callback: A function that automatically executes when specific actions are taken. Super Apps use callbacks to respond to Tagomi-related actions.

User Data: Data that can be included with Tagomi function calls and utilized within Super App callbacks.

Batch Calls: A Super Token feature allowing multiple actions to be executed in a single transaction.

The Tagomi Host: The core of the protocol, processing function calls and facilitating protocol governance and Super App callbacks.

Resolver: A contract assisting in locating all protocol constituent contract addresses.

Sentinels & Solvency​

Buffer: Tokens locked temporarily when a stream starts.

Liquidation: The process initiated by a sentinel when an account's balance reaches zero while streaming funds.

Sentinel: A node monitoring the Tagomi network and closing critical or insolvent streams. Anyone can run a sentinel node.

PIC (Patrician in Charge): The recipient of rewards for closing streams during the priority period when an account becomes critical.

TOGA (Transparent Ongoing Auction): An auction allowing individuals to become the PIC by staking a higher amount than the current PIC.

Stake: Funds locked in the TOGA contract by the PIC.

Top Up: Adding to a Super Token balance to prevent liquidation due to a zero balance.

ISETH is the interface for native Super Tokens.

ABI​

In order to interact with any contract satistying the ISETH interface, you can use the following ABI:

Fn upgradeByETH​

function upgradeByETH(
) 
    external

Fn upgradeByETHTo​

function upgradeByETHTo(
    address to
) 
    external

Parameters​

Fn downgradeToETH​

function downgradeToETH(
    uint256 wad
) 
    external

Parameters​

ISETH

Super ETH (SETH) full interface

This is the technical reference related to the interface for any super token pool regardless of the distribution schemes.

struct PoolIndexData​

struct PoolIndexData {
  uint128 totalUnits;
  uint32 wrappedSettledAt;
  int96 wrappedFlowRate;
  int256 wrappedSettledValue;
}

struct MemberData​

struct MemberData {
  uint128 ownedUnits;
  uint32 syncedSettledAt;
  int96 syncedFlowRate;
  int256 syncedSettledValue;
  int256 settledValue;
  int256 claimedValue;
}

Tagomi_POOL_INVALID_TIME​

error Tagomi_POOL_INVALID_TIME()

Tagomi_POOL_NO_POOL_MEMBERS​

error Tagomi_POOL_NO_POOL_MEMBERS()

Tagomi_POOL_NO_ZERO_ADDRESS​

error Tagomi_POOL_NO_ZERO_ADDRESS()

Tagomi_POOL_NOT_POOL_ADMIN_OR_GDA​

error Tagomi_POOL_NOT_POOL_ADMIN_OR_GDA()

Tagomi_POOL_NOT_GDA​

error Tagomi_POOL_NOT_GDA()

Tagomi_POOL_TRANSFER_UNITS_NOT_ALLOWED​

error Tagomi_POOL_TRANSFER_UNITS_NOT_ALLOWED()

Event MemberUnitsUpdated​

event MemberUnitsUpdated(
    contract ITagomiToken token,
    address member,
    uint128 oldUnits,
    uint128 newUnits
)

Parameters​

Event DistributionClaimed​

event DistributionClaimed(
    contract ITagomiToken token,
    address member,
    int256 claimedAmount,
    int256 totalClaimed
)

Parameters​

Fn transferabilityForUnitsOwner​

function transferabilityForUnitsOwner(
) 
    external 
    returns (bool)

A boolean indicating whether pool members can transfer their units

Fn distributionFromAnyAddress​

function distributionFromAnyAddress(
) 
    external 
    returns (bool)

A boolean indicating whether addresses other than the pool admin can distribute via the pool

Fn admin​

function admin(
) 
    external 
    returns (address)

The admin is the creator of the pool and has permissions to update member units and is the recipient of the adjustment flow rate

The pool admin

Fn superToken​

function superToken(
) 
    external 
    returns (contract ITagomiToken)

The SuperToken for the pool

Fn getTotalUnits​

function getTotalUnits(
) 
    external 
    returns (uint128)

The total units of the pool

Fn getTotalConnectedUnits​

function getTotalConnectedUnits(
) 
    external 
    returns (uint128)

The total number of units of connected members

Fn getTotalDisconnectedUnits​

function getTotalDisconnectedUnits(
) 
    external 
    returns (uint128)

The total number of units of disconnected members

Fn getUnits​

function getUnits(
    address memberAddress
) 
    external 
    returns (uint128)

Parameters​

The total number of units for memberAddress

Fn getTotalFlowRate​

function getTotalFlowRate(
) 
    external 
    returns (int96)

The total flow rate of the pool

Fn getTotalConnectedFlowRate​

function getTotalConnectedFlowRate(
) 
    external 
    returns (int96)

The flow rate of the connected members

Fn getTotalDisconnectedFlowRate​

function getTotalDisconnectedFlowRate(
) 
    external 
    returns (int96)

The flow rate of the disconnected members

Fn getDisconnectedBalance​

function getDisconnectedBalance(
    uint32 time
) 
    external 
    returns (int256 balance)

Parameters​

The balance of all the disconnected members at time

Fn getMemberFlowRate​

function getMemberFlowRate(
    address memberAddress
) 
    external 
    returns (int96)

Parameters​

The flow rate a member is receiving from the pool

Fn getClaimable​

function getClaimable(
    address memberAddr,
    uint32 time
) 
    external 
    returns (int256)

Parameters​

The claimable balance for memberAddr at time in the pool

Fn getClaimableNow​

function getClaimableNow(
    address memberAddr
) 
    external 
    returns (int256 claimableBalance, uint256 timestamp)

Parameters​

The claimable balance for memberAddr at block.timestamp in the pool

Fn updateMemberUnits​

function updateMemberUnits(
    address memberAddr,
    uint128 newUnits
) 
    external 
    returns (bool)

Parameters​

Sets memberAddr ownedUnits to newUnits

Fn claimAll​

function claimAll(
    address memberAddr
) 
    external 
    returns (bool)

Parameters​

Claims the claimable balance for memberAddr at block.timestamp

Fn claimAll​

function claimAll(
) 
    external 
    returns (bool)

Claims the claimable balance for msg.sender at block.timestamp

Fn increaseAllowance​

function increaseAllowance(
    address spender,
    uint256 addedValue
) 
    external 
    returns (bool)

Parameters​

Return Values​

Increases the allowance of spender by addedValue

Fn decreaseAllowance​

function decreaseAllowance(
    address spender,
    uint256 subtractedValue
) 
    external 
    returns (bool)

Parameters​

Return Values​

Decreases the allowance of spender by subtractedValue

The CFAv1Forwarder contract is a Tagomi forwarder that implements the Constant Flow Agreement (CFA) related functions. It is a contract specifically made immutable in order to facilitate the interaction with Money Streaming through the Constant Flow Agreement (CFA).

This contract is optimized for interaction that would happen from your client application. For more information on the best practices regarding this interaction, please refer to the Create, Update and Delete Flows or Manage Access Control and User Data.

Contract Address​

The CFAv1Forwarder contract address is the same on all networks:

0xcfA132E353cB4E398080B9700609bb008eceB125

ABI​

In order to interact with the CFAv1Forwarder contract, you can use the following ABI:

CFA_FWD_INVALID_FLOW_RATE​

error CFA_FWD_INVALID_FLOW_RATE()

_cfa​

contract IConstantFlowAgreementV1 _cfa

Fn constructor​

function constructor(
    contract ITagomi host
)
    public

Parameters​

Fn setFlowrate​

setFlowrate() write

Try it out

function setFlowrate(address token, address receiver, int96 flowrate) nonpayable returns (bool)

powered byLearn more

Parameters​

Return Values​

Sets the given flowrate between msg.sender and a given receiver. If there's no pre-existing flow and flowrate non-zero, a new flow is created. If there's an existing flow and flowrate non-zero, the flowrate of that flow is updated. If there's an existing flow and flowrate zero, the flow is deleted. If the existing and given flowrate are equal, no action is taken. On creation of a flow, a "buffer" amount is automatically detracted from the sender account's available balance. If the sender account is solvent when the flow is deleted, this buffer is redeemed to it.

Fn setFlowrateFrom​

setFlowrateFrom() write

Try it out

function setFlowrateFrom(
  address token, 
  address sender, 
  address receiver, 
  int96 flowrate
) nonpayable returns (bool)

powered byLearn more

Parameters​

Return Values​

Like setFlowrate, but can be invoked by an account with flowOperator permissions on behalf of the sender account.

Fn getFlowrate​

getFlowrate() read

Try it out

function getFlowrate(address token, address sender, address receiver) view returns (int96 flowrate)

powered byLearn more

Currently, only 0 or 1 flows can exist between 2 accounts. This may change in the future.

Parameters​

Return Values​

Get the flowrate of the flow between 2 accounts if exists.

Fn getFlowInfo​

getFlowInfo() read

Try it out

function getFlowInfo(address token, address sender, address receiver) view returns (
  uint256 lastUpdated, 
  int96 flowrate, 
  uint256 deposit, 
  uint256 owedDeposit
)

powered byLearn more

Parameters​

Return Values​

Get all available information about a flow (if exists). If only the flowrate is needed, consider using getFlowrate instead.

Fn getBufferAmountByFlowrate​

function getBufferAmountByFlowrate(
    contract ISuperToken token,
    int96 flowrate
)
    external
    returns (uint256 bufferAmount)

getBufferAmountByFlowrate() read

Try it out

function getBufferAmountByFlowrate(address token, int96 flowrate) view returns (uint256 bufferAmount)

powered byLearn more

Parameters​

Return Values​

Get the buffer amount required for the given token and flowrate. This amount can vary based on the combination of token, flowrate and chain being queried. The result for a given set of parameters can change over time, because it depends on governance configurable protocol parameters. Changes of the required buffer amount affect only flows created or updated after the change.

Fn getAccountFlowrate​

getAccountFlowrate() read

Try it out

function getAccountFlowrate(address token, address account) view returns (int96 flowrate)

powered byLearn more

Parameters​

Return Values​

Get the net flowrate of an account.

Fn getAccountFlowInfo​

getAccountFlowInfo() read

Try it out

function getAccountFlowInfo(address token, address account) view returns (
  uint256 lastUpdated, 
  int96 flowrate, 
  uint256 deposit, 
  uint256 owedDeposit
)

powered byLearn more

Parameters​

Return Values​

Get aggregated flow information (if any exist) of an account. If only the net flowrate is needed, consider using getAccountFlowrate instead.

Fn createFlow​

createFlow() write

Try it out

function createFlow(
  address token, 
  address sender, 
  address receiver, 
  int96 flowrate, 
  bytes userData
) nonpayable returns (bool)

powered byLearn more

Parameters​

Return Values​

Low-level wrapper of createFlow/createFlowByOperator. If the address of msg.sender is not the same as the address of the sender argument, createFlowByOperator is used internally. In this case msg.sender needs to have permission to create flows on behalf of the given sender account with sufficient flowRateAllowance. Currently, only 1 flow can exist between 2 accounts, thus createFlow will fail if one already exists.

Fn updateFlow​

updateFlow() write

Try it out

function updateFlow(
  address token, 
  address sender, 
  address receiver, 
  int96 flowrate, 
  bytes userData
) nonpayable returns (bool)

powered byLearn more

Parameters​

Return Values​

Low-level wrapper if updateFlow/updateFlowByOperator. If the address of msg.sender doesn't match the address of the sender argument, updateFlowByOperator is invoked. In this case msg.sender needs to have permission to update flows on behalf of the given sender account with sufficient flowRateAllowance.

Fn deleteFlow​

deleteFlow() write

Try it out

function deleteFlow(
  address token, 
  address sender, 
  address receiver, 
  bytes userData
) nonpayable returns (bool)

powered byLearn more

Parameters​

Return Values​

Low-level wrapper of deleteFlow/deleteFlowByOperator. If msg.sender isn't the same as sender address, msg.sender needs to have permission to delete flows on behalf of the given sender account.

Fn grantPermissions​

grantPermissions() write

Try it out

function grantPermissions(address token, address flowOperator) nonpayable returns (bool)

powered byLearn more

Parameters​

Return Values​

Grants a flowOperator permission to create/update/delete flows on behalf of msg.sender. In order to restrict what a flowOperator can or can't do, the flowOperator account should be a contract implementing the desired restrictions.

Fn revokePermissions​

revokePermissions() write

Try it out

function revokePermissions(address token, address flowOperator) nonpayable returns (bool)

powered byLearn more

Parameters​

Return Values​

Revokes all permissions previously granted to a flowOperator by msg.sender. Revocation doesn't undo or reset flows previously created/updated by the flowOperator. In order to be sure about the state of flows at the time of revocation, you need to check that state either in the same transaction or after this transaction.

Fn updateFlowOperatorPermissions​

updateFlowOperatorPermissions() write

Try it out

function updateFlowOperatorPermissions(
  address token, 
  address flowOperator, 
  uint8 permissions, 
  int96 flowrateAllowance
) nonpayable returns (bool)

powered byLearn more

Parameters​

Return Values​

Low-level wrapper of IConstantFlowAgreementV1.updateFlowOperatorPermissions flowrateAllowance does NOT restrict the net flowrate a flowOperator is able to set. In order to restrict that, flowOperator needs to be a contract implementing the wanted limitations.

Fn getFlowOperatorPermissions​

getFlowOperatorPermissions() read

Try it out

function getFlowOperatorPermissions(address token, address sender, address flowOperator) view returns (uint8 permissions, int96 flowrateAllowance)

powered byLearn more

Parameters​

Return Values​

Get the currently set permissions granted to the given flowOperator by the given sender account.

Fn _setFlowrateFrom​

setFlowrateFrom() write

Try it out

function setFlowrateFrom(
  address token, 
  address sender, 
  address receiver, 
  int96 flowrate
) nonpayable returns (bool)

powered byLearn more

Parameters​

Fn _createFlow​

createFlow() write

Try it out

function createFlow(
  address token, 
  address sender, 
  address receiver, 
  int96 flowrate, 
  bytes userData
) nonpayable returns (bool)

powered byLearn more

Parameters​

Fn _updateFlow​

updateFlow() write

Try it out

function updateFlow(
  address token, 
  address sender, 
  address receiver, 
  int96 flowrate, 
  bytes userData
) nonpayable returns (bool)

powered byLearn more

Parameters​

Fn _deleteFlow​

deleteFlow() write

Try it out

function deleteFlow(
  address token, 
  address sender, 
  address receiver, 
  bytes userData
) nonpayable returns (bool)

powered byLearn more

Parameters​

Fn _updateFlowOperatorPermissions​

updateFlowOperatorPermissions() write

Try it out

function updateFlowOperatorPermissions(
  address token, 
  address flowOperator, 
  uint8 permissions, 
  int96 flowrateAllowance
) nonpayable returns (bool)

powered byLearn more

Parameters​

Program Overview

This bug bounty is specifically for Tagomi's smart contract code; client / UI only bugs are omitted.

Tagomi's smart contract is open-source(opens in a new tab).

The severity guidelines are based on Immunefi's classification system(opens in a new tab).

Note that these are simply guidelines for the severity of the bugs. Each bug bounty submission will be evaluated on a case-by-case basis.

Submission

Please email hello@drift.trade with a detailed description of the attack vector. For critical and moderate bugs, we require a proof of concept done on a privately deployed mainnet contract. We will reach back out in 1 business day with additional questions or the next steps on the bug bounty.

Bug Bounty Payment

Bug bounties will be paid in USDC. Alternative payment methods can be used on a case-by-case basis.

Invalid Bug Bounties

The following are out of scope for the bug bounty:

• Attacks that the reporter has already exploited themselves, leading to damage

• Attacks requiring access to leaked keys/credentials

• Attacks requiring access to privileged addresses (governance, admin)

• Incorrect data supplied by third-party oracles (This does not exclude oracle manipulation/flash loan attacks)

• Lack of liquidity

• Third-party, off-chain bot errors (for instance bugs with an arbitrage bot running on the smart contracts)

• Best practice critiques

• Sybil attacks

• Attempted phishing or other social engineering attacks involving Tagomi contributors or users

• Denial of service, or automated testing of services that generate significant traffic.

• Any submission violating Immunefi's rules

This is the technical reference related to the interface for Super Tokens.

Implementation addresses​

Super Token deployments work in a proxy pattern with the original implementation being comon between all super tokens for each chain. The implementation address for the SuperToken is different for each network and can be found in the SuperTokenFactory at the method getSuperTokenLogic.

To get the addresses of all the SuperTokenFactory contracts, you can use the Tagomi Explorer, section Protocol.

ABI​

In order to interact with any contract satistying the ISuperToken interface, you can use the following ABI:

Functions​

Fn initialize​

function initialize(
    contract IERC20 underlyingToken,
    uint8 underlyingDecimals,
    string n,
    string s
) 
    external

Initialize the contract

Parameters​

Fn initializeWithAdmin​

function initializeWithAdmin(
    contract IERC20 underlyingToken,
    uint8 underlyingDecimals,
    string n,
    string s,
    address admin
) 
    external

Initialize the contract with an admin

Parameters​

Fn changeAdmin​

function changeAdmin(
    address newAdmin
) 
    external

Only the current admin can call this function if admin is address(0), it is implicitly the host address

Parameters​

Changes the admin for the SuperToken

Fn getAdmin​

function getAdmin(
) 
    external 
    returns (address admin)

Returns the admin address for the SuperToken

Fn CONSTANT_OUTFLOW_NFT​

function CONSTANT_OUTFLOW_NFT(
) 
    external 
    returns (contract IConstantOutflowNFT)

Fn CONSTANT_INFLOW_NFT​

function CONSTANT_INFLOW_NFT(
) 
    external 
    returns (contract IConstantInflowNFT)

Fn POOL_ADMIN_NFT​

function POOL_ADMIN_NFT(
) 
    external 
    returns (contract IPoolAdminNFT)

Fn POOL_MEMBER_NFT​

function POOL_MEMBER_NFT(
) 
    external 
    returns (contract IPoolMemberNFT)

Fn name​

function name(
) 
    external 
    returns (string)

Returns the name of the token.

Fn symbol​

function symbol(
) 
    external 
    returns (string)

Returns the symbol of the token, usually a shorter version of the name.

Fn decimals​

function decimals(
) 
    external 
    returns (uint8)

_Returns the number of decimals used to get its user representation. For example, if decimals equals 2, a balance of 505 tokens should be displayed to a user as 5,05 (505 / 10 ** 2).

Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value ERC20 uses, unless setupDecimals is called.

Note​

SuperToken always uses 18 decimals.

This information is only used for display purposes: it in no way affects any of the arithmetic of the contract, including IBEP20-balanceOf and IBEP20-transfer.

Fn totalSupply​

function totalSupply(
) 
    external 
    returns (uint256)

See IBEP20-totalSupply.

Fn balanceOf​

function balanceOf(
    address account
) 
    external 
    returns (uint256 balance)

Returns the amount of tokens owned by an account (owner).

Parameters​

Fn transfer​

function transfer(
    address recipient,
    uint256 amount
) 
    external 
    returns (bool)

Moves amount tokens from the caller's account to recipient.

Parameters​

Return Values​

Emits​

a BEP20 Transfer event.

Fn allowance​

function allowance(
    address owner,
    address spender
) 
    external 
    returns (uint256)

Returns the remaining number of tokens that spender will be allowed to spend on behalf of owner through transferFrom. This is zero by default.

Parameters​

This value changes when approve or transferFrom are called.

Fn approve​

function approve(
    address spender,
    uint256 amount
) 
    external 
    returns (bool)

Sets amount as the allowance of spender over the caller's tokens.

Parameters​

Return Values​

Note​

Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards

Emits​

an Approval event.

Fn transferFrom​

function transferFrom(
    address sender,
    address recipient,
    uint256 amount
) 
    external 
    returns (bool)

Moves amount tokens from sender to recipient using the allowance mechanism. amount is then deducted from the caller's allowance.

Parameters​

Return Values​

Emits​

a Transfer event.

Fn increaseAllowance​

function increaseAllowance(
    address spender,
    uint256 addedValue
) 
    external 
    returns (bool)

_Atomically increases the allowance granted to spender by the caller.

This is an alternative to approve that can be used as a mitigation for problems described in IBEP20-approve._

Parameters​

Emits​

an Approval event indicating the updated allowance.

@custom:requirements

• `spender` cannot be the zero address.

Fn decreaseAllowance​

function decreaseAllowance(
    address spender,
    uint256 subtractedValue
) 
    external 
    returns (bool)

_Atomically decreases the allowance granted to spender by the caller.

This is an alternative to approve that can be used as a mitigation for problems described in IBEP20-approve._

Parameters​

Emits​

an Approval event indicating the updated allowance.

@custom:requirements

• `spender` cannot be the zero address.

• `spender` must have allowance for the caller of at least `subtractedValue`.

Fn granularity​

function granularity(
) 
    external 
    returns (uint256)

Returns the smallest part of the token that is not divisible. This means all token operations (creation, movement and destruction) must have amounts that are a multiple of this number.

Note​

For super token contracts, this value is always 1

Fn send​

function send(
    address recipient,
    uint256 amount,
    bytes userData
) 
    external

_Moves amount tokens from the caller's account to recipient.

If send or receive hooks are registered for the caller and recipient, the corresponding functions will be called with userData and empty operatorData. See IERC777Sender and IERC777Recipient._

Parameters​

Emits​

a Sent event.

@custom:requirements

• the caller must have at least `amount` tokens.

• `recipient` cannot be the zero address.

• if `recipient` is a contract, it must implement the IERC777Recipient interface.

Fn burn​

function burn(
    uint256 amount,
    bytes userData
) 
    external

_Destroys amount tokens from the caller's account, reducing the total supply and transfers the underlying token to the caller's account.

If a send hook is registered for the caller, the corresponding function will be called with userData and empty operatorData. See IERC777Sender._

Parameters​

Emits​

a Burned event.

@custom:requirements

• the caller must have at least `amount` tokens.

Fn isOperatorFor​

function isOperatorFor(
    address operator,
    address tokenHolder
) 
    external 
    returns (bool)

_Returns true if an account is an operator of tokenHolder. Operators can send and burn tokens on behalf of their owners. All accounts are their own operator.

See operatorSend and operatorBurn._

Parameters​

Fn authorizeOperator​

function authorizeOperator(
    address operator
) 
    external

_Make an account an operator of the caller.

See isOperatorFor._

Parameters​

Emits​

an AuthorizedOperator event.

@custom:requirements

• `operator` cannot be calling address.

Fn revokeOperator​

function revokeOperator(
    address operator
) 
    external

_Revoke an account's operator status for the caller.

See isOperatorFor and defaultOperators._

Parameters​

Emits​

a RevokedOperator event.

@custom:requirements

• `operator` cannot be calling address.

Fn defaultOperators​

function defaultOperators(
) 
    external 
    returns (address[])

_Returns the list of default operators. These accounts are operators for all token holders, even if authorizeOperator was never called on them.

This list is immutable, but individual holders may revoke these via revokeOperator, in which case isOperatorFor will return false._

Fn operatorSend​

function operatorSend(
    address sender,
    address recipient,
    uint256 amount,
    bytes userData,
    bytes operatorData
) 
    external

_Moves amount tokens from sender to recipient. The caller must be an operator of sender.

If send or receive hooks are registered for sender and recipient, the corresponding functions will be called with userData and operatorData. See IERC777Sender and IERC777Recipient._

Parameters​

Emits​

a Sent event.

@custom:requirements

• `sender` cannot be the zero address.

• `sender` must have at least `amount` tokens.

• the caller must be an operator for `sender`.

• `recipient` cannot be the zero address.

• if `recipient` is a contract, it must implement the IERC777Recipient interface.

Fn operatorBurn​

function operatorBurn(
    address account,
    uint256 amount,
    bytes userData,
    bytes operatorData
) 
    external

_Destroys amount tokens from account, reducing the total supply. The caller must be an operator of account.

If a send hook is registered for account, the corresponding function will be called with userData and operatorData. See IERC777Sender._

Parameters​

Emits​

a Burned event.

@custom:requirements

• `account` cannot be the zero address.

• `account` must have at least `amount` tokens.

• the caller must be an operator for `account`.

Fn selfMint​

function selfMint(
    address account,
    uint256 amount,
    bytes userData
) 
    external

_Mint new tokens for the account If userData is not empty, the tokensReceived hook is invoked according to ERC777 semantics.

@custom:modifiers

• onlySelf_

Parameters​

Fn selfBurn​

function selfBurn(
    address account,
    uint256 amount,
    bytes userData
) 
    external

_Burn existing tokens for the account If userData is not empty, the tokensToSend hook is invoked according to ERC777 semantics.

@custom:modifiers

• onlySelf_

Parameters​

Fn selfTransferFrom​

function selfTransferFrom(
    address sender,
    address spender,
    address recipient,
    uint256 amount
) 
    external

_Transfer amount tokens from the sender to recipient. If spender isn't the same as sender, checks if spender has allowance to spend tokens of sender.

@custom:modifiers

• onlySelf_

Parameters​

Fn selfApproveFor​

function selfApproveFor(
    address account,
    address spender,
    uint256 amount
) 
    external

_Give spender, amount allowance to spend the tokens of account.

@custom:modifiers

• onlySelf_

Parameters​

Fn transferAll​

function transferAll(
    address recipient
) 
    external

Transfer all available balance from msg.sender to recipient

Parameters​

Fn getUnderlyingToken​

function getUnderlyingToken(
) 
    external 
    returns (address tokenAddr)

Return the underlying token contract

Return Values​

Fn getUnderlyingDecimals​

function getUnderlyingDecimals(
) 
    external 
    returns (uint8 underlyingDecimals)

Return the underlying token decimals

Return Values​

Fn toUnderlyingAmount​

function toUnderlyingAmount(
    uint256 amount
) 
    external 
    returns (uint256 underlyingAmount, uint256 adjustedAmount)

Return the underlying token conversion rate

Parameters​

Return Values​

Fn upgrade​

function upgrade(
    uint256 amount
) 
    external

Upgrade ERC20 to SuperToken.

Parameters​

Note​

It will use `transferFrom` to get tokens. Before calling this function you should `approve` this contract

Fn upgradeTo​

function upgradeTo(
    address to,
    uint256 amount,
    bytes userData
) 
    external

Upgrade BEP20 to SuperToken and transfer immediately

Parameters​

Note​

It will use `transferFrom` to get tokens. Before calling this function you should `approve` this contract

@custom:warning

• there is potential of reentrancy IF the "to" account is a registered ERC777 recipient. @custom:requirements

• if `userData` is NOT empty AND `to` is a contract, it MUST be a registered ERC777 recipient otherwise it reverts.

Fn downgrade​

function downgrade(
    uint256 amount
) 
    external

Downgrade SuperToken to ERC20. It will call transfer to send tokens

Parameters​

Fn downgradeTo​

function downgradeTo(
    address to,
    uint256 amount
) 
    external

Downgrade SuperToken to BEP20 and transfer immediately

Parameters​

Fn operationApprove​

function operationApprove(
    address account,
    address spender,
    uint256 amount
) 
    external

Perform BEP20 approve by host contract.

Parameters​

@custom:modifiers

• onlyHost |

Fn operationIncreaseAllowance​

function operationIncreaseAllowance(
    address account,
    address spender,
    uint256 addedValue
) 
    external

Parameters​

Fn operationDecreaseAllowance​

function operationDecreaseAllowance(
    address account,
    address spender,
    uint256 subtractedValue
) 
    external

Parameters​

Fn operationTransferFrom​

function operationTransferFrom(
    address account,
    address spender,
    address recipient,
    uint256 amount
) 
    external

Perform ERC20 transferFrom by host contract.

Parameters​

@custom:modifiers

• onlyHost |

Fn operationSend​

function operationSend(
    address spender,
    address recipient,
    uint256 amount,
    bytes userData
) 
    external

Perform ERC777 send by host contract.

Parameters​

@custom:modifiers

• onlyHost |

Fn operationUpgrade​

function operationUpgrade(
    address account,
    uint256 amount
) 
    external

Upgrade ERC20 to SuperToken by host contract.

Parameters​

@custom:modifiers

• onlyHost |

Fn operationDowngrade​

function operationDowngrade(
    address account,
    uint256 amount
) 
    external

Downgrade ERC20 to SuperToken by host contract.

Parameters​

@custom:modifiers

• onlyHost |

Events​

Event AdminChanged​

event AdminChanged(
    address oldAdmin,
    address newAdmin
)

Parameters​

Event TokenUpgraded​

event TokenUpgraded(
    address account,
    uint256 amount
)

Token upgrade event

Parameters​

Event TokenDowngraded​

event TokenDowngraded(
    address account,
    uint256 amount
)

Token downgrade event

Parameters​

Event ConstantOutflowNFTCreated​

event ConstantOutflowNFTCreated(
    contract IConstantOutflowNFT constantOutflowNFT
)

Constant Outflow NFT proxy created event

Parameters​

Event ConstantInflowNFTCreated​

event ConstantInflowNFTCreated(
    contract IConstantInflowNFT constantInflowNFT
)

Constant Inflow NFT proxy created event

Parameters​

Event PoolAdminNFTCreated​

event PoolAdminNFTCreated(
    contract IPoolAdminNFT poolAdminNFT
)

Pool Admin NFT proxy created event

Parameters​

Event PoolMemberNFTCreated​

event PoolMemberNFTCreated(
    contract IPoolMemberNFT poolMemberNFT
)

Pool Member NFT proxy created event

Parameters​

Error Codes​

SUPER_TOKEN_CALLER_IS_NOT_OPERATOR_FOR_HOLDER​

error SUPER_TOKEN_CALLER_IS_NOT_OPERATOR_FOR_HOLDER()

SUPER_TOKEN_NOT_ERC777_TOKENS_RECIPIENT​

error SUPER_TOKEN_NOT_ERC777_TOKENS_RECIPIENT()

SUPER_TOKEN_INFLATIONARY_DEFLATIONARY_NOT_SUPPORTED​

error SUPER_TOKEN_INFLATIONARY_DEFLATIONARY_NOT_SUPPORTED()

SUPER_TOKEN_NO_UNDERLYING_TOKEN​

error SUPER_TOKEN_NO_UNDERLYING_TOKEN()

SUPER_TOKEN_ONLY_SELF​

error SUPER_TOKEN_ONLY_SELF()

SUPER_TOKEN_ONLY_ADMIN​

error SUPER_TOKEN_ONLY_ADMIN()

SUPER_TOKEN_ONLY_GOV_OWNER​

error SUPER_TOKEN_ONLY_GOV_OWNER()

SUPER_TOKEN_APPROVE_FROM_ZERO_ADDRESS​

error SUPER_TOKEN_APPROVE_FROM_ZERO_ADDRESS()

SUPER_TOKEN_APPROVE_TO_ZERO_ADDRESS​

error SUPER_TOKEN_APPROVE_TO_ZERO_ADDRESS()

SUPER_TOKEN_BURN_FROM_ZERO_ADDRESS​

error SUPER_TOKEN_BURN_FROM_ZERO_ADDRESS()

SUPER_TOKEN_MINT_TO_ZERO_ADDRESS​

error SUPER_TOKEN_MINT_TO_ZERO_ADDRESS()

SUPER_TOKEN_TRANSFER_FROM_ZERO_ADDRESS​

error SUPER_TOKEN_TRANSFER_FROM_ZERO_ADDRESS()

SUPER_TOKEN_TRANSFER_TO_ZERO_ADDRESS​

error SUPER_TOKEN_TRANSFER_TO_ZERO_ADDRESS()

SUPER_TOKEN_NFT_PROXY_ADDRESS_CHANGED​

error SUPER_TOKEN_NFT_PROXY_ADDRESS_CHANGED()

The GDAv1Forwarder contract is a Tagomi forwarder that implements the General Distribution Agreement (GDA) related functions. It is a contract specifically made immutable in order to facilitate the interaction with Distributions through the General Distribution Agreement (GDA).

This contract is optimized for interaction that would happen from outside the blockchain (off-chain). For more information on the best practices regarding this interaction, please refer to the SDK Section section of this documentation.

Contract Address​

The GDAv1Forwarder contract address is the same on all Tagomi chains:

0x6DA13Bde224A05a288748d857b9e7DDEffd1dE08

ABI​

In order to interact with the GDAv1Forwarder contract, you can use the following ABI:

_gda​

contract IGeneralDistributionAgreementV1 _gda

Fn constructor​

function constructor(
    contract ITagomi host
)
    public