Only this pageAll pages
Powered by GitBook
1 of 37

Tagomi

Loading...

OverView

Loading...

Loading...

Loading...

Ecosystem

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Token $TGM

Loading...

Loading...

Loading...

Use Cases

Loading...

Loading...

Advanced Topics

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Roadmap and developers

Loading...

Loading...

Security

Loading...

Loading...

Loading...

NFT

Introduction to the NFTs of the Crypto Tagomi Project

Welcome to the world of NFTs from the Crypto Tagomi project! We are proud to introduce a unique and valuable collection of NFTs, specially designed for RPG (Role-Playing Game) enthusiasts. With a perfect combination of art, blockchain technology, and gaming experience, Tagomi's NFTs are not just digital assets but valuable rewards in the journey of exploring the virtual world.

1. The Value of Tagomi NFTs

The NFTs (Non-Fungible Tokens) of Tagomi represent unique assets in the game, providing players with the opportunity to own special characters, items, and resources. Each NFT holds not only technical value but is also meticulously crafted in terms of art and design. Players can utilize these NFTs to enhance their gaming experience, create rich stories, and explore new possibilities in the world of Tagomi.

2. NFT Theme and Role-Playing Game

The NFT collection of Tagomi is designed around a rich role-playing theme, where players can embody different characters and embark on exciting adventures. The NFTs in the project include:

  • Characters: Each character is a unique NFT, equipped with special skills and abilities, allowing players to create their own strategies in battles.

  • Items: Valuable items such as weapons, armor, and accessories enhance the strength of characters and expand capabilities in the game.

  • Land/Environment: NFTs can also represent areas in the game, where players can build and develop their own worlds.

3. Benefits of NFTs in the Game

  • True Ownership: NFTs provide players with true ownership of in-game assets, meaning you can buy, sell, or trade your NFTs on various marketplaces.

  • Enhanced Gaming Experience: With unique NFTs, players can enrich their gaming experience, creating memorable moments and captivating stories.

  • Investment Value: The high-value NFTs from Tagomi are not just items in the game but can also become valuable investment assets in the future.

4. Conclusion

The NFTs of the Crypto Tagomi project are not just ordinary digital assets; they offer players wonderful experiences and real value in the world of role-playing games. Join the Tagomi community to explore this unique NFT collection and become a part of the exciting journey in the virtual world!

Distributions

The introduction of Distributions marks a significant advancement in DeFi applications, offering a scalable method for one-to-many fund transfers. Distributions allow for the transfer of value to multiple recipients with minimal on-chain data modification, making them infinitely scalable, highly efficient and gas-friendly.

note

There are other on-chain solutions that may seem to solve this problem without using a new token implementation (e.g Disperse App). While these solutions can be great for a low amount of recipients, they are not infinitely scalable and can become very expensive as the number of recipients increases. Furthermore, they do not allow for distributing money streaming

Overview​

Distributions function by allowing for the creation of pools with a designated pool admin who manages units for pool members. Members of these pools can receive funds either instantly or through continuous streaming, making this method highly efficient and scalable. There are two types of Distributions:

  • Instant Distributions: They allow one transaction distribution to any number of receivers with a fixed gas cost.

  • Streaming Distributions: They allow for continuous distribution of funds to receivers through Money Streaming to a Pool.


  • Instant Distribution

  • Streaming Distribution

Instant Distributions allow one transaction to distribute to any number of receivers with a fixed gas cost.

Click on the Blue Circle to initiate an Instant Distribution

Distribution PoolClick to distribute a tokenMember AMember BMember CMember DMember E

By creating a Distribution Pool, you can distribute any token instantly


Definitions​

  • Pool: A channel for proportional token distribution.

  • Distribution: The action of allocating specified token amounts to receivers.

  • Units: Represent the proportion of the distribution each subscriber receives.

  • Pool Admin: The administrator of the distribution process.

  • Subscribers/Pool Member: Receivers allocated units and eligible to receive tokens through the Index.

Key Features​

  • Pools as Contracts: Unlike previous approaches, pools in streaming distributions are contracts and can be ERC20 tokens. This allows pool members to transfer units among themselves, which wasn't possible earlier.

  • Roles and Permissions: A pool admin can grant and revoke units, while any account can act as a distributor to execute fund distributions.

  • Distribution Methods: There are two primary ways to distribute funds:

    • Instant Distribution: Calculated as distributionAmount * (poolMemberUnits / poolTotalUnits).

    • Streaming Distribution: Determined by poolFlowRate * (poolMemberUnits / poolTotalUnits).

  • Gas Efficiency: The cost of executing distributions remains constant, regardless of the number of pool members.

High-Level Workflow​

  1. Pool Creation: Any account can create a pool and appoint a pool admin. This pool acts as a channel for distributing funds.

  2. Unit Management: The pool admin assigns units to members, representing their share in future distributions.

  3. Member Connection: Pool members can connect to or disconnect from the pool, affecting how they access distributed funds.

  4. Distribution Execution: Distributors can initiate either instant or streaming distributions, which are then divided among pool members based on their unit share.

Distribution Examples​

Streaming Distribution Illustration​

This diagram shows a distributor streaming funds to various pool members, each holding different unit amounts. Note: A single transaction can cater to multiple members.

Streaming Distribution

Adjusting Unit Counts​

Here, a distributor modifies unit counts for members. This change instantly alters the distribution rate for all members in one transaction. Batch updates can be done using Tagomi's batch call.

Unit Count Adjustment

Modifying the Flow Rate​

This example demonstrates how a change in the distributor's streaming rate affects the total flow rate of the pool, thus instantly impacting each member's rate.

Flow Rate Change

Advanced Pool Features​

As pools are also ERC20 tokens, they enable:

  • Transfer of Units: Pool members can freely transfer their units.

  • Delegated Transfers: Using the approve and transferFrom functions, units can be transferred on behalf of a member.

These features add composability and flexibility, expanding the potential use cases for pools in web3.

Money Streaming

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.

  • CRUD Timestamp: 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.

Formula​

  • 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

Example - Monitoring Account A's Current Balance​

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

1. Starting an Outbound Stream​

Outbound Stream

Outbound Stream

  • Initial Balance: 1000 USDCx

  • Flow Rate to Account B: 0.01 USDCx/sec

  • Time Elapsed: 1000 seconds

  • Current Balance: 990 USDCx

2. Increasing the Flow Rate​

Flow Rate Increase

Flow Rate Increase

  • Static Balance: 990 USDCx

  • New Flow Rate: 0.02 USDCx/sec

  • Current Balance: 990 USDCx

3. Time Elapse Post Flow Rate Change​

Time Elapse

Time Elapse

  • Time Elapsed: 2000 seconds

  • Current Balance: 950 USDCx

4. Receiving an Inbound Stream​

Inbound Stream

Inbound Stream

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

  • Current Balance: 950 USDCx

5. Post Inbound Stream Time Elapse​

Post Inbound Stream

Post Inbound Stream

  • Time Elapsed: 1000 seconds

  • Current Balance: 970 USDCx

6. Deleting the Outbound Stream​

Deleting Outbound Stream

*Deleting Inbound Stream

  • Static Balance: 970 USDCx

  • Current Balance: 970 USDCx

Other Considerations​

Discrete Actions and Active Streams​

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

Interaction with Distributions​

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

Solvency and Sentinels​

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

Buffer​

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​

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.

Mini game

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!

Staking

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.

Metaverse

Introduction to the Metaverse of the Crypto Tagomi Project

Welcome to the Metaverse of the Crypto Tagomi project! We are excited to introduce a creative virtual space where users can interact, explore, and engage in various exciting activities within the blockchain world. Tagomi's Metaverse is not just a game or a social platform; it is a rich ecosystem that connects people through advanced technology.

1. Concept of Tagomi Metaverse

The Tagomi Metaverse is an interactive 3D space where users can create personal avatars and participate in diverse activities. Here, you can explore different areas, engage in role-playing games, socialize with the community, and even take part in virtual events. We aim to create an immersive and enriching experience, allowing users to fully enjoy the crypto world.

2. Key Features of Tagomi Metaverse

  • Social Interaction: Meet and connect with other crypto enthusiasts from around the world. Share ideas, strategies, and participate in lively discussions within the community.

  • Games and Activities: Join engaging games and other entertainment activities where you can earn rewards and enhance your skills.

  • NFT Marketplace: Explore and trade unique NFTs within the Metaverse, from characters and items to virtual real estate. This is an opportunity for you to invest and grow your assets in the virtual space.

3. Benefits of Participating in Tagomi Metaverse

  • Rich Experience: The Tagomi Metaverse offers a diverse and enriching experience where you can discover new and exciting things.

  • Connection Opportunities: Joining the Metaverse allows you to connect with a global crypto community, expanding your network and seeking collaboration opportunities.

  • Earning Potential: Through activities in the Metaverse, users can earn money from games, NFT trading, and participating in special events.

4. Conclusion

The Metaverse of the Crypto Tagomi project is a unique virtual space that combines blockchain technology with entertainment experiences. We invite you to join us on a journey of exploration, interaction, and development in a vibrant and captivating virtual world. Let’s build the Tagomi community together and experience the wonderful things that the Metaverse has to offer!

Tokenomics

TOKENOMIC:

  • Ticker: TGM

  • Token type: BEP-20

  • IDO Token Price: 3,000 TGM = 1 BNB

  • Total Tokens: 300,000,000

  • Smart Contract:

TOKEN DISTRIBUTION:

  • Advisors – 6%

  • Liquidity (DEX & CEX) – 10%

  • Liquidity mining – 5%

  • Ecosystem – 12%

  • Seed - 6%

  • Strategic pertnership – 9%

  • Community rewards – 5%

  • Pre-sale – 8%

  • Airdrop - 3%

  • Public listing – 3%

  • Reserve – 18%

  • Team – 15%

FUNDS ALLOCATION:

  • Operational – 16.7%

  • General costs – 8.3%

  • Initial liquidity – 15%

  • Marketing – 10%

  • Development – 50%

Airdrop

Tagomi ($TGM) Airdrop Announcement The Tagomi project is officially launching an exciting Airdrop program for the community with attractive rewards! To show our appreciation for the support, we are allocating 3% of the total supply of 300,000,000 $TGM, equivalent to 9,000,000 $TGM, as rewards for this Airdrop event.

1. Overview of the $TGM Airdrop

The Airdrop is a fantastic opportunity for users to participate and earn free $TGM tokens from the Tagomi project. Through this event, we aim to strengthen and grow our community.

2. How to Participate in the Airdrop

To join the Airdrop program, simply follow these steps:

  • Follow Tagomi's Official X Account: Make sure you're following us on X to stay updated on all important news.

  • Join the Official Telegram Community: Join our official Telegram group to stay in the loop about updates and events.

  • Complete the Required Tasks: Airdrop tasks may include sharing project information, inviting friends to join, and interacting with Tagomi’s posts on social media platforms.

  • Earn Points for Completing Tasks: Each completed task will earn participants points, and these points will later be converted into $TGM tokens based on the total number of points earned. The more tasks completed, the more points (and thus tokens) you can earn!

  • Fill Out the Airdrop Participation Form: Once you've completed the above steps, submit your information through the registration form so we can contact you and verify your eligibility.

3. Airdrop Reward Rules and Guidelines

  • Honesty: We ask all participants to be honest while participating in the Airdrop. Any form of cheating or creating fake accounts to gain an unfair advantage will result in disqualification.

  • Point-to-Token Conversion: Points accumulated during the Airdrop will be converted into $TGM tokens. These tokens will be distributed once the project launches its IDO (Initial DEX Offering) for $TGM. The more points you earn, the more $TGM tokens you'll receive!

  • Reward Announcement: The list of Airdrop reward recipients will be publicly announced on Tagomi’s official X account. Stay tuned so you don’t miss out!

  • Reward Distribution Timeline: $TGM rewards will be sent to participants' wallets after the event concludes and the winners are announced. Please be patient as we ensure prompt reward distribution.

  • Eligibility and Fairness: Everyone who participates has a chance to win, based on the number of tasks completed and the validity of the information provided.

