Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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
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
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.
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:
Pool Creation: Any account can create a pool and appoint a pool admin. This pool acts as a channel for distributing funds.
Unit Management: The pool admin assigns units to members, representing their share in future distributions.
Member Connection: Pool members can connect to or disconnect from the pool, affecting how they access distributed funds.
Distribution Execution: Distributors can initiate either instant or streaming distributions, which are then divided among pool members based on their unit share.
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.
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.
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.
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.
Subscribers/Pool Member: Receivers allocated units and eligible to receive tokens through the Index.
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.
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.
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.
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:
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!
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:
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.
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.
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%
FUNDS ALLOCATION:
Operational – 16.7%
General costs – 8.3%
Initial liquidity – 15%
Marketing – 10%
Strategic pertnership – 9%
Community rewards – 5%
Pre-sale – 8%
Airdrop - 3%
Public listing – 3%
Reserve – 18%
Team – 15%
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!
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.
To participate in the Pre-sale IDO and purchase $TGM tokens, please follow these steps on the official Tagomi website:
Visit the Official Tagomi Website:
Go to , the official platform for all information and updates on the Tagomi project.
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.
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.
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: and secure your $TGM tokens before they run out. Thank you for your continued trust and support!
Stay informed by following our official channels:
X:
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
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.
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.
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.
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.
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.
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!
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.
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.
Flow Rate: The rate at which the sender's balance decreases and the receiver's increases per second.
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 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.
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.
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 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.
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.
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.
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."
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:
New Netflow rate
New CRUD timestamp
New Static Balance: set to the Current Balance at the CRUD timestamp
Real-Time Balance reset to zero
The Real-Time Balance then adjusts by-the-second at the netflow rate.
Streaming Real-Time Balance
info
NOTE: Creating a stream is a one-time action. The balance is dynamically calculated and does not require continuous transactions.
Static Balance: Initial balance at the latest CRUD timestamp
Real-Time Balance: Netflow Rate * Seconds since the latest CRUD timestamp
Current Balance: Static Balance + Real-Time Balance
Let's examine how Account A's balance changes with stream interactions.
1. Starting an 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
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 Elapsed: 2000 seconds
Current Balance: 950 USDCx
4. Receiving an 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
Time Elapsed: 1000 seconds
Current Balance: 970 USDCx
6. Deleting the Outbound Stream
*Deleting Inbound Stream
Static Balance: 970 USDCx
Current Balance: 970 USDCx
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.
Accounts with negative net flow rates reaching zero balance are considered critical. Superfluid handles this with buffer deposits and Sentinels.
Buffer deposits are taken when opening a stream, serving as a reserve in case of a critical balance. If a stream is closed before hitting critical, the buffer is refunded. In cases where the account becomes critical, the buffer is used to continue outbound streams until Sentinels intervene.
Sentinels are external actors who monitor Constant Flow Agreements (Money Streaming), close streams of critical accounts, and earn buffer deposits.
For more details, see the Liquidations and Sentinels pages.
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.
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!
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.
How to Stake TGM Tokens:
Access the Staking Platform: Go to the staking platform provided by Tagomi.
Connect Wallet: Connect your wallet that holds the TGM tokens to the staking platform.
Choose Pool: Select the pool you want to stake your TGM tokens in based on the amount you hold.
Enter Amount: Enter the amount of TGM tokens you wish to stake in the chosen pool.
Confirm Staking: Confirm the staking transaction and wait for it to be processed.
Staking Period: Your staked TGM tokens will be locked in the chosen pool for a period of 10 days.
Earn Rewards: During the staking period, you will start earning staking rewards based on the APR (Annual Percentage Rate) of the chosen pool.
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:
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.
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.
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.
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.
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.
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.
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.
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!
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.
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!
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.
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!
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 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 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
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
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.
This glossary provides a comprehensive overview of terms and concepts within the Tagomi ecosystem.
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 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.
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.
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.
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.
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.
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
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.
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.
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.
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 created to manage Distributions.
TagomiGovernanceII (UUPS Proxy)
The main governance contract that will allow Tagomi community members to participate in the governance of the protocol.
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.
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.
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, 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.
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 form the foundational layer of the Tagomi Protocol, where all Super Agreement data for an account is compiled.
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.
Registration of Super Apps with the Tagomi Host is essential to enable their callback functionalities.
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.
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.
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.
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.
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.
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).
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.
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).
Consider a Super App designed to consolidate all incoming flows into a single outgoing flow to a specific account (Account Z):
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.
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.
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.
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.
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
Super Apps introduce a layer of programmability to Super Agreements, enhancing the potential for innovative decentralized applications (dApps).
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
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.
Create flow without userData
Parameters
Create flow with userData
Parameters
Update flow without userData
Parameters
Update flow with userData
Parameters
Delete flow without userData
Parameters
Delete flow with userData
Parameters
Update permissions for flow operator
Parameters
Update permissions for flow operator - give operator max permissions
Parameters
Update permissions for flow operator - revoke all permission
Parameters
Increases the flow rate allowance for flow operator
Parameters
allowing userData to be a parameter here triggered stack too deep error
Increases the flow rate allowance for flow operator
Parameters
allowing userData to be a parameter here triggered stack too deep error
Decreases the flow rate allowance for flow operator
Parameters
allowing userData to be a parameter here triggered stack too deep error
Decreases the flow rate allowance for flow operator
Parameters
allowing userData to be a parameter here triggered stack too deep error
Increases the flow rate allowance for flow operator and adds the permissions
Parameters
allowing userData to be a parameter here triggered stack too deep error
Increases the flow rate allowance for flow operator and adds the permissions
Parameters
allowing userData to be a parameter here triggered stack too deep error
Decreases the flow rate allowance for flow operator and removes the permissions
Parameters
allowing userData to be a parameter here triggered stack too deep error
Decreases the flow rate allowance for flow operator and removes the permissions
Parameters
allowing userData to be a parameter here triggered stack too deep error
Update permissions for flow operator in callback
Parameters
Return Values
allowing userData to be a parameter here triggered stack too deep error
Update permissions for flow operator - give operator max permissions
Parameters
Return Values
Update permissions for flow operator - revoke all permission
Parameters
Return Values
Creates flow as an operator without userData
Parameters
Creates flow as an operator with userData
Parameters
Updates flow as an operator without userData
Parameters
Updates flow as an operator with userData
Parameters
Deletes flow as an operator without userData
Parameters
Deletes flow as an operator with userData
Parameters
Create flow with context and userData
Parameters
Return Values
Create flow by operator with context
Parameters
Return Values
Update flow with context
Parameters
Return Values
Update flow by operator with context
Parameters
Return Values
Delete flow with context
Parameters
Return Values
Delete flow by operator with context
Parameters
Return Values
get flow rate between two accounts for given token
Parameters
Return Values
get flow info between two accounts for given token
Parameters
Return Values
get net flow rate for given account for given token (CFA + GDA)
Parameters
Return Values
get CFA net flow rate for given account for given token
Parameters
Return Values
get GDA net flow rate for given account for given token
Parameters
Return Values
get the aggregated flow info of the account
Parameters
Return Values
calculate buffer for a flow rate
Parameters
Return Values
get existing flow permissions
Parameters
Return Values
Gets an index by its ID and publisher.
Parameters
Return Values
Calculates the distribution amount based on the amount of tokens desired to distribute.
Parameters
Return Values
List all subscriptions of an address
Parameters
Return Values
Gets subscription by publisher, index id, and subscriber.
Parameters
Return Values
Parameters
Parameters
GDA VIEW FUNCTIONS *************************************
Parameters
Parameters
Parameters
Creates a new index.
Parameters
Creates a new index with userData.
Parameters
Updates an index value. This distributes an amount of tokens equal to indexValue - lastIndexValue. See distribute for another way to distribute.
Parameters
Updates an index value with userData. This distributes an amount of tokens equal to indexValue - lastIndexValue. See distribute for another way to distribute.
Parameters
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
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
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
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
Revokes a previously approved subscription.
Parameters
Revokes a previously approved subscription. This takes arbitrary user data.
Parameters
Updates the units of a subscription. This changes the number of shares the subscriber holds
Parameters
Updates the units of a subscription. This changes the number of shares the subscriber holds. This takes arbitrary user data.
Parameters
Deletes a subscription, setting a subcriber's units to zero
Parameters
Deletes a subscription, setting a subcriber's units to zero. This takes arbitrary userdata.
Parameters
Claims pending distribution. Subscription should not be approved
Parameters
Claims pending distribution. Subscription should not be approved. This takes arbitrary user data.
Parameters
Creates a new index with ctx. Meant for usage in super app callbacks
Parameters
Return Values
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
Return Values
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
Return Values
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
Return Values
Revokes a previously approved subscription. Meant for usage in super apps
Parameters
Return Values
Updates the units of a subscription. This changes the number of shares the subscriber holds. Meant for usage in super apps
Parameters
Return Values
Deletes a subscription, setting a subcriber's units to zero. Meant for usage in super apps
Parameters
Return Values
Claims pending distribution. Subscription should not be approved. Meant for usage in super app callbacks
Parameters
Return Values
Creates a new Tagomi Pool.
Parameters
The PoolConfig struct is defined as follows:
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
Updates the units of a pool member.
Parameters
Return Values
Updates the units of a pool member.
Parameters
Return Values
Claims all tokens from the pool.
Parameters
Return Values
Claims all tokens from the pool.
Parameters
Return Values
Connects a pool member to pool.
Parameters
Return Values
Connects a pool member to pool.
Parameters
Return Values
Disconnects a pool member from pool.
Parameters
Return Values
Disconnects a pool member from pool.
Parameters
Return Values
Tries to distribute requestedAmount amount of token from from to pool.
Parameters
Return Values
Tries to distribute requestedAmount amount of token from from to pool.
Parameters
Return Values
Tries to distribute flow at requestedFlowRate of token from from to pool.
Parameters
Return Values
Tries to distribute flow at requestedFlowRate of token from from to pool.
Parameters
Return Values
Updates the units of a pool member.
Parameters
Return Values
Claims all tokens from the pool.
Parameters
Return Values
Connects a pool member to pool.
Parameters
Return Values
Disconnects a pool member from pool.
Parameters
Return Values
Tries to distribute requestedAmount amount of token from from to pool.
Parameters
Return Values
Tries to distribute flow at requestedFlowRate of token from from to pool.
Parameters
Return Values
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.
The CFAv1Forwarder contract address is the same on all networks:
In order to interact with the CFAv1Forwarder contract, you can use the following ABI:
Parameters
Try it out
Parameters
Return Values
Sets the given flowrate between msg.sender and a given receiver. If there's no pre-existing flow and flowrate non-zero, a new flow is created. If there's an existing flow and flowrate non-zero, the flowrate of that flow is updated. If there's an existing flow and flowrate zero, the flow is deleted. If the existing and given flowrate are equal, no action is taken. On creation of a flow, a "buffer" amount is automatically detracted from the sender account's available balance. If the sender account is solvent when the flow is deleted, this buffer is redeemed to it.
Try it out
Parameters
Return Values
Like setFlowrate, but can be invoked by an account with flowOperator permissions on behalf of the sender account.
Try it out
Currently, only 0 or 1 flows can exist between 2 accounts. This may change in the future.
Parameters
Return Values
Get the flowrate of the flow between 2 accounts if exists.
Try it out
Parameters
Return Values
Get all available information about a flow (if exists). If only the flowrate is needed, consider using getFlowrate instead.
Try it out
Parameters
Return Values
Get the buffer amount required for the given token and flowrate. This amount can vary based on the combination of token, flowrate and chain being queried. The result for a given set of parameters can change over time, because it depends on governance configurable protocol parameters. Changes of the required buffer amount affect only flows created or updated after the change.
Try it out
Parameters
Return Values
Get the net flowrate of an account.
Try it out
Parameters
Return Values
Get aggregated flow information (if any exist) of an account. If only the net flowrate is needed, consider using getAccountFlowrate instead.
Try it out
Parameters
Return Values
Low-level wrapper of createFlow/createFlowByOperator. If the address of msg.sender is not the same as the address of the sender argument, createFlowByOperator is used internally. In this case msg.sender needs to have permission to create flows on behalf of the given sender account with sufficient flowRateAllowance. Currently, only 1 flow can exist between 2 accounts, thus createFlow will fail if one already exists.
Try it out
Parameters
Return Values
Low-level wrapper if updateFlow/updateFlowByOperator. If the address of msg.sender doesn't match the address of the sender argument, updateFlowByOperator is invoked. In this case msg.sender needs to have permission to update flows on behalf of the given sender account with sufficient flowRateAllowance.
Try it out
Parameters
Return Values
Low-level wrapper of deleteFlow/deleteFlowByOperator. If msg.sender isn't the same as sender address, msg.sender needs to have permission to delete flows on behalf of the given sender account.
Try it out
Parameters
Return Values
Grants a flowOperator permission to create/update/delete flows on behalf of msg.sender. In order to restrict what a flowOperator can or can't do, the flowOperator account should be a contract implementing the desired restrictions.
Try it out
Parameters
Return Values
Revokes all permissions previously granted to a flowOperator by msg.sender. Revocation doesn't undo or reset flows previously created/updated by the flowOperator. In order to be sure about the state of flows at the time of revocation, you need to check that state either in the same transaction or after this transaction.
Try it out
Parameters
Return Values
Low-level wrapper of IConstantFlowAgreementV1.updateFlowOperatorPermissions flowrateAllowance does NOT restrict the net flowrate a flowOperator is able to set. In order to restrict that, flowOperator needs to be a contract implementing the wanted limitations.
Try it out
Parameters
Return Values
Get the currently set permissions granted to the given flowOperator by the given sender account.
Try it out
Parameters
Try it out
Parameters
Try it out
Parameters
Try it out
Parameters
Try it out
Parameters
0xcfA132E353cB4E398080B9700609bb008eceB125allowDelete
bool
flowRateAllowance
int96
The allowance provided to flowOperator
userData
bytes
The userdata passed along with call
userData
bytes
The userdata passed along with call
allowDelete
bool
flowRateAllowance
int96
The allowance provided to flowOperator
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
userData
bytes
The user provided data
userData
bytes
The user provided data
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
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
//
userData
bytes
Arbitrary user data field.
userData
bytes
Arbitrary user data field.
userData
bytes
Arbitrary user data field.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
userData
bytes
User-specific data.
userData
bytes
User-specific data.
userData
bytes
User-specific data.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
token
contract ISuperToken
The token used in flow
receiver
address
The receiver of the flow
flowRate
int96
The desired flowRate
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
token
contract ISuperToken
The token used in flow
receiver
address
The receiver of the flow
flowRate
int96
The desired flowRate
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
token
contract ISuperToken
The token used in flow
sender
address
The sender of the flow
receiver
address
The receiver of the flow
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
token
contract ISuperToken
The token used in flow
flowOperator
address
The address given flow permissions
allowCreate
bool
creation permissions
allowUpdate
bool
token
contract ISuperToken
The token used in flow
flowOperator
address
The address given flow permissions
token
contract ISuperToken
The token used in flow
flowOperator
address
The address given flow permissions
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
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
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
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
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
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
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
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
token
contract ISuperToken
The token used in flow
flowOperator
address
The address given flow permissions
allowCreate
bool
creation permissions
allowUpdate
bool
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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
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
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
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
token
contract ISuperToken
The token to flow
sender
address
The sender of the flow
receiver
address
The receiver of the flow
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
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)
newCtx
bytes
The updated context after the execution of the agreement function
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
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
token
contract ISuperToken
The token used in flow
sender
address
The sender of the flow
receiver
address
The receiver of the flow
flowRate
int96
The flow rate
token
contract ISuperToken
The token used in flow
sender
address
The sender of the flow
receiver
address
The receiver of the flow
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
token
contract ISuperToken
Super token address
account
address
Account to query
flowRate
int96
The net flow rate of the account
token
contract ISuperToken
Super token address
account
address
Account to query
flowRate
int96
The net flow rate of the account
token
contract ISuperToken
Super token address
account
address
Account to query
flowRate
int96
The net flow rate of the account
token
contract ISuperToken
Super token address
account
address
Account to query
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
token
contract ISuperToken
The token used in flow
flowRate
int96
The flowrate to calculate the needed buffer for
bufferAmount
uint256
The buffer amount based on flowRate, liquidationPeriod and minimum deposit
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
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)
token
contract ISuperToken
Super token used with the index.
publisher
address
Publisher of the index.
indexId
uint32
ID of the index.
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.
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.
actualAmount
uint256
Amount to be distributed with correct rounding.
newIndexValue
uint128
The index value after the distribution would be called.
token
contract ISuperToken
Super token used in the indexes listed.
subscriber
address
Subscriber address.
publishers
address[]
Publishers of the indices.
indexIds
uint32[]
IDs of the indices.
unitsList
uint128[]
Units owned of the indices.
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.
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.
token
contract ISuperToken
agreementId
bytes32
token
contract ISuperToken
from
address
to
contract ITagomiPool
token
contract ISuperToken
from
address
to
contract ITagomiPool
requestedFlowRate
int96
token
contract ISuperToken
from
address
to
contract ITagomiPool
requestedAmount
uint256
token
contract ISuperToken
pool
address
member
address
token
contract ISuperToken
Super Token used with the index.
indexId
uint32
ID of the index.
token
contract ISuperToken
Super Token used with the index.
indexId
uint32
ID of the index.
userData
bytes
Arbitrary user data field.
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.
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.
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
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.
token
contract ISuperToken
Super Token used with the index.
publisher
address
Publisher of the index.
indexId
uint32
ID of the index.
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.
token
contract ISuperToken
Super Token used with the index.
publisher
address
Publisher of the index.
indexId
uint32
ID of the index.
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.
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.
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.
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.
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.
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.
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.
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)
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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.
newCtx
bytes
The updated context after the execution of the agreement function
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.
newCtx
bytes
The updated context after the execution of the agreement function
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.
newCtx
bytes
The updated context after the execution of the agreement function
token
contract ISuperToken
The Super Token address.
admin
address
The pool admin address.
poolConfig
struct PoolConfig
The pool configuration (see below)
pool
contract ITagomiPool
The address of the deployed Tagomi Pool
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.
[0]
bool
bool A boolean value indicating whether the pool was created successfully.
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.
[0]
bool
A boolean value indicating whether the pool was created successfully.
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.
[0]
bool
A boolean value indicating whether the claim was successful.
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.
[0]
bool
A boolean value indicating whether the claim was successful.
token
contract ISuperToken
The Super Token address.
pool
contract ITagomiPool
The Tagomi Pool to connect.
[0]
bool
A boolean value indicating whether the connection was successful.
token
contract ISuperToken
The Super Token address.
pool
contract ITagomiPool
The Tagomi Pool to connect.
userData
bytes
User-specific data.
[0]
bool
A boolean value indicating whether the connection was successful.
token
contract ISuperToken
The Super Token address.
pool
contract ITagomiPool
The Tagomi Pool to disconnect.
[0]
bool
A boolean value indicating whether the disconnection was successful.
token
contract ISuperToken
The Super Token address.
pool
contract ITagomiPool
The Tagomi Pool to disconnect.
userData
bytes
User-specific data.
[0]
bool
A boolean value indicating whether the disconnection was successful.
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.
[0]
bool
A boolean value indicating whether the distribution was successful.
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.
[0]
bool
A boolean value indicating whether the distribution was successful.
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.
[0]
bool
A boolean value indicating whether the distribution was successful.
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.
[0]
bool
A boolean value indicating whether the distribution was successful.
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.
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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)
newCtx
bytes
The updated context after the execution of the agreement function
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.
newCtx
bytes
The updated context after the execution of the agreement function
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.
newCtx
bytes
The updated context after the execution of the agreement function
userData
bytes
(optional) User data to be set. Should be set to zero if not needed.
userData
bytes
(optional) User data to be set. Should be set to zero if not needed.
userData
bytes
userData
bytes
host
contract ITagomi
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.
[0]
bool
bool
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.
[0]
bool
bool
token
contract ISuperToken
Super token address
sender
address
The sender of the flow
receiver
address
The receiver of the flow
flowrate
int96
The flowrate from the sender to the receiver account. Returns 0 if no flow exists.
token
contract ISuperToken
Super token address
sender
address
The sender of the flow
receiver
address
The receiver of the flow
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
token
contract ISuperToken
Super token address
flowrate
int96
The flowrate for which the buffer amount is calculated
bufferAmount
uint256
The buffer amount required for the given configuration.
token
contract ISuperToken
Super token address
account
address
Account to query
flowrate
int96
The net flowrate (aggregate incoming minus aggregate outgoing flowrate), can be negative.
token
contract ISuperToken
Super token address
account
address
Account to query
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
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
[0]
bool
bool
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
[0]
bool
bool
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.
[0]
bool
bool
token
contract ISuperToken
Super token address
flowOperator
address
Account to which permissions are granted
[0]
bool
bool
token
contract ISuperToken
Super token address
flowOperator
address
Account from which permissions are revoked
[0]
bool
bool
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.
[0]
bool
bool
token
contract ISuperToken
Super token address
sender
address
The account which (possiby) granted permissions
flowOperator
address
Account to which (possibly) permissions were granted
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.
token
contract ISuperToken
sender
address
receiver
address
flowrate
int96
token
contract ISuperToken
sender
address
receiver
address
flowrate
int96
token
contract ISuperToken
sender
address
receiver
address
flowrate
int96
token
contract ISuperToken
sender
address
receiver
address
userData
bytes
token
contract ISuperToken
flowOperator
address
permissions
uint8
flowrateAllowance
int96
function createFlow(
contract ISuperToken token,
address receiver,
int96 flowRate
)
internal
returns (bool)function createFlow(
contract ISuperToken token,
address receiver,
int96 flowRate,
bytes userData
)
internal
returns (bool)function updateFlow(
contract ISuperToken token,
address receiver,
int96 flowRate
)
internal
returns (bool)function updateFlow(
contract ISuperToken token,
address receiver,
int96 flowRate,
bytes userData
)
internal
returns (bool)function deleteFlow(
contract ISuperToken token,
address sender,
address receiver
)
internal
returns (bool)function deleteFlow(
contract ISuperToken token,
address sender,
address receiver,
bytes userData
)
internal
returns (bool)function setFlowPermissions(
contract ISuperToken token,
address flowOperator,
bool allowCreate,
bool allowUpdate,
bool allowDelete,
int96 flowRateAllowance
)
internal
returns (bool)function setMaxFlowPermissions(
contract ISuperToken token,
address flowOperator
)
internal
returns (bool)function revokeFlowPermissions(
contract ISuperToken token,
address flowOperator
)
internal
returns (bool)function increaseFlowRateAllowance(
contract ISuperToken token,
address flowOperator,
int96 addedFlowRateAllowance
)
internal
returns (bool)function increaseFlowRateAllowance(
contract ISuperToken token,
address flowOperator,
int96 addedFlowRateAllowance,
bytes userData
)
internal
returns (bool)function decreaseFlowRateAllowance(
contract ISuperToken token,
address flowOperator,
int96 subtractedFlowRateAllowance
)
internal
returns (bool)function decreaseFlowRateAllowance(
contract ISuperToken token,
address flowOperator,
int96 subtractedFlowRateAllowance,
bytes userData
)
internal
returns (bool)function increaseFlowRateAllowanceWithPermissions(
contract ISuperToken token,
address flowOperator,
uint8 permissionsToAdd,
int96 addedFlowRateAllowance
)
internal
returns (bool)function increaseFlowRateAllowanceWithPermissions(
contract ISuperToken token,
address flowOperator,
uint8 permissionsToAdd,
int96 addedFlowRateAllowance,
bytes userData
)
internal
returns (bool)function decreaseFlowRateAllowanceWithPermissions(
contract ISuperToken token,
address flowOperator,
uint8 permissionsToRemove,
int96 subtractedFlowRateAllowance
)
internal
returns (bool)function decreaseFlowRateAllowanceWithPermissions(
contract ISuperToken token,
address flowOperator,
uint8 permissionsToRemove,
int96 subtractedFlowRateAllowance,
bytes userData
)
internal
returns (bool)function setFlowPermissionsWithCtx(
contract ISuperToken token,
address flowOperator,
bool allowCreate,
bool allowUpdate,
bool allowDelete,
int96 flowRateAllowance,
bytes ctx
)
internal
returns (bytes newCtx)function setMaxFlowPermissionsWithCtx(
contract ISuperToken token,
address flowOperator,
bytes ctx
)
internal
returns (bytes newCtx)function revokeFlowPermissionsWithCtx(
contract ISuperToken token,
address flowOperator,
bytes ctx
)
internal
returns (bytes newCtx)function createFlowFrom(
contract ISuperToken token,
address sender,
address receiver,
int96 flowRate
)
internal
returns (bool)function createFlowFrom(
contract ISuperToken token,
address sender,
address receiver,
int96 flowRate,
bytes userData
)
internal
returns (bool)function updateFlowFrom(
contract ISuperToken token,
address sender,
address receiver,
int96 flowRate
)
internal
returns (bool)function updateFlowFrom(
contract ISuperToken token,
address sender,
address receiver,
int96 flowRate,
bytes userData
)
internal
returns (bool)function deleteFlowFrom(
contract ISuperToken token,
address sender,
address receiver
)
internal
returns (bool)function deleteFlowFrom(
contract ISuperToken token,
address sender,
address receiver,
bytes userData
)
internal
returns (bool)function createFlowWithCtx(
contract ISuperToken token,
address receiver,
int96 flowRate,
bytes ctx
)
internal
returns (bytes newCtx)function createFlowFromWithCtx(
contract ISuperToken token,
address sender,
address receiver,
int96 flowRate,
bytes ctx
)
internal
returns (bytes newCtx)function updateFlowWithCtx(
contract ISuperToken token,
address receiver,
int96 flowRate,
bytes ctx
)
internal
returns (bytes newCtx)function updateFlowFromWithCtx(
contract ISuperToken token,
address sender,
address receiver,
int96 flowRate,
bytes ctx
)
internal
returns (bytes newCtx)function deleteFlowWithCtx(
contract ISuperToken token,
address sender,
address receiver,
bytes ctx
)
internal
returns (bytes newCtx)function deleteFlowFromWithCtx(
contract ISuperToken token,
address sender,
address receiver,
bytes ctx
)
internal
returns (bytes newCtx)function getFlowRate(
contract ISuperToken token,
address sender,
address receiver
)
internal
returns (int96 flowRate)function getFlowInfo(
contract ISuperToken token,
address sender,
address receiver
)
internal
returns (uint256 lastUpdated, int96 flowRate, uint256 deposit, uint256 owedDeposit)function getNetFlowRate(
contract ISuperToken token,
address account
)
internal
returns (int96 flowRate)function getCFANetFlowRate(
contract ISuperToken token,
address account
)
internal
returns (int96 flowRate)function getGDANetFlowRate(
contract ISuperToken token,
address account
)
internal
returns (int96 flowRate)function getNetFlowInfo(
contract ISuperToken token,
address account
)
internal
returns (uint256 lastUpdated, int96 flowRate, uint256 deposit, uint256 owedDeposit)function getBufferAmountByFlowRate(
contract ISuperToken token,
int96 flowRate
)
internal
returns (uint256 bufferAmount)function getFlowPermissions(
contract ISuperToken token,
address sender,
address flowOperator
)
internal
returns (bool allowCreate, bool allowUpdate, bool allowDelete, int96 flowRateAllowance)function getIndex(
contract ISuperToken token,
address publisher,
uint32 indexId
)
internal
returns (bool exist, uint128 indexValue, uint128 totalUnitsApproved, uint128 totalUnitsPending)function calculateDistribution(
contract ISuperToken token,
address publisher,
uint32 indexId,
uint256 amount
)
internal
returns (uint256 actualAmount, uint128 newIndexValue)function listSubscriptions(
contract ISuperToken token,
address subscriber
)
internal
returns (address[] publishers, uint32[] indexIds, uint128[] unitsList)function getSubscription(
contract ISuperToken token,
address publisher,
uint32 indexId,
address subscriber
)
internal
returns (bool exist, bool approved, uint128 units, uint256 pendingDistribution)function getSubscriptionByID(
contract ISuperToken token,
bytes32 agreementId
)
internal
returns (address publisher, uint32 indexId, bool approved, uint128 units, uint256 pendingDistribution)function getFlowDistributionFlowRate(
contract ISuperToken token,
address from,
contract ITagomiPool to
)
internal
returns (int96)function estimateFlowDistributionActualFlowRate(
contract ISuperToken token,
address from,
contract ITagomiPool to,
int96 requestedFlowRate
)
internal
returns (int96 actualFlowRate, int96 totalDistributionFlowRate)function estimateDistributionActualAmount(
contract ISuperToken token,
address from,
contract ITagomiPool to,
uint256 requestedAmount
)
internal
returns (uint256 actualAmount)function isMemberConnected(
contract ISuperToken token,
address pool,
address member
)
internal
returns (bool)function createIndex(
contract ISuperToken token,
uint32 indexId
)
internal
returns (bool)function createIndex(
contract ISuperToken token,
uint32 indexId,
bytes userData
)
internal
returns (bool)function updateIndexValue(
contract ISuperToken token,
uint32 indexId,
uint128 indexValue
)
internal
returns (bool)function updateIndexValue(
contract ISuperToken token,
uint32 indexId,
uint128 indexValue,
bytes userData
)
internal
returns (bool)function distribute(
contract ISuperToken token,
uint32 indexId,
uint256 amount
)
internal
returns (bool)function distribute(
contract ISuperToken token,
uint32 indexId,
uint256 amount,
bytes userData
)
internal
returns (bool)function approveSubscription(
contract ISuperToken token,
address publisher,
uint32 indexId
)
internal
returns (bool)function approveSubscription(
contract ISuperToken token,
address publisher,
uint32 indexId,
bytes userData
)
internal
returns (bool)function revokeSubscription(
contract ISuperToken token,
address publisher,
uint32 indexId
)
internal
returns (bool)function revokeSubscription(
contract ISuperToken token,
address publisher,
uint32 indexId,
bytes userData
)
internal
returns (bool)function updateSubscriptionUnits(
contract ISuperToken token,
uint32 indexId,
address subscriber,
uint128 units
)
internal
returns (bool)function updateSubscriptionUnits(
contract ISuperToken token,
uint32 indexId,
address subscriber,
uint128 units,
bytes userData
)
internal
returns (bool)function deleteSubscription(
contract ISuperToken token,
address publisher,
uint32 indexId,
address subscriber
)
internal
returns (bool)function deleteSubscription(
contract ISuperToken token,
address publisher,
uint32 indexId,
address subscriber,
bytes userData
)
internal
returns (bool)function claim(
contract ISuperToken token,
address publisher,
uint32 indexId,
address subscriber
)
internal
returns (bool)function claim(
contract ISuperToken token,
address publisher,
uint32 indexId,
address subscriber,
bytes userData
)
internal
returns (bool)function createIndexWithCtx(
contract ISuperToken token,
uint32 indexId,
bytes ctx
)
internal
returns (bytes newCtx)function updateIndexValueWithCtx(
contract ISuperToken token,
uint32 indexId,
uint128 indexValue,
bytes ctx
)
internal
returns (bytes newCtx)function distributeWithCtx(
contract ISuperToken token,
uint32 indexId,
uint256 amount,
bytes ctx
)
internal
returns (bytes newCtx)function approveSubscriptionWithCtx(
contract ISuperToken token,
address publisher,
uint32 indexId,
bytes ctx
)
internal
returns (bytes newCtx)function revokeSubscriptionWithCtx(
contract ISuperToken token,
address publisher,
uint32 indexId,
bytes ctx
)
internal
returns (bytes newCtx)function updateSubscriptionUnitsWithCtx(
contract ISuperToken token,
uint32 indexId,
address subscriber,
uint128 units,
bytes ctx
)
internal
returns (bytes newCtx)function deleteSubscriptionWithCtx(
contract ISuperToken token,
address publisher,
uint32 indexId,
address subscriber,
bytes ctx
)
internal
returns (bytes newCtx)function claimWithCtx(
contract ISuperToken token,
address publisher,
uint32 indexId,
address subscriber,
bytes ctx
)
internal
returns (bytes newCtx)function createPool(
contract ISuperToken token,
address admin,
struct PoolConfig poolConfig
)
internal
returns (contract ITagomiPool pool)struct PoolConfig {
bool transferabilityForUnitsOwner;
bool distributionFromAnyAddress;
}function updateMemberUnits(
contract ISuperToken token,
contract ITagomiPool pool,
address memberAddress,
uint128 newUnits
)
internal
returns (bool)function updateMemberUnits(
contract ISuperToken token,
contract ITagomiPool pool,
address memberAddress,
uint128 newUnits,
bytes userData
)
internal
returns (bool)function claimAll(
contract ISuperToken token,
contract ITagomiPool pool,
address memberAddress
)
internal
returns (bool)function claimAll(
contract ISuperToken token,
contract ITagomiPool pool,
address memberAddress,
bytes userData
)
internal
returns (bool)function connectPool(
contract ISuperToken token,
contract ITagomiPool pool
)
internal
returns (bool)function connectPool(
contract ISuperToken token,
contract ITagomiPool pool,
bytes userData
)
internal
returns (bool)function disconnectPool(
contract ISuperToken token,
contract ITagomiPool pool
)
internal
returns (bool)function disconnectPool(
contract ISuperToken token,
contract ITagomiPool pool,
bytes userData
)
internal
returns (bool)function distributeToPool(
contract ISuperToken token,
address from,
contract ITagomiPool pool,
uint256 requestedAmount
)
internal
returns (bool)function distribute(
contract ISuperToken token,
address from,
contract ITagomiPool pool,
uint256 requestedAmount,
bytes userData
)
internal
returns (bool)function distributeFlow(
contract ISuperToken token,
address from,
contract ITagomiPool pool,
int96 requestedFlowRate
)
internal
returns (bool)function distributeFlow(
contract ISuperToken token,
address from,
contract ITagomiPool pool,
int96 requestedFlowRate,
bytes userData
)
internal
returns (bool)function updateMemberUnitsWithCtx(
contract ISuperToken token,
contract ITagomiPool pool,
address memberAddress,
uint128 newUnits,
bytes ctx
)
internal
returns (bytes newCtx)function claimAllWithCtx(
contract ISuperToken token,
contract ITagomiPool pool,
address memberAddress,
bytes ctx
)
internal
returns (bytes newCtx)function connectPoolWithCtx(
contract ISuperToken token,
contract ITagomiPool pool,
bytes ctx
)
internal
returns (bytes newCtx)function disconnectPoolWithCtx(
contract ISuperToken token,
contract ITagomiPool pool,
bytes ctx
)
internal
returns (bytes newCtx)function distributeWithCtx(
contract ISuperToken token,
address from,
contract ITagomiPool pool,
uint256 requestedAmount,
bytes ctx
)
internal
returns (bytes newCtx)function distributeFlowWithCtx(
contract ISuperToken token,
address from,
contract ITagomiPool pool,
int96 requestedFlowRate,
bytes ctx
)
internal
returns (bytes newCtx)error CFA_FWD_INVALID_FLOW_RATE()contract IConstantFlowAgreementV1 _cfafunction constructor(
contract ITagomi host
)
publicfunction setFlowrate(address token, address receiver, int96 flowrate) nonpayable returns (bool)function setFlowrateFrom(
address token,
address sender,
address receiver,
int96 flowrate
) nonpayable returns (bool)function getFlowrate(address token, address sender, address receiver) view returns (int96 flowrate)function getFlowInfo(address token, address sender, address receiver) view returns (
uint256 lastUpdated,
int96 flowrate,
uint256 deposit,
uint256 owedDeposit
)function getBufferAmountByFlowrate(
contract ISuperToken token,
int96 flowrate
)
external
returns (uint256 bufferAmount)function getBufferAmountByFlowrate(address token, int96 flowrate) view returns (uint256 bufferAmount)function getAccountFlowrate(address token, address account) view returns (int96 flowrate)function getAccountFlowInfo(address token, address account) view returns (
uint256 lastUpdated,
int96 flowrate,
uint256 deposit,
uint256 owedDeposit
)function createFlow(
address token,
address sender,
address receiver,
int96 flowrate,
bytes userData
) nonpayable returns (bool)function updateFlow(
address token,
address sender,
address receiver,
int96 flowrate,
bytes userData
) nonpayable returns (bool)function deleteFlow(
address token,
address sender,
address receiver,
bytes userData
) nonpayable returns (bool)function grantPermissions(address token, address flowOperator) nonpayable returns (bool)function revokePermissions(address token, address flowOperator) nonpayable returns (bool)function updateFlowOperatorPermissions(
address token,
address flowOperator,
uint8 permissions,
int96 flowrateAllowance
) nonpayable returns (bool)function getFlowOperatorPermissions(address token, address sender, address flowOperator) view returns (uint8 permissions, int96 flowrateAllowance)function setFlowrateFrom(
address token,
address sender,
address receiver,
int96 flowrate
) nonpayable returns (bool)function createFlow(
address token,
address sender,
address receiver,
int96 flowrate,
bytes userData
) nonpayable returns (bool)function updateFlow(
address token,
address sender,
address receiver,
int96 flowrate,
bytes userData
) nonpayable returns (bool)function deleteFlow(
address token,
address sender,
address receiver,
bytes userData
) nonpayable returns (bool)function updateFlowOperatorPermissions(
address token,
address flowOperator,
uint8 permissions,
int96 flowrateAllowance
) nonpayable returns (bool)ISETH is the interface for native Super Tokens.
In order to interact with any contract satistying the ISETH interface, you can use the following ABI:
Parameters
Parameters
Super ETH (SETH) full interface
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).
Severity
Description
Bug Bounty
Critical
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.
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 bounties will be paid in USDC. Alternative payment methods can be used on a case-by-case basis.
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)
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
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
February 2025 and after
Bitcoin Staking: Hold Bitcoin, Earn Altcoin Yield.
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.
Tagomi Protocol introduces innovative methods for community engagement and social token incentives, fostering long-term loyalty and participation.
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.
This is the technical reference related to the interface for Super Tokens.
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.
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
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
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
Multiple payment gateway integration
Reached 1 million app downloads
Integrate all the experiments from 2023 into the Tagomi app
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.
to
address
wad
uint256
Parameters
token
contract ITagomiToken
member
address
oldUnits
uint128
newUnits
uint128
Parameters
token
contract ITagomiToken
member
address
claimedAmount
int256
totalClaimed
int256
A boolean indicating whether pool members can transfer their units
A boolean indicating whether addresses other than the pool admin can distribute via the pool
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
The SuperToken for the pool
The total units of the pool
The total number of units of connected members
The total number of units of disconnected members
Parameters
memberAddress
address
The address of the member
The total number of units for memberAddress
The total flow rate of the pool
The flow rate of the connected members
The flow rate of the disconnected members
Parameters
time
uint32
The time to query
The balance of all the disconnected members at time
Parameters
memberAddress
address
The address of the member
The flow rate a member is receiving from the pool
Parameters
memberAddr
address
The address of the member
time
uint32
The time to query
The claimable balance for memberAddr at time in the pool
Parameters
memberAddr
address
The address of the member
The claimable balance for memberAddr at block.timestamp in the pool
Parameters
memberAddr
address
The address of the member
newUnits
uint128
The new units for the member
Sets memberAddr ownedUnits to newUnits
Parameters
memberAddr
address
The address of the member
Claims the claimable balance for memberAddr at block.timestamp
Claims the claimable balance for msg.sender at block.timestamp
Parameters
spender
address
The address of the spender
addedValue
uint256
The amount to increase the allowance by
Return Values
[0]
bool
true if successful
Increases the allowance of spender by addedValue
Parameters
spender
address
The address of the spender
subtractedValue
uint256
The amount to decrease the allowance by
Return Values
[0]
bool
true if successful
Decreases the allowance of spender by subtractedValue
function upgradeByETH(
)
externalfunction upgradeByETHTo(
address to
)
externalfunction downgradeToETH(
uint256 wad
)
externalstruct PoolIndexData {
uint128 totalUnits;
uint32 wrappedSettledAt;
int96 wrappedFlowRate;
int256 wrappedSettledValue;
}struct MemberData {
uint128 ownedUnits;
uint32 syncedSettledAt;
int96 syncedFlowRate;
int256 syncedSettledValue;
int256 settledValue;
int256 claimedValue;
}error Tagomi_POOL_INVALID_TIME()error Tagomi_POOL_NO_POOL_MEMBERS()error Tagomi_POOL_NO_ZERO_ADDRESS()error Tagomi_POOL_NOT_POOL_ADMIN_OR_GDA()error Tagomi_POOL_NOT_GDA()error Tagomi_POOL_TRANSFER_UNITS_NOT_ALLOWED()event MemberUnitsUpdated(
contract ITagomiToken token,
address member,
uint128 oldUnits,
uint128 newUnits
)event DistributionClaimed(
contract ITagomiToken token,
address member,
int256 claimedAmount,
int256 totalClaimed
)function transferabilityForUnitsOwner(
)
external
returns (bool)function distributionFromAnyAddress(
)
external
returns (bool)function admin(
)
external
returns (address)function superToken(
)
external
returns (contract ITagomiToken)function getTotalUnits(
)
external
returns (uint128)function getTotalConnectedUnits(
)
external
returns (uint128)function getTotalDisconnectedUnits(
)
external
returns (uint128)function getUnits(
address memberAddress
)
external
returns (uint128)function getTotalFlowRate(
)
external
returns (int96)function getTotalConnectedFlowRate(
)
external
returns (int96)function getTotalDisconnectedFlowRate(
)
external
returns (int96)function getDisconnectedBalance(
uint32 time
)
external
returns (int256 balance)function getMemberFlowRate(
address memberAddress
)
external
returns (int96)function getClaimable(
address memberAddr,
uint32 time
)
external
returns (int256)function getClaimableNow(
address memberAddr
)
external
returns (int256 claimableBalance, uint256 timestamp)function updateMemberUnits(
address memberAddr,
uint128 newUnits
)
external
returns (bool)function claimAll(
address memberAddr
)
external
returns (bool)function claimAll(
)
external
returns (bool)function increaseAllowance(
address spender,
uint256 addedValue
)
external
returns (bool)function decreaseAllowance(
address spender,
uint256 subtractedValue
)
external
returns (bool)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).
Scope: protocol-v2
Authored: May 10th 2024
Last Updated: June 27th 2024
View the full report here(opens in a new tab).
Scope: Metamask Snap "Connect" by Drift(opens in a new tab)
View the full report here
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.
The PCR model within the Tagomi Protocol offers a scalable way to incentivize community actions based on specific Key Performance Indicators (KPIs).
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
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.
In order to interact with any contract satistying the ISuperToken interface, you can use the following ABI:
Initialize the contract
Parameters
underlyingToken
contract IERC20
underlyingDecimals
uint8
n
string
s
string
Initialize the contract with an admin
Parameters
underlyingToken
contract IERC20
underlyingDecimals
uint8
n
string
s
string
Only the current admin can call this function if admin is address(0), it is implicitly the host address
Parameters
newAdmin
address
New admin address
Changes the admin for the SuperToken
Returns the admin address for the SuperToken
Returns the name of the token.
Returns the symbol of the token, usually a shorter version of the name.
_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.
See IBEP20-totalSupply.
Returns the amount of tokens owned by an account (owner).
Parameters
account
address
Moves amount tokens from the caller's account to recipient.
Parameters
recipient
address
amount
uint256
Return Values
[0]
bool
Returns Success a boolean value indicating whether the operation succeeded.
Emits
a BEP20 Transfer event.
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
owner
address
spender
address
This value changes when approve or transferFrom are called.
Sets amount as the allowance of spender over the caller's tokens.
Parameters
spender
address
amount
uint256
Return Values
[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.
Moves amount tokens from sender to recipient using the allowance mechanism. amount is then deducted from the caller's allowance.
Parameters
sender
address
recipient
address
amount
uint256
Return Values
[0]
bool
Returns Success a boolean value indicating whether the operation succeeded.
Emits
a Transfer event.
_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
spender
address
addedValue
uint256
Emits
an Approval event indicating the updated allowance.
@custom:requirements
`spender` cannot be the zero address.
_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
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`.
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
_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
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.
_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
amount
uint256
userData
bytes
Emits
a Burned event.
@custom:requirements
the caller must have at least `amount` tokens.
_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
operator
address
tokenHolder
address
_Make an account an operator of the caller.
See isOperatorFor._
Parameters
operator
address
Emits
an AuthorizedOperator event.
@custom:requirements
`operator` cannot be calling address.
_Revoke an account's operator status for the caller.
See isOperatorFor and defaultOperators._
Parameters
operator
address
Emits
a RevokedOperator event.
@custom:requirements
`operator` cannot be calling 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._
_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
sender
address
recipient
address
amount
uint256
userData
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.
_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
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`.
_Mint new tokens for the account If userData is not empty, the tokensReceived hook is invoked according to ERC777 semantics.
@custom:modifiers
onlySelf_
Parameters
account
address
amount
uint256
userData
bytes
_Burn existing tokens for the account If userData is not empty, the tokensToSend hook is invoked according to ERC777 semantics.
@custom:modifiers
onlySelf_
Parameters
account
address
amount
uint256
userData
bytes
_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
sender
address
spender
address
recipient
address
amount
uint256
_Give spender, amount allowance to spend the tokens of account.
@custom:modifiers
onlySelf_
Parameters
account
address
spender
address
amount
uint256
Transfer all available balance from msg.sender to recipient
Parameters
recipient
address
Return the underlying token contract
Return Values
tokenAddr
address
Underlying token address
Return the underlying token decimals
Return Values
underlyingDecimals
uint8
Underlying token decimals
Return the underlying token conversion rate
Parameters
amount
uint256
Number of tokens to be upgraded (in 18 decimals)
Return Values
underlyingAmount
uint256
The underlying token amount after scaling
adjustedAmount
uint256
The super token amount after scaling
Upgrade ERC20 to SuperToken.
Parameters
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
Upgrade BEP20 to SuperToken and transfer immediately
Parameters
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.
Downgrade SuperToken to ERC20. It will call transfer to send tokens
Parameters
amount
uint256
Number of tokens to be downgraded
Downgrade SuperToken to BEP20 and transfer immediately
Parameters
to
address
The account to receive downgraded tokens
amount
uint256
Number of tokens to be downgraded (in 18 decimals)
Perform BEP20 approve by host contract.
Parameters
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 |
Parameters
account
address
spender
address
addedValue
uint256
Parameters
account
address
spender
address
subtractedValue
uint256
Perform ERC20 transferFrom by host contract.
Parameters
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 |
Perform ERC777 send by host contract.
Parameters
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 |
Upgrade ERC20 to SuperToken by host contract.
Parameters
account
address
The account to be changed.
amount
uint256
Number of tokens to be upgraded (in 18 decimals)
@custom:modifiers
onlyHost |
Downgrade ERC20 to SuperToken by host contract.
Parameters
account
address
The account to be changed.
amount
uint256
Number of tokens to be downgraded (in 18 decimals)
@custom:modifiers
onlyHost |
Parameters
oldAdmin
address
newAdmin
address
Token upgrade event
Parameters
account
address
Account where tokens are upgraded to
amount
uint256
Amount of tokens upgraded (in 18 decimals)
Token downgrade event
Parameters
account
address
Account whose tokens are downgraded
amount
uint256
Amount of tokens downgraded
Constant Outflow NFT proxy created event
Parameters
constantOutflowNFT
contract IConstantOutflowNFT
constant outflow nft address
Constant Inflow NFT proxy created event
Parameters
constantInflowNFT
contract IConstantInflowNFT
constant inflow nft address
Pool Admin NFT proxy created event
Parameters
poolAdminNFT
contract IPoolAdminNFT
pool admin nft address
Pool Member NFT proxy created event
Parameters
poolMemberNFT
contract IPoolMemberNFT
pool member nft address
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.
The GDAv1Forwarder contract address is the same on all Tagomi chains:
In order to interact with the GDAv1Forwarder contract, you can use the following ABI:
Parameters
Try it out
Creates a new Tagomi Pool.
Parameters
Return Values
Try it out
Updates the units of a pool member.
Parameters
Try it out
Claims all tokens from the pool.
Parameters
Try it out
Connects a pool member to pool.
Parameters
Return Values
Try it out
Disconnects a pool member from pool.
Parameters
Return Values
Try it out
Tries to distribute requestedAmount amount of token from from to pool.
Parameters
Return Values
Try it out
Tries to distribute flow at requestedFlowRate of token from from to pool.
Parameters
Return Values
Try it out
Checks if the specified account is a pool.
Parameters
Return Values
Try it out
Gets the GDA net flow rate for the specified account.
Parameters
Return Values
Try it out
Gets the flow rate of tokens between the specified accounts.
Parameters
Return Values
Try it out
Gets the pool adjustment flow rate for the specified pool.
Parameters
Return Values
Try it out
Estimates the actual flow rate for flow distribution to the specified pool.
Parameters
Return Values
Try it out
Estimates the actual amount for distribution to the specified pool.
Parameters
Return Values
Try it out
Checks if the specified member is connected to the pool.
Parameters
Return Values
Try it out
Gets the pool adjustment flow information for the specified pool.
Parameters
Return Values
function initialize(
contract IERC20 underlyingToken,
uint8 underlyingDecimals,
string n,
string s
)
externalfunction initializeWithAdmin(
contract IERC20 underlyingToken,
uint8 underlyingDecimals,
string n,
string s,
address admin
)
externalfunction changeAdmin(
address newAdmin
)
externalfunction getAdmin(
)
external
returns (address admin)function CONSTANT_OUTFLOW_NFT(
)
external
returns (contract IConstantOutflowNFT)function CONSTANT_INFLOW_NFT(
)
external
returns (contract IConstantInflowNFT)function POOL_ADMIN_NFT(
)
external
returns (contract IPoolAdminNFT)function POOL_MEMBER_NFT(
)
external
returns (contract IPoolMemberNFT)function name(
)
external
returns (string)function symbol(
)
external
returns (string)function decimals(
)
external
returns (uint8)function totalSupply(
)
external
returns (uint256)function balanceOf(
address account
)
external
returns (uint256 balance)function transfer(
address recipient,
uint256 amount
)
external
returns (bool)function allowance(
address owner,
address spender
)
external
returns (uint256)function approve(
address spender,
uint256 amount
)
external
returns (bool)function transferFrom(
address sender,
address recipient,
uint256 amount
)
external
returns (bool)function increaseAllowance(
address spender,
uint256 addedValue
)
external
returns (bool)function decreaseAllowance(
address spender,
uint256 subtractedValue
)
external
returns (bool)function granularity(
)
external
returns (uint256)function send(
address recipient,
uint256 amount,
bytes userData
)
externalfunction burn(
uint256 amount,
bytes userData
)
externalfunction isOperatorFor(
address operator,
address tokenHolder
)
external
returns (bool)function authorizeOperator(
address operator
)
externalfunction revokeOperator(
address operator
)
externalfunction defaultOperators(
)
external
returns (address[])function operatorSend(
address sender,
address recipient,
uint256 amount,
bytes userData,
bytes operatorData
)
externalfunction operatorBurn(
address account,
uint256 amount,
bytes userData,
bytes operatorData
)
externalfunction selfMint(
address account,
uint256 amount,
bytes userData
)
externalfunction selfBurn(
address account,
uint256 amount,
bytes userData
)
externalfunction selfTransferFrom(
address sender,
address spender,
address recipient,
uint256 amount
)
externalfunction selfApproveFor(
address account,
address spender,
uint256 amount
)
externalfunction transferAll(
address recipient
)
externalfunction getUnderlyingToken(
)
external
returns (address tokenAddr)function getUnderlyingDecimals(
)
external
returns (uint8 underlyingDecimals)function toUnderlyingAmount(
uint256 amount
)
external
returns (uint256 underlyingAmount, uint256 adjustedAmount)function upgrade(
uint256 amount
)
externalfunction upgradeTo(
address to,
uint256 amount,
bytes userData
)
externalfunction downgrade(
uint256 amount
)
externalfunction downgradeTo(
address to,
uint256 amount
)
externalfunction operationApprove(
address account,
address spender,
uint256 amount
)
externalfunction operationIncreaseAllowance(
address account,
address spender,
uint256 addedValue
)
externalfunction operationDecreaseAllowance(
address account,
address spender,
uint256 subtractedValue
)
externalfunction operationTransferFrom(
address account,
address spender,
address recipient,
uint256 amount
)
externalfunction operationSend(
address spender,
address recipient,
uint256 amount,
bytes userData
)
externalfunction operationUpgrade(
address account,
uint256 amount
)
externalfunction operationDowngrade(
address account,
uint256 amount
)
externalevent AdminChanged(
address oldAdmin,
address newAdmin
)event TokenUpgraded(
address account,
uint256 amount
)event TokenDowngraded(
address account,
uint256 amount
)event ConstantOutflowNFTCreated(
contract IConstantOutflowNFT constantOutflowNFT
)event ConstantInflowNFTCreated(
contract IConstantInflowNFT constantInflowNFT
)event PoolAdminNFTCreated(
contract IPoolAdminNFT poolAdminNFT
)event PoolMemberNFTCreated(
contract IPoolMemberNFT poolMemberNFT
)error SUPER_TOKEN_CALLER_IS_NOT_OPERATOR_FOR_HOLDER()error SUPER_TOKEN_NOT_ERC777_TOKENS_RECIPIENT()error SUPER_TOKEN_INFLATIONARY_DEFLATIONARY_NOT_SUPPORTED()error SUPER_TOKEN_NO_UNDERLYING_TOKEN()error SUPER_TOKEN_ONLY_SELF()error SUPER_TOKEN_ONLY_ADMIN()error SUPER_TOKEN_ONLY_GOV_OWNER()error SUPER_TOKEN_APPROVE_FROM_ZERO_ADDRESS()error SUPER_TOKEN_APPROVE_TO_ZERO_ADDRESS()error SUPER_TOKEN_BURN_FROM_ZERO_ADDRESS()error SUPER_TOKEN_MINT_TO_ZERO_ADDRESS()error SUPER_TOKEN_TRANSFER_FROM_ZERO_ADDRESS()error SUPER_TOKEN_TRANSFER_TO_ZERO_ADDRESS()error SUPER_TOKEN_NFT_PROXY_ADDRESS_CHANGED()0x6DA13Bde224A05a288748d857b9e7DDEffd1dE08admin
address
operatorData
bytes
userData
bytes
User-specific data.
userData
bytes
User-specific data.
host
contract ITagomi
token
contract ITagomiToken
The Super Token address.
admin
address
The pool admin address.
config
struct PoolConfig
The pool configuration (see PoolConfig in IGeneralDistributionAgreementV1.sol)
success
bool
A boolean value indicating whether the pool was created successfully.
pool
contract ITagomiPool
The address of the deployed Tagomi Pool
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.
pool
contract ITagomiPool
The Tagomi Pool to claim from.
memberAddress
address
The address of the member to claim for.
userData
bytes
User-specific data.
pool
contract ITagomiPool
The Tagomi Pool to connect.
userData
bytes
User-specific data.
[0]
bool
A boolean value indicating whether the connection was successful.
pool
contract ITagomiPool
The Tagomi Pool to disconnect.
userData
bytes
User-specific data.
[0]
bool
A boolean value indicating whether the disconnection was successful.
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.
[0]
bool
A boolean value indicating whether the distribution was successful.
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.
[0]
bool
A boolean value indicating whether the distribution was successful.
token
contract ITagomiToken
The Super Token address.
account
address
The account address to check.
[0]
bool
A boolean value indicating whether the account is a pool.
token
contract ITagomiToken
The Super Token address.
account
address
The account address.
[0]
int96
The gda net flow rate for the account.
token
contract ITagomiToken
The Super Token address.
from
address
The sender address.
to
contract ITagomiPool
The receiver address (the pool address).
[0]
int96
The flow distribution flow rate
pool
address
The pool address.
[0]
int96
The pool adjustment flow rate.
token
contract ITagomiToken
The Super Token address.
from
address
The sender address.
to
contract ITagomiPool
The pool address.
requestedFlowRate
int96
The requested flow rate.
actualFlowRate
int96
totalDistributionFlowRate
int96
token
contract ITagomiToken
The Super Token address.
from
address
The sender address.
to
contract ITagomiPool
The pool address.
requestedAmount
uint256
The requested amount.
actualAmount
uint256
The actual amount for distribution.
pool
contract ITagomiPool
The Tagomi Pool address.
member
address
The member address.
[0]
bool
A boolean value indicating whether the member is connected to the pool.
pool
contract ITagomiPool
The pool address.
[0]
address
The pool admin, pool ID, and pool adjustment flow rate.
[1]
bytes32
[2]
int96
contract IGeneralDistributionAgreementV1 _gdafunction constructor(
contract ITagomi host
)
publicfunction createPool(address token, address admin, tuple config) nonpayable returns (bool success, address pool)function updateMemberUnits(
address pool,
address memberAddress,
uint128 newUnits,
bytes userData
) nonpayable returns (bool success)function claimAll(address pool, address memberAddress, bytes userData) nonpayable returns (bool success)function connectPool(address pool, bytes userData) nonpayable returns (bool)function disconnectPool(address pool, bytes userData) nonpayable returns (bool)function distribute(
address token,
address from,
address pool,
uint256 requestedAmount,
bytes userData
) nonpayable returns (bool)function distributeFlow(
address token,
address from,
address pool,
int96 requestedFlowRate,
bytes userData
) nonpayable returns (bool)function isPool(address token, address account) view returns (bool)function getNetFlow(address token, address account) view returns (int96)function getFlowDistributionFlowRate(address token, address from, address to) view returns (int96)function getPoolAdjustmentFlowRate(address pool) view returns (int96)function estimateFlowDistributionActualFlowRate(
address token,
address from,
address to,
int96 requestedFlowRate
) view returns (
int96 actualFlowRate,
int96 totalDistributionFlowRate
)function estimateDistributionActualAmount(
address token,
address from,
address to,
uint256 requestedAmount
) view returns (uint256 actualAmount)function isMemberConnected(address pool, address member) view returns (bool)function getPoolAdjustmentFlowInfo(address pool) view returns (address, bytes32, int96)