4. Conclusion

Tagomi hopes that this Airdrop event will help the community grow and become stronger. It’s a great opportunity to earn valuable rewards and be a crucial part of the $TGM project. Complete tasks, earn points, and convert them into tokens when we launch our IDO!

Follow our X account and join the community channels for more details about this event. Thank you for your support, and get ready to join the Airdrop today!

Follow us on X for updates: @TAGOMI_Web3

Trading on Tagomi App

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!

Social & Community

Tagomi Protocol introduces innovative methods for community engagement and social token incentives, fostering long-term loyalty and participation.

Gradual Social Token Incentives​

Rather than distributing social tokens in a single airdrop, Tagomi enables a gradual, by-the-second streaming of tokens to community members or creator audiences.

Concept​

  • Long-Term Engagement: This model rewards ongoing loyalty and engagement, as opposed to immediate lump-sum airdrops.

  • Example: Consider the scenario where the longer an individual holds a community NFT, the more social tokens they accrue, discouraging immediate selling post-airdrop.

Explore this concept with the Reverb project, a platform that streams social tokens based on music listening habits.

Perpetual Conditional Rewards (PCR)​

The PCR model within the Tagomi Protocol offers a scalable way to incentivize community actions based on specific Key Performance Indicators (KPIs).

Mechanism​

  • Reward Distribution: Rewards are streamed to participants based on progress towards a KPI metric.

  • Funding and Execution: Funded through money streams and distributed using the Tagomi Instant Distribution Agreement, with KPI verification via UMA's KPI Options.

Perpetual Conditional Rewards

Perpetual Conditional Rewards

Use Cases​

  • Community Incentives: Communities can incentivize members for activities like increasing Twitter followers or GitHub repo stars.

  • Scalable Incentives: This system provides a method to reward members proportionally for contributing to communal goals.

For a deeper dive into the PCR concept, refer to this Twitter thread by UMAprotocol.

Tagomi's approach to social tokens and community incentives represents a shift towards more dynamic and engagement-focused reward systems in the digital space.

Pre-sale IDO

Tagomi Project Announces Pre-sale IDO for TGM Token!

Tagomi is excited to announce the upcoming Pre-sale IDO for our $TGM token, giving our valued partners, loyal customers, and supportive community an exclusive opportunity to purchase $TGM at an early stage. As part of this special event, we are allocating 8% of the total supply of 300,000,000 $TGM tokens, equivalent to 24,000,000 $TGM.

This Pre-sale IDO is a chance to become an early tor in the project and acquire tokens at a limited, discounted rate. Act fast, as token availability is limited, and the demand is high!

1. Pre-sale IDO Overview

The Pre-sale IDO (Initial DEX Offering) is an exclusive event that allows early access to $TGM tokens before they are fully listed on the public market. This is a golden opportunity for early supporters to own $TGM tokens and enjoy the long-term potential of the Tagomi project.

We are thrilled to reward our community and partners with this Pre-sale phase, as they have been instrumental in helping us build and shape Tagomi from the very beginning.

2. How to Purchase $TGM Tokens

To participate in the Pre-sale IDO and purchase $TGM tokens, please follow these steps on the official Tagomi website:

  1. Visit the Official Tagomi Website:

    • Go to https://tagomi.tech/, the official platform for all information and updates on the Tagomi project.

  2. Create an Account:

    • If you haven't already, register for an account on the Tagomi website. Ensure you provide accurate details and secure your account.

  3. Connect Your Wallet:

    • Once logged in, link your cryptocurrency wallet (such as MetaMask, Trust Wallet, or others) to the Tagomi platform. Make sure your wallet is loaded with supported cryptocurrencies (ETH, BNB, USDT, etc.) to complete the transaction.

  4. Access the Pre-sale IDO Section:

    • Navigate to the dedicated Pre-sale IDO section on the website. Here, you’ll find all the information regarding the token price, allocation limits, and current availability.

  5. Select the Amount of $TGM Tokens:

    • Choose how many $TGM tokens you wish to purchase, keeping in mind that there may be individual purchase limits due to the limited supply.

  6. Confirm and Complete the Purchase:

    • After selecting your desired amount, confirm the purchase. You will be prompted to approve the transaction from your wallet. Once the transaction is confirmed, you will receive your $TGM tokens directly in your linked wallet.

  7. Stay Updated:

    • After purchasing, keep an eye on updates through our website and social media channels for important information regarding token listing and the next steps in the project’s roadmap.

3. Why Participate in the Pre-sale IDO?

  • Exclusive Access: Get $TGM tokens before they are available to the public.

  • Discounted Pricing: Early participants can buy tokens at a special pre-sale price, which may increase when $TGM is listed on exchanges.

  • Limited Supply: Only 8% of the total token supply is available for the Pre-sale IDO, so don’t miss your chance to secure your share.

  • Support the Project: By participating in this early phase, you are directly contributing to the growth and development of Tagomi and its ecosystem.

4. Join the Tagomi Movement

The Pre-sale IDO for $TGM is a significant milestone for the Tagomi project, and we want you to be a part of it! As we continue to innovate and grow, holding $TGM tokens will give you access to various future benefits within the Tagomi ecosystem, from governance to exclusive features.

Visit the official website now: https://tagomi.tech/ and secure your $TGM tokens before they run out. Thank you for your continued trust and support!

Follow Tagomi for Updates:

Stay informed by following our official channels:

  • X: @TAGOMI_Web3

  • Telegram: Tagomi Telegram

Don’t miss your opportunity to be an early investor in one of the most promising projects of the year!

Pre-sale IDO 6 round

Round 1: 1 BNB = 3000 $TGM

Round 2: 1 BNB = 2850 $TGM

Round 3: 1BNB = 2700 $TGM

Round 4: 1BNB = 2550 $TGM

Round 5: 1BNB = 2400 $TGM

Round 6: 1BNB = 2250 $TGM

Super Apps

Super Apps represents a class of smart contracts that interact seamlessly with the Tagomi Protocol, enabling dynamic responses to Money streaming or Distributions (Also called Super Agreements).

Definition

Super Apps are smart contracts registered with the Tagomi Protocol, designed to react to Super Agreements. These reactions are facilitated through callbacks, allowing Super Apps to engage dynamically with the creation, modification, and termination of Super Agreements.

Reacting to Super Agreements

The reactivity of Super Apps stems from callbacks. These are segments of code within the Super App that are triggered when a Super Agreement involving the Super App is created, updated, or deleted. Such callbacks can execute various actions, from minting NFTs to initiating new Streams (Constant Flow Agreements).

Example - Stream Consolidator Super App

Consider a Super App designed to consolidate all incoming flows into a single outgoing flow to a specific account (Account Z):

  1. Incoming Flow from Account A: Account A initiates a Money Stream to the Super App (100 USDCx/mo). The Super App, in turn, starts an outbound Stream of the same rate to Account Z.

  2. Multiple Flow Adjustments: If Account B starts a new Money Stream to the Super App (25 USDCx/mo) and Account A adjusts its flow (to 50 USDCx/mo), the Super App responds by updating its outbound Streams accordingly.

  3. Ongoing Reactions: The Super App continues to adapt to new Money Streams or adjustments from various accounts, maintaining a reactive outbound flow.

info

NOTE: For a smart contract to qualify as a Super App, it must have defined callbacks to interact with Super Agreements.

Registering With The Protocol

Registration of a Super App with the Tagomi Protocol is crucial. This registration process involves coding the smart contract to be identifiable as a Super App within the protocol.

Purpose of Registration

  • Protocol Recognition: When a stream is initiated towards a contract, the Tagomi Protocol checks if the recipient is a registered Super App.

  • Callback Activation: If identified as a Super App, the protocol activates the Super App's callbacks, enabling its reactive capabilities.

Super App Registration

Why Are Super Apps Needed?

Super Apps introduce a layer of programmability to Super Agreements, enhancing the potential for innovative decentralized applications (dApps).

Potential Use Cases

  • Lending Applications: Automate loan repayments through Streams, eliminating the need for manual transactions.

  • Subscription Services: Enable on-chain subscriptions paid via Streams, incorporating features like automatic affiliate payouts.

Super Apps open up a realm of possibilities, combining custom logic with the functionalities of Super Agreements to craft unique and scalable dApps.

For further inspiration, explore the following examples of Super Apps:

Explore Super App Examples

Super Tokens

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.

Token-Cost-Averaging

Token-Cost-Averaging* (TCA) is one possible application designed to leverage the power of Tagomi streams. This application could allow the user to swap tokens in continuous real-time streams: stream in your Sell token and receive back the Buy token periodically.

What is Token-Cost-Averaging (TCA)?

Token-Cost-Averaging (TCA) is an investment strategy where an investor divides up the total amount to be invested across periodic purchases of a target asset (just like Dollar-Cost-Averaging but it's asset agnostic). This strategy gives users the best results over time by swapping tokens in continuous real-time streams: stream in your Sell token and receive back the Buy token periodically.

How does it work?

This application could be a new trading app powered by Tagomi. It could be designed to provide a more efficient and accessible way to perform Token-Cost-Averaging (TCA) by leveraging the power of Tagomi's streaming technology. Under the hood, the app would perform swaps time-continuously using a Time-Weighted Average Price (TWAP) oracle for liquidity source aggregation and a fair price over time.

The Tagomi Advantage

Compared to existing TCA or DCA (Dollar-Cost-Averaging) dApps built on other protocols, Tagomi offers several advantages:

  • Efficiency and Accessibility: Building on Money Streams makes TCA more efficient and accessible. By using Tagomi's streaming technology, it allows for continuous and automated investment flows, reducing the need for manual intervention and making investment more seamless and user-friendly.

  • Reduced Volatility Impact: The core idea of TCA is to mitigate the risks associated with volatile market conditions. Tagomi enhances this approach by allowing for more frequent and smaller investments, thereby further reducing the potential impact of sudden market changes.

  • Innovation in DeFi: By leveraging Tagomi's groundbreaking streaming technology, this TCA app stands at the forefront of innovation in decentralized finance, offering a unique approach to cryptocurrency investments.

Tagomi Host

The Tagomi Host Contract is a central element of the Tagomi Protocol, acting as a hub connecting Super Tokens, Super Agreements, and Super Apps

Tagomi Host Contract

Let's explore how the Host Contract interacts with different components of the Tagomi Protocol.

Super Agreements 🔗 Host Contract

Super Agreements, each with their unique contracts, interface with the Host Contract. Interaction with a Super Agreement is typically done by calling callAgreement() on the Host Contract, specifying the agreement and parameters.

Key Points

  • Upgradeability and Expansion: Super Agreements can be updated or new ones can be added and registered with the Host Contract.

info

NOTE: Direct interactions with Super Token contracts are not required for invoking Super Agreements. Instead, these agreements are accessed via the Host Contract, which then manages the Super Token balances involved.

Super Tokens 🔗 Host Contract

Super Tokens form the foundational layer of the Tagomi Protocol, where all Super Agreement data for an account is compiled.

Functionality

  • Aggregated Balance Calculation: The impact of each Super Agreement on an account's balance is cumulatively calculated to determine the Super Token balance.

  • Data Sourcing: Super Token contracts obtain necessary data through the Host Contract by iterating over the registered Super Agreements.

Super Apps 🔗 Host Contract

Registration of Super Apps with the Tagomi Host is essential to enable their callback functionalities.

Interaction Mechanics

  • Registration Requirement: Super Apps must be registered with the Host to function correctly.

  • Callback Activation: When a Super Agreement is engaged with a Super App, the Host Contract triggers the Super App's callbacks.

Super Apps and Host Contract

In summary, the Tagomi Host Contract is integral to the Tagomi Protocol, facilitating seamless interactions and integrations among Super Tokens, Super Agreements, and Super Apps.

What is Tagomi?

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.

​
​
​
​
​
​
​

SuperTokenV1Library

Library for Token Centric Interface

The SuperTokenV1Library is a solidity library that allows you to interact with the Tagomi Protocol. It is a comprehensive library for Tagomi protocol. It includes all the functions that are required to interact with the Tagomi protocol. It includes functions for interacting with Money Streaming and Distributions. In order to have access to the library, you need to:

  • Import the library in your contract as such:

    import "@Tagomi-finance/bsc-contracts/contracts/apps/SuperTokenV1Library.sol";

  • Make sure that you include the using statement in your contract:

    using SuperTokenV1Library for ISuperToken;

Note 1

In the case of interacting with Native Super Tokens you should use using SuperTokenV1Library for ISETH; instead.

Note 2

It is important to "warm up" the cache and cache the host, cfa, gda before calling, this is only applicable to Foundry tests where the vm.expectRevert() will not work as expected. You must use vm.startPrank(account) instead of vm.prank when executing functions if the cache isn't "warmed up" yet. vm.prank impersonates the account only for the first call, which will be used for caching.

Fn createFlow​

function createFlow(
    contract ISuperToken token,
    address receiver,
    int96 flowRate
) 
    internal 
    returns (bool)

Create flow without userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

Fn createFlow​

function createFlow(
    contract ISuperToken token,
    address receiver,
    int96 flowRate,
    bytes userData
) 
    internal 
    returns (bool)

Create flow with userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

userData

bytes

The userdata passed along with call

Fn updateFlow​

function updateFlow(
    contract ISuperToken token,
    address receiver,
    int96 flowRate
) 
    internal 
    returns (bool)

Update flow without userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

Fn updateFlow (w/userData)​

function updateFlow(
    contract ISuperToken token,
    address receiver,
    int96 flowRate,
    bytes userData
) 
    internal 
    returns (bool)

Update flow with userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

userData

bytes

The userdata passed along with call

Fn deleteFlow​

function deleteFlow(
    contract ISuperToken token,
    address sender,
    address receiver
) 
    internal 
    returns (bool)

Delete flow without userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

Fn deleteFlow (w/userData)​

function deleteFlow(
    contract ISuperToken token,
    address sender,
    address receiver,
    bytes userData
) 
    internal 
    returns (bool)

Delete flow with userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

userData

bytes

The userdata passed along with call

Fn setFlowPermissions​

function setFlowPermissions(
    contract ISuperToken token,
    address flowOperator,
    bool allowCreate,
    bool allowUpdate,
    bool allowDelete,
    int96 flowRateAllowance
) 
    internal 
    returns (bool)

Update permissions for flow operator

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address given flow permissions

allowCreate

bool

creation permissions

allowUpdate

bool

allowDelete

bool

flowRateAllowance

int96

The allowance provided to flowOperator

Fn setMaxFlowPermissions​

function setMaxFlowPermissions(
    contract ISuperToken token,
    address flowOperator
) 
    internal 
    returns (bool)

Update permissions for flow operator - give operator max permissions

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address given flow permissions

Fn revokeFlowPermissions​

function revokeFlowPermissions(
    contract ISuperToken token,
    address flowOperator
) 
    internal 
    returns (bool)

Update permissions for flow operator - revoke all permission

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address given flow permissions

Fn increaseFlowRateAllowance​

function increaseFlowRateAllowance(
    contract ISuperToken token,
    address flowOperator,
    int96 addedFlowRateAllowance
) 
    internal 
    returns (bool)

Increases the flow rate allowance for flow operator

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address whose flow rate allowance is increased

addedFlowRateAllowance

int96

amount to increase allowance by

allowing userData to be a parameter here triggered stack too deep error

Fn increaseFlowRateAllowance (w/userData)​

function increaseFlowRateAllowance(
    contract ISuperToken token,
    address flowOperator,
    int96 addedFlowRateAllowance,
    bytes userData
) 
    internal 
    returns (bool)

Increases the flow rate allowance for flow operator

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address whose flow rate allowance is increased

addedFlowRateAllowance

int96

amount to increase allowance by

userData

bytes

The userdata passed along with call

allowing userData to be a parameter here triggered stack too deep error

Fn decreaseFlowRateAllowance​

function decreaseFlowRateAllowance(
    contract ISuperToken token,
    address flowOperator,
    int96 subtractedFlowRateAllowance
) 
    internal 
    returns (bool)

Decreases the flow rate allowance for flow operator

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address whose flow rate allowance is decreased

subtractedFlowRateAllowance

int96

amount to decrease allowance by

allowing userData to be a parameter here triggered stack too deep error

Fn decreaseFlowRateAllowance (w/userData)​

function decreaseFlowRateAllowance(
    contract ISuperToken token,
    address flowOperator,
    int96 subtractedFlowRateAllowance,
    bytes userData
) 
    internal 
    returns (bool)

Decreases the flow rate allowance for flow operator

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address whose flow rate allowance is decreased

subtractedFlowRateAllowance

int96

amount to decrease allowance by

userData

bytes

The userdata passed along with call

allowing userData to be a parameter here triggered stack too deep error

Fn increaseFlowRateAllowanceWithPermissions​

function increaseFlowRateAllowanceWithPermissions(
    contract ISuperToken token,
    address flowOperator,
    uint8 permissionsToAdd,
    int96 addedFlowRateAllowance
) 
    internal 
    returns (bool)

Increases the flow rate allowance for flow operator and adds the permissions

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address whose flow rate allowance is increased

permissionsToAdd

uint8

The permissions to add for the flow operator

addedFlowRateAllowance

int96

amount to increase allowance by

allowing userData to be a parameter here triggered stack too deep error

Fn increaseFlowRateAllowanceWithPermissions (w/userData)​

function increaseFlowRateAllowanceWithPermissions(
    contract ISuperToken token,
    address flowOperator,
    uint8 permissionsToAdd,
    int96 addedFlowRateAllowance,
    bytes userData
) 
    internal 
    returns (bool)

Increases the flow rate allowance for flow operator and adds the permissions

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address whose flow rate allowance is increased

permissionsToAdd

uint8

The permissions to add for the flow operator

addedFlowRateAllowance

int96

amount to increase allowance by

userData

bytes

The userdata passed along with call

allowing userData to be a parameter here triggered stack too deep error

Fn decreaseFlowRateAllowanceWithPermissions​

function decreaseFlowRateAllowanceWithPermissions(
    contract ISuperToken token,
    address flowOperator,
    uint8 permissionsToRemove,
    int96 subtractedFlowRateAllowance
) 
    internal 
    returns (bool)

Decreases the flow rate allowance for flow operator and removes the permissions

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address whose flow rate allowance is subtracted

permissionsToRemove

uint8

The permissions to remove for the flow operator

subtractedFlowRateAllowance

int96

amount to subtract allowance by

allowing userData to be a parameter here triggered stack too deep error

Fn decreaseFlowRateAllowanceWithPermissions (w/userData)​

function decreaseFlowRateAllowanceWithPermissions(
    contract ISuperToken token,
    address flowOperator,
    uint8 permissionsToRemove,
    int96 subtractedFlowRateAllowance,
    bytes userData
) 
    internal 
    returns (bool)

Decreases the flow rate allowance for flow operator and removes the permissions

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address whose flow rate allowance is subtracted

permissionsToRemove

uint8

The permissions to remove for the flow operator

subtractedFlowRateAllowance

int96

amount to subtract allowance by

userData

bytes

The userdata passed along with call

allowing userData to be a parameter here triggered stack too deep error

Fn setFlowPermissionsWithCtx​

function setFlowPermissionsWithCtx(
    contract ISuperToken token,
    address flowOperator,
    bool allowCreate,
    bool allowUpdate,
    bool allowDelete,
    int96 flowRateAllowance,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Update permissions for flow operator in callback

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address given flow permissions

allowCreate

bool

creation permissions

allowUpdate

bool

allowDelete

bool

flowRateAllowance

int96

The allowance provided to flowOperator

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

allowing userData to be a parameter here triggered stack too deep error

Fn setMaxFlowPermissionsWithCtx​

function setMaxFlowPermissionsWithCtx(
    contract ISuperToken token,
    address flowOperator,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Update permissions for flow operator - give operator max permissions

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address given flow permissions

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn revokeFlowPermissionsWithCtx​

function revokeFlowPermissionsWithCtx(
    contract ISuperToken token,
    address flowOperator,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Update permissions for flow operator - revoke all permission

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowOperator

address

The address given flow permissions

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn createFlowFrom​

function createFlowFrom(
    contract ISuperToken token,
    address sender,
    address receiver,
    int96 flowRate
) 
    internal 
    returns (bool)

Creates flow as an operator without userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

Fn createFlowFrom (w/userData)​

function createFlowFrom(
    contract ISuperToken token,
    address sender,
    address receiver,
    int96 flowRate,
    bytes userData
) 
    internal 
    returns (bool)

Creates flow as an operator with userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

userData

bytes

The user provided data

Fn updateFlowFrom​

function updateFlowFrom(
    contract ISuperToken token,
    address sender,
    address receiver,
    int96 flowRate
) 
    internal 
    returns (bool)

Updates flow as an operator without userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

Fn updateFlowFrom (w/userData)​

function updateFlowFrom(
    contract ISuperToken token,
    address sender,
    address receiver,
    int96 flowRate,
    bytes userData
) 
    internal 
    returns (bool)

Updates flow as an operator with userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

userData

bytes

The user provided data

Fn deleteFlowFrom​

function deleteFlowFrom(
    contract ISuperToken token,
    address sender,
    address receiver
) 
    internal 
    returns (bool)

Deletes flow as an operator without userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

Fn deleteFlowFrom (w/userData)​

function deleteFlowFrom(
    contract ISuperToken token,
    address sender,
    address receiver,
    bytes userData
) 
    internal 
    returns (bool)

Deletes flow as an operator with userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

userData

bytes

The user provided data

Fn createFlowWithCtx​

function createFlowWithCtx(
    contract ISuperToken token,
    address receiver,
    int96 flowRate,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Create flow with context and userData

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn createFlowFromWithCtx​

function createFlowFromWithCtx(
    contract ISuperToken token,
    address sender,
    address receiver,
    int96 flowRate,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Create flow by operator with context

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn updateFlowWithCtx​

function updateFlowWithCtx(
    contract ISuperToken token,
    address receiver,
    int96 flowRate,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Update flow with context

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn updateFlowFromWithCtx​

function updateFlowFromWithCtx(
    contract ISuperToken token,
    address sender,
    address receiver,
    int96 flowRate,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Update flow by operator with context

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The receiver of the flow

receiver

address

The receiver of the flow

flowRate

int96

The desired flowRate

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn deleteFlowWithCtx​

function deleteFlowWithCtx(
    contract ISuperToken token,
    address sender,
    address receiver,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Delete flow with context

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn deleteFlowFromWithCtx​

function deleteFlowFromWithCtx(
    contract ISuperToken token,
    address sender,
    address receiver,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Delete flow by operator with context

Parameters​

Name
Type
Description

token

contract ISuperToken

The token to flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn getFlowRate​

function getFlowRate(
    contract ISuperToken token,
    address sender,
    address receiver
) 
    internal 
    returns (int96 flowRate)

get flow rate between two accounts for given token

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

Return Values​

Name
Type
Description

flowRate

int96

The flow rate

Fn getFlowInfo​

function getFlowInfo(
    contract ISuperToken token,
    address sender,
    address receiver
) 
    internal 
    returns (uint256 lastUpdated, int96 flowRate, uint256 deposit, uint256 owedDeposit)

get flow info between two accounts for given token

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

sender

address

The sender of the flow

receiver

address

The receiver of the flow

Return Values​

Name
Type
Description

lastUpdated

uint256

Timestamp of flow creation or last flowrate change

flowRate

int96

The flow rate

deposit

uint256

The amount of deposit the flow

owedDeposit

uint256

The amount of owed deposit of the flow

Fn getNetFlowRate​

function getNetFlowRate(
    contract ISuperToken token,
    address account
) 
    internal 
    returns (int96 flowRate)

get net flow rate for given account for given token (CFA + GDA)

Parameters​

Name
Type
Description

token

contract ISuperToken

Super token address

account

address

Account to query

Return Values​

Name
Type
Description

flowRate

int96

The net flow rate of the account

Fn getCFANetFlowRate​

function getCFANetFlowRate(
    contract ISuperToken token,
    address account
) 
    internal 
    returns (int96 flowRate)

get CFA net flow rate for given account for given token

Parameters​

Name
Type
Description

token

contract ISuperToken

Super token address

account

address

Account to query

Return Values​

Name
Type
Description

flowRate

int96

The net flow rate of the account

Fn getGDANetFlowRate​

function getGDANetFlowRate(
    contract ISuperToken token,
    address account
) 
    internal 
    returns (int96 flowRate)

get GDA net flow rate for given account for given token

Parameters​

Name
Type
Description

token

contract ISuperToken

Super token address

account

address

Account to query

Return Values​

Name
Type
Description

flowRate

int96

The net flow rate of the account

Fn getNetFlowInfo​

function getNetFlowInfo(
    contract ISuperToken token,
    address account
) 
    internal 
    returns (uint256 lastUpdated, int96 flowRate, uint256 deposit, uint256 owedDeposit)

get the aggregated flow info of the account

Parameters​

Name
Type
Description

token

contract ISuperToken

Super token address

account

address

Account to query

Return Values​

Name
Type
Description

lastUpdated

uint256

Timestamp of the last change of the net flow

flowRate

int96

The net flow rate of token for account

deposit

uint256

The sum of all deposits for account's flows

owedDeposit

uint256

The sum of all owed deposits for account's flows

Fn getBufferAmountByFlowRate​

function getBufferAmountByFlowRate(
    contract ISuperToken token,
    int96 flowRate
) 
    internal 
    returns (uint256 bufferAmount)

calculate buffer for a flow rate

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

flowRate

int96

The flowrate to calculate the needed buffer for

Return Values​

Name
Type
Description

bufferAmount

uint256

The buffer amount based on flowRate, liquidationPeriod and minimum deposit

Fn getFlowPermissions​

function getFlowPermissions(
    contract ISuperToken token,
    address sender,
    address flowOperator
) 
    internal 
    returns (bool allowCreate, bool allowUpdate, bool allowDelete, int96 flowRateAllowance)

get existing flow permissions

Parameters​

Name
Type
Description

token

contract ISuperToken

The token used in flow

sender

address

sender of a flow

flowOperator

address

the address we are checking permissions of for sender & token

Return Values​

Name
Type
Description

allowCreate

bool

is true if the flowOperator can create flows

allowUpdate

bool

is true if the flowOperator can update flows

allowDelete

bool

is true if the flowOperator can delete flows

flowRateAllowance

int96

The flow rate allowance the flowOperator is granted (only goes down)

Fn getIndex​

function getIndex(
    contract ISuperToken token,
    address publisher,
    uint32 indexId
) 
    internal 
    returns (bool exist, uint128 indexValue, uint128 totalUnitsApproved, uint128 totalUnitsPending)

Gets an index by its ID and publisher.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

Return Values​

Name
Type
Description

exist

bool

True if the index exists.

indexValue

uint128

Total value of the index.

totalUnitsApproved

uint128

Units of the index approved by subscribers.

totalUnitsPending

uint128

Units of teh index not yet approved by subscribers.

Fn calculateDistribution​

function calculateDistribution(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    uint256 amount
) 
    internal 
    returns (uint256 actualAmount, uint128 newIndexValue)

Calculates the distribution amount based on the amount of tokens desired to distribute.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

amount

uint256

Amount of tokens desired to distribute.

Return Values​

Name
Type
Description

actualAmount

uint256

Amount to be distributed with correct rounding.

newIndexValue

uint128

The index value after the distribution would be called.

Fn listSubscriptions​

function listSubscriptions(
    contract ISuperToken token,
    address subscriber
) 
    internal 
    returns (address[] publishers, uint32[] indexIds, uint128[] unitsList)

List all subscriptions of an address

Parameters​

Name
Type
Description

token

contract ISuperToken

Super token used in the indexes listed.

subscriber

address

Subscriber address.

Return Values​

Name
Type
Description

publishers

address[]

Publishers of the indices.

indexIds

uint32[]

IDs of the indices.

unitsList

uint128[]

Units owned of the indices.

Fn getSubscription​

function getSubscription(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    address subscriber
) 
    internal 
    returns (bool exist, bool approved, uint128 units, uint256 pendingDistribution)

Gets subscription by publisher, index id, and subscriber.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber to the index.

Return Values​

Name
Type
Description

exist

bool

True if the subscription exists.

approved

bool

True if the subscription has been approved by the subscriber.

units

uint128

Units held by the subscriber

pendingDistribution

uint256

If not approved, the amount to be claimed on approval.

Fn getSubscriptionByID​

function getSubscriptionByID(
    contract ISuperToken token,
    bytes32 agreementId
) 
    internal 
    returns (address publisher, uint32 indexId, bool approved, uint128 units, uint256 pendingDistribution)

Parameters​

Name
Type
Description

token

contract ISuperToken

agreementId

bytes32

Fn getFlowDistributionFlowRate​

function getFlowDistributionFlowRate(
    contract ISuperToken token,
    address from,
    contract ITagomiPool to
) 
    internal 
    returns (int96)

Parameters​

Name
Type
Description

token

contract ISuperToken

from

address

to

contract ITagomiPool

GDA VIEW FUNCTIONS *************************************

Fn estimateFlowDistributionActualFlowRate​

function estimateFlowDistributionActualFlowRate(
    contract ISuperToken token,
    address from,
    contract ITagomiPool to,
    int96 requestedFlowRate
) 
    internal 
    returns (int96 actualFlowRate, int96 totalDistributionFlowRate)

Parameters​

Name
Type
Description

token

contract ISuperToken

from

address

to

contract ITagomiPool

requestedFlowRate

int96

Fn estimateDistributionActualAmount​

function estimateDistributionActualAmount(
    contract ISuperToken token,
    address from,
    contract ITagomiPool to,
    uint256 requestedAmount
) 
    internal 
    returns (uint256 actualAmount)

Parameters​

Name
Type
Description

token

contract ISuperToken

from

address

to

contract ITagomiPool

requestedAmount

uint256

Fn isMemberConnected​

function isMemberConnected(
    contract ISuperToken token,
    address pool,
    address member
) 
    internal 
    returns (bool)

Parameters​

Name
Type
Description

token

contract ISuperToken

pool

address

member

address

Fn createIndex​

function createIndex(
    contract ISuperToken token,
    uint32 indexId
) 
    internal 
    returns (bool)

Creates a new index.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

Fn createIndex​

function createIndex(
    contract ISuperToken token,
    uint32 indexId,
    bytes userData
) 
    internal 
    returns (bool)

Creates a new index with userData.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

userData

bytes

Arbitrary user data field.

Fn updateIndexValue​

function updateIndexValue(
    contract ISuperToken token,
    uint32 indexId,
    uint128 indexValue
) 
    internal 
    returns (bool)

Updates an index value. This distributes an amount of tokens equal to indexValue - lastIndexValue. See distribute for another way to distribute.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

indexValue

uint128

New TOTAL index value, this will equal the total amount distributed.

Fn updateIndexValue​

function updateIndexValue(
    contract ISuperToken token,
    uint32 indexId,
    uint128 indexValue,
    bytes userData
) 
    internal 
    returns (bool)

Updates an index value with userData. This distributes an amount of tokens equal to indexValue - lastIndexValue. See distribute for another way to distribute.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

indexValue

uint128

New TOTAL index value, this will equal the total amount distributed.

userData

bytes

Arbitrary user data field.

Fn distribute​

function distribute(
    contract ISuperToken token,
    uint32 indexId,
    uint256 amount
) 
    internal 
    returns (bool)

Distributes tokens in a more developer friendly way than updateIndex. Instead of passing the new total index value, you pass the amount of tokens desired to be distributed.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

amount

uint256

- total number of tokens desired to be distributed

NOTE in many cases, there can be some precision loss

This may cause a slight difference in the amount param specified and the actual amount distributed.

See below for math:

//indexDelta = amount the index will be updated by during an internal call to _updateIndex().

It is calculated like so:

indexDelta = amount / totalUnits

(see the distribute() implementatation in ./agreements/InstantDistributionAgreement.sol)

NOTE Solidity does not support floating point numbers

So the indexDelta will be rounded down to the nearest integer.

This will create a 'remainder' amount of tokens that will not be distributed

(we'll call this the 'distribution modulo')

distributionModulo = amount - indexDelta * totalUnits

NOTE due to rounding, there may be a small amount of tokens left in the publisher's account

This amount is equal to the 'distributionModulo' value

//

Fn distribute (w/userData)​

function distribute(
    contract ISuperToken token,
    uint32 indexId,
    uint256 amount,
    bytes userData
) 
    internal 
    returns (bool)

Distributes tokens in a more developer friendly way than updateIndex (w user data). Instead of passing the new total index value, this function will increase the index value by amount. This takes arbitrary user data.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

amount

uint256

Amount by which the index value should increase.

userData

bytes

Arbitrary user data field.

Fn approveSubscription​

function approveSubscription(
    contract ISuperToken token,
    address publisher,
    uint32 indexId
) 
    internal 
    returns (bool)

Approves a subscription to an index. The subscriber's real time balance will not update until the subscription is approved, but once approved, the balance will be updated with prior distributions.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

Fn approveSubscription (w/userData)​

function approveSubscription(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    bytes userData
) 
    internal 
    returns (bool)

Approves a subscription to an index with user data. The subscriber's real time balance will not update until the subscription is approved, but once approved, the balance will be updated with prior distributions.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

userData

bytes

Arbitrary user data field.

Fn revokeSubscription​

function revokeSubscription(
    contract ISuperToken token,
    address publisher,
    uint32 indexId
) 
    internal 
    returns (bool)

Revokes a previously approved subscription.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

Fn revokeSubscription (w/userData)​

function revokeSubscription(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    bytes userData
) 
    internal 
    returns (bool)

Revokes a previously approved subscription. This takes arbitrary user data.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

userData

bytes

Arbitrary user data field.

Fn updateSubscriptionUnits​

function updateSubscriptionUnits(
    contract ISuperToken token,
    uint32 indexId,
    address subscriber,
    uint128 units
) 
    internal 
    returns (bool)

Updates the units of a subscription. This changes the number of shares the subscriber holds

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber address whose units are to be updated.

units

uint128

New number of units the subscriber holds.

Fn updateSubscriptionUnits (w/userData)​

function updateSubscriptionUnits(
    contract ISuperToken token,
    uint32 indexId,
    address subscriber,
    uint128 units,
    bytes userData
) 
    internal 
    returns (bool)

Updates the units of a subscription. This changes the number of shares the subscriber holds. This takes arbitrary user data.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber address whose units are to be updated.

units

uint128

New number of units the subscriber holds.

userData

bytes

Arbitrary user data field.

Fn deleteSubscription​

function deleteSubscription(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    address subscriber
) 
    internal 
    returns (bool)

Deletes a subscription, setting a subcriber's units to zero

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber address whose units are to be deleted.

Fn deleteSubscription (w/userData)​

function deleteSubscription(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    address subscriber,
    bytes userData
) 
    internal 
    returns (bool)

Deletes a subscription, setting a subcriber's units to zero. This takes arbitrary userdata.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber address whose units are to be deleted.

userData

bytes

Arbitrary user data field.

Fn claim​

function claim(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    address subscriber
) 
    internal 
    returns (bool)

Claims pending distribution. Subscription should not be approved

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber address that receives the claim.

Fn claim (w/userData)​

function claim(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    address subscriber,
    bytes userData
) 
    internal 
    returns (bool)

Claims pending distribution. Subscription should not be approved. This takes arbitrary user data.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber address that receives the claim.

userData

bytes

Arbitrary user data field.

Fn createIndexWithCtx​

function createIndexWithCtx(
    contract ISuperToken token,
    uint32 indexId,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Creates a new index with ctx. Meant for usage in super app callbacks

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn updateIndexValueWithCtx​

function updateIndexValueWithCtx(
    contract ISuperToken token,
    uint32 indexId,
    uint128 indexValue,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Updates an index value with ctx. This distributes an amount of tokens equal to indexValue - lastIndexValue. See distribute for another way to distribute. Meant for usage in super app callbakcs

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

indexValue

uint128

New TOTAL index value, this will equal the total amount distributed.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn distributeWithCtx​

function distributeWithCtx(
    contract ISuperToken token,
    uint32 indexId,
    uint256 amount,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Distributes tokens in a more developer friendly way than updateIndex.Instead of passing the new total index value, this function will increase the index value by amount.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

amount

uint256

Amount by which the index value should increase.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn approveSubscriptionWithCtx​

function approveSubscriptionWithCtx(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Approves a subscription to an index. The subscriber's real time balance will not update until the subscription is approved, but once approved, the balance will be updated with prior distributions.

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn revokeSubscriptionWithCtx​

function revokeSubscriptionWithCtx(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Revokes a previously approved subscription. Meant for usage in super apps

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn updateSubscriptionUnitsWithCtx​

function updateSubscriptionUnitsWithCtx(
    contract ISuperToken token,
    uint32 indexId,
    address subscriber,
    uint128 units,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Updates the units of a subscription. This changes the number of shares the subscriber holds. Meant for usage in super apps

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber address whose units are to be updated.

units

uint128

New number of units the subscriber holds.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn deleteSubscriptionWithCtx​

function deleteSubscriptionWithCtx(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    address subscriber,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Deletes a subscription, setting a subcriber's units to zero. Meant for usage in super apps

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber address whose units are to be deleted.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn claimWithCtx​

function claimWithCtx(
    contract ISuperToken token,
    address publisher,
    uint32 indexId,
    address subscriber,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Claims pending distribution. Subscription should not be approved. Meant for usage in super app callbacks

Parameters​

Name
Type
Description

token

contract ISuperToken

Super Token used with the index.

publisher

address

Publisher of the index.

indexId

uint32

ID of the index.

subscriber

address

Subscriber address that receives the claim.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn createPool​

function createPool(
    contract ISuperToken token,
    address admin,
    struct PoolConfig poolConfig
) 
    internal 
    returns (contract ITagomiPool pool)

Creates a new Tagomi Pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

admin

address

The pool admin address.

poolConfig

struct PoolConfig

The pool configuration (see below)

The PoolConfig struct is defined as follows:

struct PoolConfig {
    bool transferabilityForUnitsOwner;
    bool distributionFromAnyAddress;
}
  • transferabilityForUnitsOwner: If true, the pool members can transfer their owned units, else, only the pool admin can manipulate the units for pool members (not recommended)

  • distributionFromAnyAddress: If true, anyone can execute distributions via the pool, else, only the pool admin can execute distributions via the pool

Return Values​

Name
Type
Description

pool

contract ITagomiPool

The address of the deployed Tagomi Pool

Fn updateMemberUnits​

function updateMemberUnits(
    contract ISuperToken token,
    contract ITagomiPool pool,
    address memberAddress,
    uint128 newUnits
) 
    internal 
    returns (bool)

Updates the units of a pool member.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to update.

memberAddress

address

The address of the member to update.

newUnits

uint128

The new units of the member.

Return Values​

Name
Type
Description

[0]

bool

bool A boolean value indicating whether the pool was created successfully.

Fn updateMemberUnits (w/userData)​

function updateMemberUnits(
    contract ISuperToken token,
    contract ITagomiPool pool,
    address memberAddress,
    uint128 newUnits,
    bytes userData
) 
    internal 
    returns (bool)

Updates the units of a pool member.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to update.

memberAddress

address

The address of the member to update.

newUnits

uint128

The new units of the member.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the pool was created successfully.

Fn claimAll​

function claimAll(
    contract ISuperToken token,
    contract ITagomiPool pool,
    address memberAddress
) 
    internal 
    returns (bool)

Claims all tokens from the pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to claim from.

memberAddress

address

The address of the member to claim for.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the claim was successful.

Fn claimAll (w/userData)​

function claimAll(
    contract ISuperToken token,
    contract ITagomiPool pool,
    address memberAddress,
    bytes userData
) 
    internal 
    returns (bool)

Claims all tokens from the pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to claim from.

memberAddress

address

The address of the member to claim for.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the claim was successful.

Fn connectPool​

function connectPool(
    contract ISuperToken token,
    contract ITagomiPool pool
) 
    internal 
    returns (bool)

Connects a pool member to pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to connect.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the connection was successful.

Fn connectPool (w/userData)​

function connectPool(
    contract ISuperToken token,
    contract ITagomiPool pool,
    bytes userData
) 
    internal 
    returns (bool)

Connects a pool member to pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to connect.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the connection was successful.

Fn disconnectPool​

function disconnectPool(
    contract ISuperToken token,
    contract ITagomiPool pool
) 
    internal 
    returns (bool)

Disconnects a pool member from pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to disconnect.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the disconnection was successful.

Fn disconnectPool (w/userData)​

function disconnectPool(
    contract ISuperToken token,
    contract ITagomiPool pool,
    bytes userData
) 
    internal 
    returns (bool)

Disconnects a pool member from pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to disconnect.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the disconnection was successful.

Fn distributeToPool​

function distributeToPool(
    contract ISuperToken token,
    address from,
    contract ITagomiPool pool,
    uint256 requestedAmount
) 
    internal 
    returns (bool)

Tries to distribute requestedAmount amount of token from from to pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

from

address

The address from which to distribute tokens.

pool

contract ITagomiPool

The Tagomi Pool address.

requestedAmount

uint256

The amount of tokens to distribute.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the distribution was successful.

Fn distribute (w/userData)​

function distribute(
    contract ISuperToken token,
    address from,
    contract ITagomiPool pool,
    uint256 requestedAmount,
    bytes userData
) 
    internal 
    returns (bool)

Tries to distribute requestedAmount amount of token from from to pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

from

address

The address from which to distribute tokens.

pool

contract ITagomiPool

The Tagomi Pool address.

requestedAmount

uint256

The amount of tokens to distribute.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the distribution was successful.

Fn distributeFlow​

function distributeFlow(
    contract ISuperToken token,
    address from,
    contract ITagomiPool pool,
    int96 requestedFlowRate
) 
    internal 
    returns (bool)

Tries to distribute flow at requestedFlowRate of token from from to pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

from

address

The address from which to distribute tokens.

pool

contract ITagomiPool

The Tagomi Pool address.

requestedFlowRate

int96

The flow rate of tokens to distribute.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the distribution was successful.

Fn distributeFlow (w/userData)​

function distributeFlow(
    contract ISuperToken token,
    address from,
    contract ITagomiPool pool,
    int96 requestedFlowRate,
    bytes userData
) 
    internal 
    returns (bool)

Tries to distribute flow at requestedFlowRate of token from from to pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

from

address

The address from which to distribute tokens.

pool

contract ITagomiPool

The Tagomi Pool address.

requestedFlowRate

int96

The flow rate of tokens to distribute.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the distribution was successful.

Fn updateMemberUnitsWithCtx​

function updateMemberUnitsWithCtx(
    contract ISuperToken token,
    contract ITagomiPool pool,
    address memberAddress,
    uint128 newUnits,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Updates the units of a pool member.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to update.

memberAddress

address

The address of the member to update.

newUnits

uint128

The new units of the member.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn claimAllWithCtx​

function claimAllWithCtx(
    contract ISuperToken token,
    contract ITagomiPool pool,
    address memberAddress,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Claims all tokens from the pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to claim from.

memberAddress

address

The address of the member to claim for.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn connectPoolWithCtx​

function connectPoolWithCtx(
    contract ISuperToken token,
    contract ITagomiPool pool,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Connects a pool member to pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The Tagomi Pool to connect.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn disconnectPoolWithCtx​

function disconnectPoolWithCtx(
    contract ISuperToken token,
    contract ITagomiPool pool,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Disconnects a pool member from pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

pool

contract ITagomiPool

The STagomi Pool to disconnect.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn distributeWithCtx​

function distributeWithCtx(
    contract ISuperToken token,
    address from,
    contract ITagomiPool pool,
    uint256 requestedAmount,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Tries to distribute requestedAmount amount of token from from to pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

from

address

The address from which to distribute tokens.

pool

contract ITagomiPool

The Tagomi Pool address.

requestedAmount

uint256

The amount of tokens to distribute.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

Fn distributeFlowWithCtx​

function distributeFlowWithCtx(
    contract ISuperToken token,
    address from,
    contract ITagomiPool pool,
    int96 requestedFlowRate,
    bytes ctx
) 
    internal 
    returns (bytes newCtx)

Tries to distribute flow at requestedFlowRate of token from from to pool.

Parameters​

Name
Type
Description

token

contract ISuperToken

The Super Token address.

from

address

The address from which to distribute tokens.

pool

contract ITagomiPool

The Tagomi Pool address.

requestedFlowRate

int96

The flow rate of tokens to distribute.

ctx

bytes

Context bytes (see ITagomi.sol for Context struct)

Return Values​

Name
Type
Description

newCtx

bytes

The updated context after the execution of the agreement function

ITagomiPool

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​

Name
Type
Description

token

contract ITagomiToken

member

address

oldUnits

uint128

newUnits

uint128

Event DistributionClaimed​

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

Parameters​

Name
Type
Description

token

contract ITagomiToken

member

address

claimedAmount

int256

totalClaimed

int256

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​

Name
Type
Description

memberAddress

address

The address of the member

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​

Name
Type
Description

time

uint32

The time to query

The balance of all the disconnected members at time

Fn getMemberFlowRate​

function getMemberFlowRate(
    address memberAddress
) 
    external 
    returns (int96)

Parameters​

Name
Type
Description

memberAddress

address

The address of the member

The flow rate a member is receiving from the pool

Fn getClaimable​

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

Parameters​

Name
Type
Description

memberAddr

address

The address of the member

time

uint32

The time to query

The claimable balance for memberAddr at time in the pool

Fn getClaimableNow​

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

Parameters​

Name
Type
Description

memberAddr

address

The address of the member

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

Fn updateMemberUnits​

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

Parameters​

Name
Type
Description

memberAddr

address

The address of the member

newUnits

uint128

The new units for the member

Sets memberAddr ownedUnits to newUnits

Fn claimAll​

function claimAll(
    address memberAddr
) 
    external 
    returns (bool)

Parameters​

Name
Type
Description

memberAddr

address

The address of the member

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​

Name
Type
Description

spender

address

The address of the spender

addedValue

uint256

The amount to increase the allowance by

Return Values​

Name
Type
Description

[0]

bool

true if successful

Increases the allowance of spender by addedValue

Fn decreaseAllowance​

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

Parameters​

Name
Type
Description

spender

address

The address of the spender

subtractedValue

uint256

The amount to decrease the allowance by

Return Values​

Name
Type
Description

[0]

bool

true if successful

Decreases the allowance of spender by subtractedValue

Glossary of Terms

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

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:

Click here to show ISETH ABI

Fn upgradeByETH​

function upgradeByETH(
) 
    external

Fn upgradeByETHTo​

function upgradeByETHTo(
    address to
) 
    external

Parameters​

Name
Type
Description

to

address

Fn downgradeToETH​

function downgradeToETH(
    uint256 wad
) 
    external

Parameters​

Name
Type
Description

wad

uint256

ISETH

Super ETH (SETH) full interface

GDAv1Forwarder

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:

Click here to show GDAv1Forwarder ABI

_gda​

contract IGeneralDistributionAgreementV1 _gda

Fn constructor​

function constructor(
    contract ITagomi host
)
    public

Parameters​

Name
Type
Description

host

contract ITagomi

Fn createPool​

createPool() write

Try it out

function createPool(address token, address admin, tuple config) nonpayable returns (bool success, address pool)

powered byLearn more

Creates a new Tagomi Pool.

Parameters​

Name
Type
Description

token

contract ITagomiToken

The Super Token address.

admin

address

The pool admin address.

config

struct PoolConfig

The pool configuration (see PoolConfig in IGeneralDistributionAgreementV1.sol)

Return Values​

Name
Type
Description

success

bool

A boolean value indicating whether the pool was created successfully.

pool

contract ITagomiPool

The address of the deployed Tagomi Pool

Fn updateMemberUnits​

updateMemberUnits() write

Try it out

function updateMemberUnits(
  address pool, 
  address memberAddress, 
  uint128 newUnits, 
  bytes userData
) nonpayable returns (bool success)

powered byLearn more

Updates the units of a pool member.

Parameters​

Name
Type
Description

pool

contract ITagomiPool

The Tagomi Pool to update.

memberAddress

address

The address of the member to update.

newUnits

uint128

The new units of the member.

userData

bytes

User-specific data.

Fn claimAll​

claimAll() write

Try it out

function claimAll(address pool, address memberAddress, bytes userData) nonpayable returns (bool success)

powered byLearn more

Claims all tokens from the pool.

Parameters​

Name
Type
Description

pool

contract ITagomiPool

The Tagomi Pool to claim from.

memberAddress

address

The address of the member to claim for.

userData

bytes

User-specific data.

Fn connectPool​

connectPool() write

Try it out

function connectPool(address pool, bytes userData) nonpayable returns (bool)

powered byLearn more

Connects a pool member to pool.

Parameters​

Name
Type
Description

pool

contract ITagomiPool

The Tagomi Pool to connect.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the connection was successful.

Fn disconnectPool​

disconnectPool() write

Try it out

function disconnectPool(address pool, bytes userData) nonpayable returns (bool)

powered byLearn more

Disconnects a pool member from pool.

Parameters​

Name
Type
Description

pool

contract ITagomiPool

The Tagomi Pool to disconnect.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the disconnection was successful.

Fn distribute​

distribute() write

Try it out

function distribute(
  address token, 
  address from, 
  address pool, 
  uint256 requestedAmount, 
  bytes userData
) nonpayable returns (bool)

powered byLearn more

Tries to distribute requestedAmount amount of token from from to pool.

Parameters​

Name
Type
Description

token

contract ITagomiToken

The Super Token address.

from

address

The address from which to distribute tokens.

pool

contract ITagomiPool

The Tagomi Pool address.

requestedAmount

uint256

The amount of tokens to distribute.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the distribution was successful.

Fn distributeFlow​

distributeFlow() write

Try it out

function distributeFlow(
  address token, 
  address from, 
  address pool, 
  int96 requestedFlowRate, 
  bytes userData
) nonpayable returns (bool)

powered byLearn more

Tries to distribute flow at requestedFlowRate of token from from to pool.

Parameters​

Name
Type
Description

token

contract ITagomiToken

The Super Token address.

from

address

The address from which to distribute tokens.

pool

contract ITagomiPool

The Tagomi Pool address.

requestedFlowRate

int96

The flow rate of tokens to distribute.

userData

bytes

User-specific data.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the distribution was successful.

Fn isPool​

isPool() read

Try it out

function isPool(address token, address account) view returns (bool)

powered byLearn more

Checks if the specified account is a pool.

Parameters​

Name
Type
Description

token

contract ITagomiToken

The Super Token address.

account

address

The account address to check.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the account is a pool.

Fn getNetFlow​

getNetFlow() read

Try it out

function getNetFlow(address token, address account) view returns (int96)

powered byLearn more

Gets the GDA net flow rate for the specified account.

Parameters​

Name
Type
Description

token

contract ITagomiToken

The Super Token address.

account

address

The account address.

Return Values​

Name
Type
Description

[0]

int96

The gda net flow rate for the account.

Fn getFlowDistributionFlowRate​

getFlowDistributionFlowRate() read

Try it out

function getFlowDistributionFlowRate(address token, address from, address to) view returns (int96)

powered byLearn more

Gets the flow rate of tokens between the specified accounts.

Parameters​

Name
Type
Description

token

contract ITagomiToken

The Super Token address.

from

address

The sender address.

to

contract ITagomiPool

The receiver address (the pool address).

Return Values​

Name
Type
Description

[0]

int96

The flow distribution flow rate

Fn getPoolAdjustmentFlowRate​

getPoolAdjustmentFlowRate() read

Try it out

function getPoolAdjustmentFlowRate(address pool) view returns (int96)

powered byLearn more

Gets the pool adjustment flow rate for the specified pool.

Parameters​

Name
Type
Description

pool

address

The pool address.

Return Values​

Name
Type
Description

[0]

int96

The pool adjustment flow rate.

Fn estimateFlowDistributionActualFlowRate​

estimateFlowDistributionActualFlowRate() read

Try it out

function estimateFlowDistributionActualFlowRate(
  address token, 
  address from, 
  address to, 
  int96 requestedFlowRate
) view returns (
  int96 actualFlowRate, 
  int96 totalDistributionFlowRate
)

powered byLearn more

Estimates the actual flow rate for flow distribution to the specified pool.

Parameters​

Name
Type
Description

token

contract ITagomiToken

The Super Token address.

from

address

The sender address.

to

contract ITagomiPool

The pool address.

requestedFlowRate

int96

The requested flow rate.

Return Values​

Name
Type
Description

actualFlowRate

int96

totalDistributionFlowRate

int96

Fn estimateDistributionActualAmount​

estimateDistributionActualAmount() read

Try it out

function estimateDistributionActualAmount(
  address token, 
  address from, 
  address to, 
  uint256 requestedAmount
) view returns (uint256 actualAmount)

powered byLearn more

Estimates the actual amount for distribution to the specified pool.

Parameters​

Name
Type
Description

token

contract ITagomiToken

The Super Token address.

from

address

The sender address.

to

contract ITagomiPool

The pool address.

requestedAmount

uint256

The requested amount.

Return Values​

Name
Type
Description

actualAmount

uint256

The actual amount for distribution.

Fn isMemberConnected​

isMemberConnected() read

Try it out

function isMemberConnected(address pool, address member) view returns (bool)

powered byLearn more

Checks if the specified member is connected to the pool.

Parameters​

Name
Type
Description

pool

contract ITagomiPool

The Tagomi Pool address.

member

address

The member address.

Return Values​

Name
Type
Description

[0]

bool

A boolean value indicating whether the member is connected to the pool.

Fn getPoolAdjustmentFlowInfo​

getPoolAdjustmentFlowInfo() read

Try it out

function getPoolAdjustmentFlowInfo(address pool) view returns (address, bytes32, int96)

powered byLearn more

Gets the pool adjustment flow information for the specified pool.

Parameters​

Name
Type
Description

pool

contract ITagomiPool

The pool address.

Return Values​

Name
Type
Description

[0]

address

The pool admin, pool ID, and pool adjustment flow rate.

[1]

bytes32

[2]

int96

CFAv1Forwarder

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:

Click here to show CFAv1Forwarder 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​

Name
Type
Description

host

contract ITagomi

Fn setFlowrate​

setFlowrate() write

Try it out

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

powered byLearn more

Parameters​

Name
Type
Description

token

contract ISuperToken

Super token address

receiver

address

The receiver of the flow

flowrate

int96

The wanted flowrate in wad/second. Only positive values are valid here.

Return Values​

Name
Type
Description

[0]

bool

bool

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​

Name
Type
Description

token

contract ISuperToken

Super token address

sender

address

The sender of the flow

receiver

address

The receiver of the flow

flowrate

int96

The wanted flowrate in wad/second. Only positive values are valid here.

Return Values​

Name
Type
Description

[0]

bool

bool

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​

Name
Type
Description

token

contract ISuperToken

Super token address

sender

address

The sender of the flow

receiver

address

The receiver of the flow

Return Values​

Name
Type
Description

flowrate

int96

The flowrate from the sender to the receiver account. Returns 0 if no flow exists.

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​

Name
Type
Description

token

contract ISuperToken

Super token address

sender

address

The sender of the flow

receiver

address

The receiver of the flow

Return Values​

Name
Type
Description

lastUpdated

uint256

Timestamp of last update (flowrate change) or zero if no flow exists

flowrate

int96

Current flowrate of the flow or zero if no flow exists

deposit

uint256

Deposit amount locked as security buffer during the lifetime of the flow

owedDeposit

uint256

Extra deposit amount borrowed to a SuperApp receiver by the flow sender

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​

Name
Type
Description

token

contract ISuperToken

Super token address

flowrate

int96

The flowrate for which the buffer amount is calculated

Return Values​

Name
Type
Description

bufferAmount

uint256

The buffer amount required for the given configuration.

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​

Name
Type
Description

token

contract ISuperToken

Super token address

account

address

Account to query

Return Values​

Name
Type
Description

flowrate

int96

The net flowrate (aggregate incoming minus aggregate outgoing flowrate), can be negative.

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​

Name
Type
Description

token

contract ISuperToken

Super token address

account

address

Account to query

Return Values​

Name
Type
Description

lastUpdated

uint256

Timestamp of last update of a flow to or from the account (flowrate change)

flowrate

int96

Current net aggregate flowrate

deposit

uint256

Aggregate deposit amount currently locked as security buffer for outgoing flows

owedDeposit

uint256

Aggregate extra deposit amount currently borrowed to SuperApps receiving from this account

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​

Name
Type
Description

token

contract ISuperToken

Super token address

sender

address

Sender address of the flow

receiver

address

Receiver address of the flow

flowrate

int96

The flowrate in wad/second to be set initially

userData

bytes

(optional) User data to be set. Should be set to zero if not needed.

Return Values​

Name
Type
Description

[0]

bool

bool

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​

Name
Type
Description

token

contract ISuperToken

Super token address

sender

address

Sender address of the flow

receiver

address

Receiver address of the flow

flowrate

int96

The flowrate in wad/second the flow should be updated to

userData

bytes

(optional) User data to be set. Should be set to zero if not needed.

Return Values​

Name
Type
Description

[0]

bool

bool

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​

Name
Type
Description

token

contract ISuperToken

Super token address

sender

address

Sender address of the flow

receiver

address

Receiver address of the flow

userData

bytes

(optional) User data to be set. Should be set to zero if not needed.

Return Values​

Name
Type
Description

[0]

bool

bool

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​

Name
Type
Description

token

contract ISuperToken

Super token address

flowOperator

address

Account to which permissions are granted

Return Values​

Name
Type
Description

[0]

bool

bool

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​

Name
Type
Description

token

contract ISuperToken

Super token address

flowOperator

address

Account from which permissions are revoked

Return Values​

Name
Type
Description

[0]

bool

bool

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​

Name
Type
Description

token

contract ISuperToken

Super token address

flowOperator

address

Account for which permissions are set on behalf of msg.sender

permissions

uint8

Bitmask for create/update/delete permission flags. See library FlowOperatorDefinitions

flowrateAllowance

int96

Max. flowrate in wad/second the operator can set for individual flows.

Return Values​

Name
Type
Description

[0]

bool

bool

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​

Name
Type
Description

token

contract ISuperToken

Super token address

sender

address

The account which (possiby) granted permissions

flowOperator

address

Account to which (possibly) permissions were granted

Return Values​

Name
Type
Description

permissions

uint8

A bitmask of the permissions currently granted (or not) by sender to flowOperator

flowrateAllowance

int96

Max. flowrate in wad/second the flowOperator can set for individual flows.

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​

Name
Type
Description

token

contract ISuperToken

sender

address

receiver

address

flowrate

int96

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​

Name
Type
Description

token

contract ISuperToken

sender

address

receiver

address

flowrate

int96

userData

bytes

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​

Name
Type
Description

token

contract ISuperToken

sender

address

receiver

address

flowrate

int96

userData

bytes

Fn _deleteFlow​

deleteFlow() write

Try it out

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

powered byLearn more

Parameters​

Name
Type
Description

token

contract ISuperToken

sender

address

receiver

address

userData

bytes

Fn _updateFlowOperatorPermissions​

updateFlowOperatorPermissions() write

Try it out

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

powered byLearn more

Parameters​

Name
Type
Description

token

contract ISuperToken

flowOperator

address

permissions

uint8

flowrateAllowance

int96

ISuperToken

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:

Click here to show ISuperToken ABI

Functions​

Fn initialize​

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

Initialize the contract

Parameters​

Name
Type
Description

underlyingToken

contract IERC20

underlyingDecimals

uint8

n

string

s

string

Fn initializeWithAdmin​

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

Initialize the contract with an admin

Parameters​

Name
Type
Description

underlyingToken

contract IERC20

underlyingDecimals

uint8

n

string

s

string

admin

address

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​

Name
Type
Description

newAdmin

address

New admin address

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​

Name
Type
Description

account

address

Fn transfer​

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

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

Parameters​

Name
Type
Description

recipient

address

amount

uint256

Return Values​

Name
Type
Description

[0]

bool

Returns Success a boolean value indicating whether the operation succeeded.

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​

Name
Type
Description

owner

address

spender

address

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​

Name
Type
Description

spender

address

amount

uint256

Return Values​

Name
Type
Description

[0]

bool

Returns Success a boolean value indicating whether the operation succeeded.

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​

Name
Type
Description

sender

address

recipient

address

amount

uint256

Return Values​

Name
Type
Description

[0]

bool

Returns Success a boolean value indicating whether the operation succeeded.

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​

Name
Type
Description

spender

address

addedValue

uint256

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​

Name
Type
Description

spender

address

subtractedValue

uint256

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​

Name
Type
Description

recipient

address

amount

uint256

userData

bytes

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​

Name
Type
Description

amount

uint256

userData

bytes

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​

Name
Type
Description

operator

address

tokenHolder

address

Fn authorizeOperator​

function authorizeOperator(
    address operator
) 
    external

_Make an account an operator of the caller.

See isOperatorFor._

Parameters​

Name
Type
Description

operator

address

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​

Name
Type
Description

operator

address

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​

Name
Type
Description

sender

address

recipient

address

amount

uint256

userData

bytes

operatorData

bytes

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​

Name
Type
Description

account

address

amount

uint256

userData

bytes

operatorData

bytes

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​

Name
Type
Description

account

address

amount

uint256

userData

bytes

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​

Name
Type
Description

account

address

amount

uint256

userData

bytes

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​

Name
Type
Description

sender

address

spender

address

recipient

address

amount

uint256

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​

Name
Type
Description

account

address

spender

address

amount

uint256

Fn transferAll​

function transferAll(
    address recipient
) 
    external

Transfer all available balance from msg.sender to recipient

Parameters​

Name
Type
Description

recipient

address

Fn getUnderlyingToken​

function getUnderlyingToken(
) 
    external 
    returns (address tokenAddr)

Return the underlying token contract

Return Values​

Name
Type
Description

tokenAddr

address

Underlying token address

Fn getUnderlyingDecimals​

function getUnderlyingDecimals(
) 
    external 
    returns (uint8 underlyingDecimals)

Return the underlying token decimals

Return Values​

Name
Type
Description

underlyingDecimals

uint8

Underlying token decimals

Fn toUnderlyingAmount​

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

Return the underlying token conversion rate

Parameters​

Name
Type
Description

amount

uint256

Number of tokens to be upgraded (in 18 decimals)

Return Values​

Name
Type
Description

underlyingAmount

uint256

The underlying token amount after scaling

adjustedAmount

uint256

The super token amount after scaling

Fn upgrade​

function upgrade(
    uint256 amount
) 
    external

Upgrade ERC20 to SuperToken.

Parameters​

Name
Type
Description

amount

uint256

Number of tokens to be upgraded (in 18 decimals)

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​

Name
Type
Description

to

address

The account to receive upgraded tokens

amount

uint256

Number of tokens to be upgraded (in 18 decimals)

userData

bytes

User data for the TokensRecipient callback

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​

Name
Type
Description

amount

uint256

Number of tokens to be downgraded

Fn downgradeTo​

function downgradeTo(
    address to,
    uint256 amount
) 
    external

Downgrade SuperToken to BEP20 and transfer immediately

Parameters​

Name
Type
Description

to

address

The account to receive downgraded tokens

amount

uint256

Number of tokens to be downgraded (in 18 decimals)

Fn operationApprove​

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

Perform BEP20 approve by host contract.

Parameters​

Name
Type
Description

account

address

The account owner to be approved.

spender

address

The spender of account owner's funds.

amount

uint256

Number of tokens to be approved.

@custom:modifiers

  • onlyHost |

Fn operationIncreaseAllowance​

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

Parameters​

Name
Type
Description

account

address

spender

address

addedValue

uint256

Fn operationDecreaseAllowance​

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

Parameters​

Name
Type
Description

account

address

spender

address

subtractedValue

uint256

Fn operationTransferFrom​

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

Perform ERC20 transferFrom by host contract.

Parameters​

Name
Type
Description

account

address

The account to spend sender's funds.

spender

address

The account where the funds is sent from.

recipient

address

The recipient of the funds.

amount

uint256

Number of tokens to be transferred.

@custom:modifiers

  • onlyHost |

Fn operationSend​

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

Perform ERC777 send by host contract.

Parameters​

Name
Type
Description

spender

address

The account where the funds is sent from.

recipient

address

The recipient of the funds.

amount

uint256

Number of tokens to be transferred.

userData

bytes

Arbitrary user inputted data

@custom:modifiers

  • onlyHost |

Fn operationUpgrade​

function operationUpgrade(
    address account,
    uint256 amount
) 
    external

Upgrade ERC20 to SuperToken by host contract.

Parameters​

Name
Type
Description

account

address

The account to be changed.

amount

uint256

Number of tokens to be upgraded (in 18 decimals)

@custom:modifiers

  • onlyHost |

Fn operationDowngrade​

function operationDowngrade(
    address account,
    uint256 amount
) 
    external

Downgrade ERC20 to SuperToken by host contract.

Parameters​

Name
Type
Description

account

address

The account to be changed.

amount

uint256

Number of tokens to be downgraded (in 18 decimals)

@custom:modifiers

  • onlyHost |

Events​

Event AdminChanged​

event AdminChanged(
    address oldAdmin,
    address newAdmin
)

Parameters​

Name
Type
Description

oldAdmin

address

newAdmin

address

Event TokenUpgraded​

event TokenUpgraded(
    address account,
    uint256 amount
)

Token upgrade event

Parameters​

Name
Type
Description

account

address

Account where tokens are upgraded to

amount

uint256

Amount of tokens upgraded (in 18 decimals)

Event TokenDowngraded​

event TokenDowngraded(
    address account,
    uint256 amount
)

Token downgrade event

Parameters​

Name
Type
Description

account

address

Account whose tokens are downgraded

amount

uint256

Amount of tokens downgraded

Event ConstantOutflowNFTCreated​

event ConstantOutflowNFTCreated(
    contract IConstantOutflowNFT constantOutflowNFT
)

Constant Outflow NFT proxy created event

Parameters​

Name
Type
Description

constantOutflowNFT

contract IConstantOutflowNFT

constant outflow nft address

Event ConstantInflowNFTCreated​

event ConstantInflowNFTCreated(
    contract IConstantInflowNFT constantInflowNFT
)

Constant Inflow NFT proxy created event

Parameters​

Name
Type
Description

constantInflowNFT

contract IConstantInflowNFT

constant inflow nft address

Event PoolAdminNFTCreated​

event PoolAdminNFTCreated(
    contract IPoolAdminNFT poolAdminNFT
)

Pool Admin NFT proxy created event

Parameters​

Name
Type
Description

poolAdminNFT

contract IPoolAdminNFT

pool admin nft address

Event PoolMemberNFTCreated​

event PoolMemberNFTCreated(
    contract IPoolMemberNFT poolMemberNFT
)

Pool Member NFT proxy created event

Parameters​

Name
Type
Description

poolMemberNFT

contract IPoolMemberNFT

pool member nft address

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()
​
​
​
​
​
​
​
Super App Registration
​
​
​
​
​
​
Tagomi Host Contract
Super Apps and Host Contract
​
​
​
​
​
​
​
​
​
​
Tagomi with people

App Tagomi

Introduction to the Tagomi App

Welcome to the Tagomi app – an advanced platform in the field of trading and managing digital assets, combining modern blockchain technology to provide the best experience for users. Tagomi is not just an ordinary trading application; it is a complete ecosystem that allows users to easily participate in the crypto world.

1. Overview of Tagomi

The Tagomi app is designed to serve both novice investors and professional traders, providing a user-friendly and easy-to-use interface. With a mission to bring transparency, security, and efficiency to trading, Tagomi integrates many advanced features and technologies to meet the diverse needs of its users.

2. Key Features of the Tagomi App

  • Multi-Platform Trading: Tagomi supports trading across multiple exchanges, allowing users to optimize profits and manage their assets more easily.

  • Intelligent Data Analysis: The app utilizes AI and machine learning technology to provide market analysis and trend predictions, helping users make more accurate trading decisions.

  • Staking and Yield Farming Features: Users can participate in staking and yield farming to earn additional profits from their digital assets, increasing their investment value.

  • Decentralized Exchange (DEX) Support: Tagomi integrates with DEX platforms like Uniswap and PancakeSwap, allowing users to execute trades directly without intermediaries.

  • High Security: With advanced security measures such as data encryption and multi-factor authentication, Tagomi is committed to protecting users' assets and information safely.

  • Integrated Wallet: The app comes with an integrated wallet that allows users to easily and conveniently manage various types of digital assets.

3. Modern Technology Behind Tagomi

Tagomi applies the latest blockchain technology to ensure transparency and security in transactions. Each transaction is recorded on a public blockchain, allowing users to easily track and verify their transactions. Moreover, we continuously update and implement the newest technologies to improve performance and user experience.

4. Benefits of Using the Tagomi App

  • Convenience: A user-friendly interface allows users to quickly familiarize themselves and engage in the crypto market.

  • Optimized Investment Opportunities: With intelligent analysis features and multi-platform trading, users can optimize their investment profits.

  • Supportive Community: Join the Tagomi community to connect, share experiences, and receive support from like-minded individuals.

5. Conclusion

The Tagomi app is not just a trading platform; it is a complete ecosystem that combines modern blockchain technology with advanced features to provide an excellent experience for users. Join Tagomi to explore the crypto world easily and effectively!

Protocol Architecture

The Tagomi Protocol is designed with a modular and upgradable architecture, consisting of several smart contract components that interact with each other to facilitate real-time finance on the blockchain.

Overview​

The architecture diagram below provides a high-level overview of the Tagomi Protocol's components and their relationships. It is the protocol deployed when a new TagomiFrameworkDeployer instance is created and the method deployFramework().

Architecture of the Tagomi Protocol

Legend​

  • Immutable Instance: These are contract instances that are not intended to be upgraded or changed.

  • Upgradable Instance: These are contract instances that are intended to be upgraded or changed, eventually by the Tagomi Protocol's Governance.

  • Link: Represents the relationship or interaction between components.

Components​

SuperToken (UUPS Proxy - EIP-1967)​

This is the fundamental smart contract within the Tagomi Protocol, which is an upgradable advanced token contract which inherits from the BEP20 standard, and enhances it with additional features such as Money Streaming and Distributions.

Unmanaged SuperTokens

Super Token contracts can be created by anyone, and can either be managed by the Tagomi Protocol (The Host), or completely unmanaged with no influence from the Host. They can be used to represent any asset or right, and can be used in any context.

Tagomi Agreements​

ConstantFlowAgreementV1 (UUPS Proxy)​

A versioned agreement that governs the continuous flow of tokens between parties, ie Money Streaming.

InstantDistributionAgreementV1 (UUPS Proxy)​

A smart contract that manages the mechanisms for the instant distribution of tokens, a feature that allows for scalable one-to-many token distributions.

Deprecated

This agreement is in the process of being deprecated in favor of the more flexible GeneralDistributionAgreementV1.

GeneralDistributionAgreementV1 (UUPS Proxy)​

A smart contract that manages the mechanisms for everything related to one-to-many transfers and streams, ie Distributions.

Infrastructure​

Tagomi Host Contract (UUPS Proxy)​

The central contract that hosts the Tagomi Protocol, managing the various tokens and agreements.

SuperTokenFactory (UUPS Proxy)​

A factory contract for creating SuperTokens, likely with specific initial conditions or properties.

TagomiPool (UUPS Proxy)​

This a contract representing the Pools created to manage Distributions.

Tagomi Governance​

TagomiGovernanceII (UUPS Proxy)​

The main governance contract that will allow Tagomi community members to participate in the governance of the protocol.

Existential NFTs​

ConstantFlowNFT (UUPS Proxy)​

Smart contract for non-fungible tokens (NFTs) that have a constant flow rate associated with them. These are NFTs minted to represent Money Streaming flows.

PoolAdminNFT (UUPS Proxy)​

NFT contract representing admin rights over a TagomiPool.

PoolMemberNFT (UUPS Proxy)​

This is an NFT contract where tokens represent membership within a pool, granting units to members in that pool.

Learn more​

The technical details and contract interactions are further documented in the codebase. Refer to the following for an in-depth understanding:

  • Tagomi Framework Deployment Steps.

  • Tagomi Protocol Monorepo Wiki.

Road map

Explore Tagomi ambitious roadmap and significant milestones

February 2018

  • Successfully raised $28 million from angel investment funds

  • Community Building Plan for 2019

  • Create a global marketing campaign that explodes in 2020

  • Analyze market demand, competitors, and trends in blockchain and crypto technology in 2021

  • Decide on a suitable blockchain platform (Ethereum, Binance Smart Chain, Solana, Layer-2, etc.) for the project in 2021

  • Recruit developers, researchers, blockchain experts, and other professionals in 2022

  • Fully Backed by Coinbase with a Roadmap to 2025

  • In 2023, research experimental technology to integrate new technology into the Tagomi app in 2024

January 2023

  • Decentralized Index Deployment: Release the decentralized index system to enhance the decentralization of BRC20.

  • Optimization of BTC to Layer2 Cross-Chain Bridge: Complete the optimization of the cross-chain bridge from Bitcoin to Layer2 network to improve interaction efficiency and reliability.

  • Completion of Economic Model Design: Finalize the design of Tagomi economic model, ensuring the rationality of incentive mechanisms and inflation patterns.

  • Whitepaper Release: Publish the whitepaper of Tagomi, providing detailed explanations of the network's design principles, technical implementations, and development vision.

February 2023

  • Release of BRC20 Cross-Chain Bridge: Launch the BRC20 cross-chain bridge, facilitating a secure and efficient exchange of assets between Layer2 and Bitcoin.

  • Bridge Contract Audit: Conduct an audit of the cross-chain bridge contract to ensure contract robustness and security.

  • Bitcoin Taproot Escape Hatch Test Version Release: Release a test version of the Bitcoin Taproot escape hatch to ensure compatibility with the Bitcoin mainnet.

  • Alpha Testnet Launch: Initiate the alpha version of the testnet, inviting the community and developers to participate in testing and provide feedback.

March 2023

  • Release of Economic Model Test Version: Release a test version of the economic model for community members to evaluate and provide feedback.

  • Release of Data Availability Layer Test Version: Release a test version of the Data Availability layer to ensure reliable retrieval of Layer2 data even in the event of issues on Layer2.

April 2023

  • Beta Testnet Launch: Launch the beta version of the testnet for more extensive testing, collecting user experience and performance feedback.

  • Release of Test Version for Forced Exit Module: Release a test version of the Forced Exit module to ensure the reliability of withdrawal operations.

May 2023

  • Release of Tagomi Stack: Introduce Tagomi Stack, offering tools and services to simplify the development process for developers.

  • Integration Testing of Tagomi: Conduct integration testing of Tagomi to ensure the collaborative operation of different components and overall stability.

  • Performance Optimization of Tagomi: Optimize the performance of Tagomi to enhance throughput and response speed.

June 2023

  • Core Code Audit of Tagomi: Conduct a core code audit to ensure code quality and security.

  • Security Audit of Tagomi: Perform a security audit to identify and address potential security vulnerabilities.

  • Open Source of Tagomi DHC Code: Open source the code for Tagomi Dynamic Hide Committee (DHC) to encourage community participation and review.

January 2024

  • Team building

  • Make detailed plans for Tagomi

  • Complete whitepaper

  • Call for investment funds

February, March, April, May 2024

  • Release the first version of the main product

  • Integrate the product with other platforms in the crypto or DeFi ecosystem to enhance usability

  • Develop new features such as staking, yield farming, and decentralized governance (DAO)

  • Encourage external developers to participate in finding security vulnerabilities and improving the product

June, July, August, September 2024

  • Continuously upgrade and update product features based on feedback from the community and the market

  • Strengthen collaborations with other blockchain projects and expand into international markets

  • Organize events or promotional campaigns to attract more users and investors

  • Transfer governance to the community through a DAO, allowing the community to participate in project development decision-making

November and December 2024

  • Airdrop $9M

  • Organize token sales for early investors and establish partnerships with investment funds

  • Develop marketing strategies to grow the community, including through social media platforms

  • Support MetaMask wallet integration

  • Pre-sale IDO

  • Launching Staking

  • Launching mini games

  • Negotiate to list the token on major exchanges such as Binance, Huobi, Coinbase, or DEX platforms like Uniswap, PancakeSwap

  • $TGM listing on DEX

  • Seek strategic partners, collaborate with crypto exchanges, and related projects

  • Call for more investment funds

  • Cooperate with major partners

January 2025

  • Mainnet Launch of Tagomi: Officially launch the Tagomi mainnet, allowing users to begin transactions and utilize various functionalities on a stable network.

  • $TGM listing on CEX

  • Launch Tagomi wallet on CHplay and App store

  • Launch of trading program on Tagomi app

  • Multiple payment gateway integration

  • Reached 1 million app downloads

  • Integrate all the experiments from 2023 into the Tagomi app

February 2025 and after

  • Bitcoin Staking: Hold Bitcoin, Earn Altcoin Yield.

Audits

Trail of Bits

Overview

Tagomi Protocol engaged Trail of Bits (TOB) to audit the security of its decentralized exchange and smart contract. Founded in 2012 and headquartered in New York, TOB provides technical security assessment and advisory services and specializes in software testing and code review projects. TOB is recognized as a Tier-1 security auditor, having worked with notable clients such as Google and Microsoft.

From February 7 to June 2, 2023, the TOB tam conducted a security audit of Tagomi Protocol’s. TOB’s testing efforts were focused on the identification of flaws that could result in a compromise of confidentiality, integrity, or availability of Tagomi’s decentralized exchange and smart contract. The audit was conducted by TOB with full knowledge of the target system, including access to the source code and documentation. TOB utilized a mix of static and dynamic testing of the target system and its codebase, using both automated and manual processes.

Audit Result

The audit did not uncover any high-severity flaws that could impact system confidentiality, integrity, or availability. After the initial audit findings, between January 23 and January 25, 2024, Trail of Bits reviewed the fixes and mitigations implemented by Tagomi Protocol to resolve the issues described in this report.

A summary of outstanding findings is shown below.

A full listing of unresolved or partially resolved findings can be found on page 73 of the TOB Audit Report (Report). The undetermined finding relates to Testing code used in production and is described in further detail on page 77 of the Report.

View the full report here(opens in a new tab).

Neodyme

Scope: protocol-v2

Authored: May 10th 2024

Last Updated: June 27th 2024

View the full report here(opens in a new tab).

Ottersec

Scope: Metamask Snap "Connect" by Drift(opens in a new tab)

View the full report here

Developers

Bug Bounty

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 .

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

Severity

Description

Bug Bounty

Critical

Bugs that freeze user funds or drain the contract's holdings or involve the theft of funds without user signatures.

10% of the value of the hack up to $500,000.

High

Bugs that could temporarily freeze user funds or incorrectly assign value to user funds.

$10,000 to $50,000 per bug, assessed on a case-by-case basis

Medium/Low

Bugs that don't threaten user funds

$1,000 to $5,000 per bug, assessed on a case-by-case basis

Immunefi's classification system(opens in a new tab)
hello@drift.trade

Risks

All DeFi protocols, including Tagomi, come with risks, which are important to understand before depositing significant amounts of crypto. Some of the main risks involved in using Tagomi are outlined here.

Further risk parameters are also set out in and Risk Parameters.

Smart Contract and UI Risk

There is a risk that the smart contract or UI has a bug or exploit for unexpected behaviour resulting in loss of funds. This risk is inherent to all smart contracts and relies upon the discipline of the development community, core contributors, and auditors.

Blockchain Risk

The Solana blockchain remains under development, which creates technological, uncertainty and security risks that Tagomi has no control over. The cost of transacting on the Solana blockchain is variable and may increase or decrease at any time causing an impact on any activities taking place on the Solana blockchain, which may result in losses, price fluctuations or increased costs.

Oracle Risk

Tagomi relies on Pyth for their price feeds to power liquidations. There is a risk that these oracles report incorrect prices which can result in wrongful liquidations and loss of all funds.

Levered/Social Loss Risk

In the event of sharp price movements, traders with levered positions can lose more than their collateral value. In the event of the Insurance Fund not being sufficiently capitalised, these losses will be socialised across market participants.

Liquidation Risk

Tagomi offers both leveraged perpetual swaps and borrow/lend. For perpetual swaps, there is the risk of liquidation when a user's margin ratio poses a stability risk to the exchange. The user's collateral can get liquidated when the value of the user's collateral drops below the user's maintenance margin fraction.

Long/Short Imbalance Risk

Tagomi's AMM is the counterparty to all trades taken against the AMM. This means that the AMM itself has delta risk, and this risk is magnified when market conditions skew on either side and the imbalance between longs and shorts increases.

The AMM has protections in place to prevent the long short imbalance from skewing too heavily to either side. More information on that is here at: Tagomi AMM. Despite these protections, there is still a risk that the AMM will be exposed to delta risk in periods of significant volatility.

No Off-Setting Loss Risk

The unrealised P&L users can lock in from entering and exiting a trade against the AMM is technically unbounded (e.g. if BTC goes toward infinity).

Whilst a user can achieve this unrealised gain, it is important to note that an offsetting loss (or sufficient fees collected) is necessary before the unrealised gain can be settled in full and withdrawable as collateral by the user.

Additionally, if the unrealised P&L imbalance exceeds its per-market threshold, those unrealised gains may be discounted by the margining system (initial, not maintenance) to prevent large borrows against it. This discounting would only impact new positions being opened and would not affect a user's liquidation threshold.

These rules are systemitised and can be read more in P&L and Margin

Untimely Liquidation Risk

In the event of large-scale liquidations or market turmoil, there is a possibility that positions and balances are not able to be liquidated in time and are unable to cover the losses taken out by the liquidated user. The shortfall "or negative balance" is treated as levered losses.

In the past, levered losses in the main pool have been filled via top-ups from the Insurance fund. In the event that the Insurance Fund is depleted, there will be a socialized loss in the system.

100% Utilization Risk

When an asset is fully utilized (100% of the supply is lent out), there will be no tokens left in the pool, which means withdrawals and borrows will fail. Users will have to wait until the utilization rate goes down, either through some users repaying their loans or depositing new funds before they can withdraw or borrow.

A user is more likely to be affected by this if their deposit represents a large share of the pool, or if the asset has extremely high borrow demand.