Tagomi is a revolutionary asset streaming and distribution protocol bringing subscriptions, salaries, vesting, and rewards to DAOs and crypto-native businesses worldwide. This is made possible by the protocol’s smart contract framework which introduces the Super Token - an extension to the BEP-20 standard enabling the transfer of value in completely novel ways.
Super Tokens
The Tagomi protocol is designed to be a "token-centric" protocol, in that all of its functionalities revolve around the concept of Super Tokens. The framework & Super Token standard can be used to add dynamic balances to tokens on chain, describing cash flows and executing them automatically over time in a non-interactive way. Any token can be transferred in Tagomi streams or distributions, which are programmable, composable, and modular. No capital is locked up, and all inflows and outflows are netted in real-time at every block without consuming any gas. The code is fully open source, while the protocol is non-custodial and permissionless.
The Tagomi Protocol has currently two main pillars that define its interactions with Super Tokens. These pillars (formerly called Agreements) are the following:
Money Streaming - A set of features that enable the creation of money streams between two parties.
Distributions - A set of features that enables the creation of a pool of funds that can be distributed to multiple recipients.
We go in further details about these two pillars in the next sections.
Money Streaming
Definition
Money Streaming is a continuous transfer of tokens from a sender to a receiver at a defined per-second rate, resulting in a "stream". This stream is perpetual and persists until it's canceled by either the sender or the receiver, or until the sender's Super Token balance is depleted.
Explanation
Money Streaming is a novel approach to token transfers, offering a dynamic way of sending funds. Instead of one-time transactions, tokens flow from the sender to the receiver continuously, creating a stream. This method provides real-time financial transactions, enabling a more fluid movement of assets over time, reflecting real-world economic activities more closely.
Example
A visualization of money streaming from the Tagomi dashboard
Consider Alice wants to pay Bob a salary of 1200 USDCx per year using Money Streaming. She sets up a stream with a flow rate of 0.038 USDCx per second. Bob's balance starts increasing every second, and Alice's decreases, ensuring a steady transfer of salary.
Distributions
Definition
Distributions in Tagomi refer to a scalable one-to-many fund transfer method. It involves creating pools with a pool admin managing units for members, who can receive funds instantly or through continuous streaming.
Explanation
Distributions are a significant advancement in decentralized finance, enabling efficient and scalable fund transfers among multiple recipients. This method is especially useful for scenarios where funds need to be distributed among many parties, like dividends or rewards, ensuring equitable and automated distribution based on predefined units.
Example
Imagine a DeFi project creating a reward pool for liquidity providers. The project sets up a distribution pool with a total of 1000 units. If a liquidity provider has 100 units, they receive 10% of the total funds distributed through the pool, either instantly or as a continuous stream, depending on the distribution method.
The introduction of Distributions marks a significant advancement in DeFi applications, offering a scalable method for one-to-many fund transfers. Distributions allow for the transfer of value to multiple recipients with minimal on-chain data modification, making them infinitely scalable, highly efficient and gas-friendly.
note
There are other on-chain solutions that may seem to solve this problem without using a new token implementation (e.g Disperse App). While these solutions can be great for a low amount of recipients, they are not infinitely scalable and can become very expensive as the number of recipients increases. Furthermore, they do not allow for distributing money streaming
Overview
Distributions function by allowing for the creation of pools with a designated pool admin who manages units for pool members. Members of these pools can receive funds either instantly or through continuous streaming, making this method highly efficient and scalable. There are two types of Distributions:
Instant Distributions: They allow one transaction distribution to any number of receivers with a fixed gas cost.
Streaming Distributions: They allow for continuous distribution of funds to receivers through Money Streaming to a Pool.
Instant Distribution
Streaming Distribution
Instant Distributions allow one transaction to distribute to any number of receivers with a fixed gas cost.
Click on the Blue Circle to initiate an Instant Distribution
Distribution PoolClick to distribute a tokenMember AMember BMember CMember DMember E
By creating a Distribution Pool, you can distribute any token instantly
Definitions
Pool: A channel for proportional token distribution.
Distribution: The action of allocating specified token amounts to receivers.
Units: Represent the proportion of the distribution each subscriber receives.
Key Features
Pools as Contracts: Unlike previous approaches, pools in streaming distributions are contracts and can be ERC20 tokens. This allows pool members to transfer units among themselves, which wasn't possible earlier.
Roles and Permissions: A pool admin can grant and revoke units, while any account can act as a distributor to execute fund distributions.
Distribution Methods: There are two primary ways to distribute funds:
High-Level Workflow
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 Examples
Streaming Distribution Illustration
This diagram shows a distributor streaming funds to various pool members, each holding different unit amounts. Note: A single transaction can cater to multiple members.
Adjusting Unit Counts
Here, a distributor modifies unit counts for members. This change instantly alters the distribution rate for all members in one transaction. Batch updates can be done using Tagomi's batch call.
Modifying the Flow Rate
This example demonstrates how a change in the distributor's streaming rate affects the total flow rate of the pool, thus instantly impacting each member's rate.
Advanced Pool Features
As pools are also ERC20 tokens, they enable:
Transfer of Units: Pool members can freely transfer their units.
Delegated Transfers: Using the approve and transferFrom functions, units can be transferred on behalf of a member.
These features add composability and flexibility, expanding the potential use cases for pools in web3.
Pool Admin: The administrator of the distribution process.
Subscribers/Pool Member: Receivers allocated units and eligible to receive tokens through the Index.
Instant Distribution: Calculated as distributionAmount * (poolMemberUnits / poolTotalUnits).
Streaming Distribution: Determined by poolFlowRate * (poolMemberUnits / poolTotalUnits).
Gas Efficiency: The cost of executing distributions remains constant, regardless of the number of pool members.
Distribution Execution: Distributors can initiate either instant or streaming distributions, which are then divided among pool members based on their unit share.
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.
Netflow Rate: The rate of change of an account's Super Token balance per second.
Sender: The account initiating the stream, specifying a receiver and flow rate.
Receiver: The account on the receiving end of a stream.
: The timestamp when a stream is created, updated, or deleted.
Real-Time Balance: The change in the account's Super Token balance since the last CRUD action.
Static Balance: The Super Token balance at the last CRUD timestamp.
Current Balance: The sum of Static Balance and Streaming Real-Time Balance.
info
NOTE: Flow rates are per second but can be represented in different time units for convenience. For example, "100 USDCx/mo." is approximately "0.0039 USDCx/sec."
Computation
The netflow for an account is calculated by netting its inbound and outbound streaming flow rates.
Example of Net Flow calculation
When a stream is modified, the following are updated in the Superfluid contracts:
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.
Formula
Static Balance: Initial balance at the latest CRUD timestamp
Real-Time Balance: Netflow Rate * Seconds since the latest CRUD timestamp
Current Balance: Static Balance + Real-Time Balance
Example - Monitoring Account A's Current Balance
Let's examine how Account A's balance changes with stream interactions.
1. Starting an Outbound Stream
Outbound Stream
Initial Balance: 1000 USDCx
Flow Rate to Account B: 0.01 USDCx/sec
Time Elapsed: 1000 seconds
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
Other Considerations
Discrete Actions and Active Streams
Transferring, wrapping, or unwrapping Super Tokens, being lump-sum actions, only affect the Static Balance and not the Real-Time Balance.
Interaction with Distributions
Actions within Distributions have their own Real-Time Balance and are added separately to the overall account balance.
Solvency and Sentinels
Accounts with negative net flow rates reaching zero balance are considered critical. Superfluid handles this with buffer deposits and Sentinels.
Buffer
Buffer deposits are taken when opening a stream, serving as a reserve in case of a critical balance. If a stream is closed before hitting critical, the buffer is refunded. In cases where the account becomes critical, the buffer is used to continue outbound streams until Sentinels intervene.
Sentinels
Sentinels are external actors who monitor Constant Flow Agreements (Money Streaming), close streams of critical accounts, and earn buffer deposits.
For more details, see the Liquidations and Sentinels pages.
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
Pure Super Tokens are natively Tagomi-enabled without an underlying token. They offer inherent ERC20 functionalities plus Tagomi's Super Agreement capabilities.
Click as quickly as possible on the Pure Super Token to create your first stream!Pure Super Token
A Pure Super Token has inherent superpowers such as Money Streaming and Distributions
Real-Time Balance
Super Tokens track an account's balance dynamically, factoring in both regular transfers and impacts from Money Streaming and Distributions.
Static Balance: The standard BEP20 balance affected by lump-sum transfers.
Real-Time Balances: The ongoing impact of each Super Agreement on an account's balance, which can be positive or negative.
The actual current balance is a sum of these components.
Current Balance Formula: Current Balance = Real-Time Balances + Static Balance
Example Calculation
Account A's Static Balance: 1,000 USDCx
Account A's Stream Out: -100 USDCx
Account A's Instant Distribution Receipts: +200 USDCx
Current Balance: 1000 - 100 + 200 = 1100 USDCx
About Super Tokens balanceOf()
If you are familiar with the BEP20 standard, you are certainly familiar with balanceOf(). A Super Token balanceOf() function reflects this dynamic balance, unlike a regular BEP20's static approach.
Introduction to the Mini Game of the Crypto Tagomi Project
Welcome to the mini game of the Crypto Tagomi project – a unique entertainment experience that combines blockchain technology with gaming! Specifically designed to provide fun and excitement, this mini game not only helps players relax but also offers opportunities to earn rewards and learn about the crypto world.
1. Introduction to Tagomi
Crypto Tagomi is an innovative blockchain platform aimed at optimizing trading and managing digital assets. With the mission to provide users with the best tools and experiences, we have developed an engaging mini game to create interaction and connection within the crypto community.
2. Mini Game Content
The Tagomi mini game is an exciting strategy game where players take on the role of savvy traders in the volatile crypto market. Players must make smart decisions and strategies to optimize their profits, thereby enhancing their trading skills.
How to Play:
Players will receive a certain amount of tokens to start trading.
Participate in virtual trading sessions where the values of cryptocurrencies change in real time.
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!
NFT
Introduction to the NFTs of the Crypto Tagomi Project
Welcome to the world of NFTs from the Crypto Tagomi project! We are proud to introduce a unique and valuable collection of NFTs, specially designed for RPG (Role-Playing Game) enthusiasts. With a perfect combination of art, blockchain technology, and gaming experience, Tagomi's NFTs are not just digital assets but valuable rewards in the journey of exploring the virtual world.
1. The Value of Tagomi NFTs
Staking
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.
Pre-sale IDO
Tagomi Project Announces Pre-sale IDO for TGM Token!
Tagomi is excited to announce the upcoming Pre-sale IDO for our $TGM token, giving our valued partners, loyal customers, and supportive community an exclusive opportunity to purchase $TGM at an early stage. As part of this special event, we are allocating 8% of the total supply of 300,000,000 $TGM tokens, equivalent to 24,000,000 $TGM.
This Pre-sale IDO is a chance to become an early tor in the project and acquire tokens at a limited, discounted rate. Act fast, as token availability is limited, and the demand is high!
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!
1. Pre-sale IDO Overview
The Pre-sale IDO (Initial DEX Offering) is an exclusive event that allows early access to $TGM tokens before they are fully listed on the public market. This is a golden opportunity for early supporters to own $TGM tokens and enjoy the long-term potential of the Tagomi project.
We are thrilled to reward our community and partners with this Pre-sale phase, as they have been instrumental in helping us build and shape Tagomi from the very beginning.
2. How to Purchase $TGM Tokens
To participate in the Pre-sale IDO and purchase $TGM tokens, please follow these steps on the official Tagomi website:
Visit the Official Tagomi Website:
Go to https://tagomi.tech/, 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.
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.
3. Why Participate in the Pre-sale IDO?
Exclusive Access: Get $TGM tokens before they are available to the public.
Discounted Pricing: Early participants can buy tokens at a special pre-sale price, which may increase when $TGM is listed on exchanges.
Limited Supply: Only 8% of the total token supply is available for the Pre-sale IDO, so don’t miss your chance to secure your share.
Support the Project: By participating in this early phase, you are directly contributing to the growth and development of Tagomi and its ecosystem.
4. Join the Tagomi Movement
The Pre-sale IDO for $TGM is a significant milestone for the Tagomi project, and we want you to be a part of it! As we continue to innovate and grow, holding $TGM tokens will give you access to various future benefits within the Tagomi ecosystem, from governance to exclusive features.
Visit the official website now: https://tagomi.tech/ and secure your $TGM tokens before they run out. Thank you for your continued trust and support!
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
Compete against other players to see who can achieve the highest profit within a limited time.
Key Features:
Attractive Rewards: Players with the best performances will receive rewards in project tokens, which can be used in other activities on the Tagomi platform.
Ranking System: Players can track their achievements through a leaderboard and receive additional rewards for those who rank at the top.
Learning from Failures: The game not only entertains but also provides valuable lessons about trading and asset management.
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.
Staking Pool Details and Benefits:
Pool 1 - 1000 to 40,000 TGM:
APR: 20%
Benefit: Users staking between 1000 to 40,000 TGM tokens will receive an APR of 20%, meaning they will earn a 20% annualized return on their staked TGM tokens.
Pool 2 - > 40,000 to 120,000 TGM:
APR: 40%
Benefit: Users staking between > 40,000 to 120,000 TGM tokens will receive an APR of approximately 40%, offering a higher annualized return compared to Pool 1.
Pool 3 - > 120,000 to 400,000 TGM:
APR: 80%
Benefit: Users staking between > 120,000 to 400,000 TGM tokens will receive an APR of approximately 80%, offering the highest annualized return and significant rewards for staking a larger amount of TGM tokens.
Overall Benefits of Staking:
Passive Income: Staking TGM tokens allows users to earn passive income through staking rewards without actively trading or participating in the market.
Higher Returns: By staking larger amounts of TGM tokens, users can benefit from higher APRs, leading to potentially higher returns on their investment.
Community Participation: Staking also contributes to the stability and security of the Tagomi network by incentivizing token holders to actively participate in securing the network.
By following these steps and understanding the benefits, users can effectively stake their TGM tokens and earn rewards while contributing to the Tagomi ecosystem.
Social & Community
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.
Concept
Long-Term Engagement: This model rewards ongoing loyalty and engagement, as opposed to immediate lump-sum airdrops.
Example: Consider the scenario where the longer an individual holds a community NFT, the more social tokens they accrue, discouraging immediate selling post-airdrop.
Explore this concept with the Reverb project, a platform that streams social tokens based on music listening habits.
Perpetual Conditional Rewards (PCR)
The PCR model within the Tagomi Protocol offers a scalable way to incentivize community actions based on specific Key Performance Indicators (KPIs).
Mechanism
Reward Distribution: Rewards are streamed to participants based on progress towards a KPI metric.
Funding and Execution: Funded through money streams and distributed using the Tagomi Instant Distribution Agreement, with KPI verification via UMA's KPI Options.
Perpetual Conditional Rewards
Use Cases
Community Incentives: Communities can incentivize members for activities like increasing Twitter followers or GitHub repo stars.
Scalable Incentives: This system provides a method to reward members proportionally for contributing to communal goals.
For a deeper dive into the PCR concept, refer to this Twitter thread by UMAprotocol.
Tagomi's approach to social tokens and community incentives represents a shift towards more dynamic and engagement-focused reward systems in the digital space.
Trading on Tagomi App
Introduction to the Trading Feature on the Tagomi App
Welcome to the trading feature on the Tagomi app – a powerful tool designed to help you optimize your trading of digital assets. By utilizing the latest market analysis and price trend technologies, Tagomi not only provides users with a smooth trading experience but also offers essential insights for making informed decisions.
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!
Tokenomics
TOKENOMIC:
Ticker: TGM
Token type: BEP-20
IDO Token Price: 3,000 TGM = 1 BNB
Total Tokens: 300,000,000
Smart Contract:
TOKEN DISTRIBUTION:
Advisors – 6%
Liquidity (DEX & CEX) – 10%
Liquidity mining – 5%
Ecosystem – 12%
FUNDS ALLOCATION:
Operational – 16.7%
General costs – 8.3%
Initial liquidity – 15%
Marketing – 10%
Glossary of Terms
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 Tokens
Super Token: Tokens used in all Tagomi operations. Types include BEP20 Wrapper Tokens, Pure Super Tokens, and Native Asset Super Tokens. Detailed information is available in our Super Tokens section.
Wrap: The process of converting BEP20 tokens into wrapped super tokens. This involves transferring BEP20 assets into the wrapper contract and receiving an equivalent amount of super tokens.
Unwrap: Converting wrapped super tokens back into their underlying BEP20 assets. This involves burning super tokens and transferring the underlying asset to the user.
Real Time Balance: A dynamic calculation of an account's balance, considering both Tagomi agreement logic and static token balances.
Agreements
Tagomi Agreement: Additional functionalities for Super Tokens provided by the Tagomi protocol. Examples include the Constant Flow Agreement and the Instant Distribution Agreement, with potential for more in the future.
Constant Flow Agreement (CFA): An agreement allowing perpetual, second-by-second movement of Super Tokens between addresses.
Instant Distribution Agreement (IDA): An agreement for mass dispersion of Super Tokens to multiple addresses based on distribution shares or "units" at a fixed gas cost.
Flow: A continuous money stream from one address to another. A sender can maintain only one flow to the same receiver per token.
Flow Rate: The amount of tokens sent in a stream, denominated in wei per second.
Net Flow Rate: The net amount of tokens sent or received per second by an account for a specific token.
ACL (Access Control List): A feature enabling varying levels of control to operators for creating, updating, or deleting streams on behalf of an account.
Index: A pool created using the Instant Distribution Agreement.
Publisher: The creator of an Index.
Units: Shares denoting an address’s share of an IDA index, interchangeable with "distribution shares".
Distribution: The action of sending tokens to addresses owning shares in an index, proportionate to the number of shares held.
Protocol
Callback: A function that automatically executes when specific actions are taken. Super Apps use callbacks to respond to Tagomi-related actions.
User Data: Data that can be included with Tagomi function calls and utilized within Super App callbacks.
Batch Calls: A Super Token feature allowing multiple actions to be executed in a single transaction.
The Tagomi Host: The core of the protocol, processing function calls and facilitating protocol governance and Super App callbacks.
Resolver: A contract assisting in locating all protocol constituent contract addresses.
Sentinels & Solvency
Buffer: Tokens locked temporarily when a stream starts.
Liquidation: The process initiated by a sentinel when an account's balance reaches zero while streaming funds.
Sentinel: A node monitoring the Tagomi network and closing critical or insolvent streams. Anyone can run a sentinel node.
PIC (Patrician in Charge): The recipient of rewards for closing streams during the priority period when an account becomes critical.
TOGA (Transparent Ongoing Auction): An auction allowing individuals to become the PIC by staking a higher amount than the current PIC.
Stake: Funds locked in the TOGA contract by the PIC.
Top Up: Adding to a Super Token balance to prevent liquidation due to a zero balance.
Token-Cost-Averaging
Token-Cost-Averaging* (TCA) is one possible application designed to leverage the power of Tagomi streams. This application could allow the user to swap tokens in continuous real-time streams: stream in your Sell token and receive back the Buy token periodically.
What is Token-Cost-Averaging (TCA)?
Token-Cost-Averaging (TCA) is an investment strategy where an investor divides up the total amount to be invested across periodic purchases of a target asset (just like Dollar-Cost-Averaging but it's asset agnostic). This strategy gives users the best results over time by swapping tokens in continuous real-time streams: stream in your Sell token and receive back the Buy token periodically.
Airdrop
Tagomi ($TGM) Airdrop Announcement
The Tagomi project is officially launching an exciting Airdrop program for the community with attractive rewards! To show our appreciation for the support, we are allocating 3% of the total supply of 300,000,000 $TGM, equivalent to 9,000,000 $TGM, as rewards for this Airdrop event.
1. Overview of the $TGM Airdrop
The Airdrop is a fantastic opportunity for users to participate and earn free $TGM tokens from the Tagomi project. Through this event, we aim to strengthen and grow our community.
Tagomi Host
The Tagomi Host Contract is a central element of the Tagomi Protocol, acting as a hub connecting Super Tokens, Super Agreements, and Super Apps
Tagomi Host Contract
Let's explore how the Host Contract interacts with different components of the Tagomi Protocol.
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.
To join the Airdrop program, simply follow these steps:
Follow Tagomi's Official X Account: Make sure you're following us on X to stay updated on all important news.
Join the Official Telegram Community: Join our official Telegram group to stay in the loop about updates and events.
Complete the Required Tasks: Airdrop tasks may include sharing project information, inviting friends to join, and interacting with Tagomi’s posts on social media platforms.
Earn Points for Completing Tasks: Each completed task will earn participants points, and these points will later be converted into $TGM tokens based on the total number of points earned. The more tasks completed, the more points (and thus tokens) you can earn!
Fill Out the Airdrop Participation Form: Once you've completed the above steps, submit your information through the registration form so we can contact you and verify your eligibility.
3. Airdrop Reward Rules and Guidelines
Honesty: We ask all participants to be honest while participating in the Airdrop. Any form of cheating or creating fake accounts to gain an unfair advantage will result in disqualification.
Point-to-Token Conversion: Points accumulated during the Airdrop will be converted into $TGM tokens. These tokens will be distributed once the project launches its IDO (Initial DEX Offering) for $TGM. The more points you earn, the more $TGM tokens you'll receive!
Reward Announcement: The list of Airdrop reward recipients will be publicly announced on Tagomi’s official X account. Stay tuned so you don’t miss out!
Reward Distribution Timeline: $TGM rewards will be sent to participants' wallets after the event concludes and the winners are announced. Please be patient as we ensure prompt reward distribution.
Eligibility and Fairness: Everyone who participates has a chance to win, based on the number of tasks completed and the validity of the information provided.
4. Conclusion
Tagomi hopes that this Airdrop event will help the community grow and become stronger. It’s a great opportunity to earn valuable rewards and be a crucial part of the $TGM project. Complete tasks, earn points, and convert them into tokens when we launch our IDO!
Follow our X account and join the community channels for more details about this event. Thank you for your support, and get ready to join the Airdrop today!
Price Prediction: Utilizing AI and machine learning technology, Tagomi offers predictions on future price movements. Predictive models are trained on historical data and current indicators, providing users with deeper insights into market trends.
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.
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 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
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.
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!
Metaverse
Introduction to the Metaverse of the Crypto Tagomi Project
Welcome to the Metaverse of the Crypto Tagomi project! We are excited to introduce a creative virtual space where users can interact, explore, and engage in various exciting activities within the blockchain world. Tagomi's Metaverse is not just a game or a social platform; it is a rich ecosystem that connects people through advanced technology.
1. Concept of Tagomi Metaverse
The Tagomi Metaverse is an interactive 3D space where users can create personal avatars and participate in diverse activities. Here, you can explore different areas, engage in role-playing games, socialize with the community, and even take part in virtual events. We aim to create an immersive and enriching experience, allowing users to fully enjoy the crypto world.
2. Key Features of Tagomi Metaverse
Social Interaction: Meet and connect with other crypto enthusiasts from around the world. Share ideas, strategies, and participate in lively discussions within the community.
Games and Activities: Join engaging games and other entertainment activities where you can earn rewards and enhance your skills.
NFT Marketplace: Explore and trade unique NFTs within the Metaverse, from characters and items to virtual real estate. This is an opportunity for you to invest and grow your assets in the virtual space.
3. Benefits of Participating in Tagomi Metaverse
Rich Experience: The Tagomi Metaverse offers a diverse and enriching experience where you can discover new and exciting things.
Connection Opportunities: Joining the Metaverse allows you to connect with a global crypto community, expanding your network and seeking collaboration opportunities.
Earning Potential: Through activities in the Metaverse, users can earn money from games, NFT trading, and participating in special events.
4. Conclusion
The Metaverse of the Crypto Tagomi project is a unique virtual space that combines blockchain technology with entertainment experiences. We invite you to join us on a journey of exploration, interaction, and development in a vibrant and captivating virtual world. Let’s build the Tagomi community together and experience the wonderful things that the Metaverse has to offer!
GDAv1Forwarder
The GDAv1Forwarder contract is a Tagomi forwarder that implements the General Distribution Agreement (GDA) related functions. It is a contract specifically made immutable in order to facilitate the interaction with Distributions through the General Distribution Agreement (GDA).
This contract is optimized for interaction that would happen from outside the blockchain (off-chain). For more information on the best practices regarding this interaction, please refer to the SDK Section section of this documentation.
The GDAv1Forwarder contract address is the same on all Tagomi chains:
ABI
In order to interact with the GDAv1Forwarder contract, you can use the following ABI:
Click here to show GDAv1Forwarder ABI
_gda
Fn constructor
Parameters
Name
Type
Description
Fn createPool
createPool() write
Try it out
Creates a new Tagomi Pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn updateMemberUnits
updateMemberUnits() write
Try it out
Updates the units of a pool member.
Parameters
Name
Type
Description
Fn claimAll
claimAll() write
Try it out
Claims all tokens from the pool.
Parameters
Name
Type
Description
Fn connectPool
connectPool() write
Try it out
Connects a pool member to pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn disconnectPool
disconnectPool() write
Try it out
Disconnects a pool member from pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn distribute
distribute() write
Try it out
Tries to distribute requestedAmount amount of token from from to pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn distributeFlow
distributeFlow() write
Try it out
Tries to distribute flow at requestedFlowRate of token from from to pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn isPool
isPool() read
Try it out
Checks if the specified account is a pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn getNetFlow
getNetFlow() read
Try it out
Gets the GDA net flow rate for the specified account.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn getFlowDistributionFlowRate
getFlowDistributionFlowRate() read
Try it out
Gets the flow rate of tokens between the specified accounts.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn getPoolAdjustmentFlowRate
getPoolAdjustmentFlowRate() read
Try it out
Gets the pool adjustment flow rate for the specified pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn estimateFlowDistributionActualFlowRate
estimateFlowDistributionActualFlowRate() read
Try it out
Estimates the actual flow rate for flow distribution to the specified pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn estimateDistributionActualAmount
estimateDistributionActualAmount() read
Try it out
Estimates the actual amount for distribution to the specified pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn isMemberConnected
isMemberConnected() read
Try it out
Checks if the specified member is connected to the pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Fn getPoolAdjustmentFlowInfo
getPoolAdjustmentFlowInfo() read
Try it out
Gets the pool adjustment flow information for the specified pool.
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Super Apps
Super Apps represents a class of smart contracts that interact seamlessly with the Tagomi Protocol, enabling dynamic responses to Money streaming or Distributions (Also called Super Agreements).
Super Apps are smart contracts registered with the Tagomi Protocol, designed to react to Super Agreements. These reactions are facilitated through callbacks, allowing Super Apps to engage dynamically with the creation, modification, and termination of Super Agreements.
Reacting to Super Agreements
The reactivity of Super Apps stems from callbacks. These are segments of code within the Super App that are triggered when a Super Agreement involving the Super App is created, updated, or deleted. Such callbacks can execute various actions, from minting NFTs to initiating new Streams (Constant Flow Agreements).
Example - Stream Consolidator Super App
Consider a Super App designed to consolidate all incoming flows into a single outgoing flow to a specific account (Account Z):
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.
Registering With The Protocol
Registration of a Super App with the Tagomi Protocol is crucial. This registration process involves coding the smart contract to be identifiable as a Super App within the protocol.
Purpose of Registration
Protocol Recognition: When a stream is initiated towards a contract, the Tagomi Protocol checks if the recipient is a registered Super App.
Callback Activation: If identified as a Super App, the protocol activates the Super App's callbacks, enabling its reactive capabilities.
Super App Registration
Why Are Super Apps Needed?
Super Apps introduce a layer of programmability to Super Agreements, enhancing the potential for innovative decentralized applications (dApps).
Potential Use Cases
Lending Applications: Automate loan repayments through Streams, eliminating the need for manual transactions.
Subscription Services: Enable on-chain subscriptions paid via Streams, incorporating features like automatic affiliate payouts.
Super Apps open up a realm of possibilities, combining custom logic with the functionalities of Super Agreements to craft unique and scalable dApps.
For further inspiration, explore the following examples of Super Apps:
Explore Super App Examples
ITagomiPool
This is the technical reference related to the interface for any super token pool regardless of the distribution schemes.
A boolean indicating whether pool members can transfer their units
Fn distributionFromAnyAddress
A boolean indicating whether addresses other than the pool admin can distribute via the pool
Fn admin
The admin is the creator of the pool and has permissions to update member units and is the recipient of the adjustment flow rate
The pool admin
Fn superToken
The SuperToken for the pool
Fn getTotalUnits
The total units of the pool
Fn getTotalConnectedUnits
The total number of units of connected members
Fn getTotalDisconnectedUnits
The total number of units of disconnected members
Fn getUnits
Parameters
Name
Type
Description
The total number of units for memberAddress
Fn getTotalFlowRate
The total flow rate of the pool
Fn getTotalConnectedFlowRate
The flow rate of the connected members
Fn getTotalDisconnectedFlowRate
The flow rate of the disconnected members
Fn getDisconnectedBalance
Parameters
Name
Type
Description
The balance of all the disconnected members at time
Fn getMemberFlowRate
Parameters
Name
Type
Description
The flow rate a member is receiving from the pool
Fn getClaimable
Parameters
Name
Type
Description
The claimable balance for memberAddr at time in the pool
Fn getClaimableNow
Parameters
Name
Type
Description
The claimable balance for memberAddr at block.timestamp in the pool
Fn updateMemberUnits
Parameters
Name
Type
Description
Sets memberAddr ownedUnits to newUnits
Fn claimAll
Parameters
Name
Type
Description
Claims the claimable balance for memberAddr at block.timestamp
Fn claimAll
Claims the claimable balance for msg.sender at block.timestamp
Fn increaseAllowance
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Increases the allowance of spender by addedValue
Fn decreaseAllowance
Parameters
Name
Type
Description
Return Values
Name
Type
Description
Decreases the allowance of spender by subtractedValue
CFAv1Forwarder
The CFAv1Forwarder contract is a Tagomi forwarder that implements the Constant Flow Agreement (CFA) related functions. It is a contract specifically made immutable in order to facilitate the interaction with Money Streaming through the Constant Flow Agreement (CFA).
This contract is optimized for interaction that would happen from your client application. For more information on the best practices regarding this interaction, please refer to the Create, Update and Delete Flows or Manage Access Control and User Data.
Contract Address
The CFAv1Forwarder
SuperTokenV1Library
Library for Token Centric Interface
The SuperTokenV1Library is a solidity library that allows you to interact with the Tagomi Protocol. It is a comprehensive library for Tagomi protocol. It includes all the functions that are required to interact with the Tagomi protocol. It includes functions for interacting with Money Streaming and Distributions. In order to have access to the library, you need to:
This is the technical reference related to the interface for Super Tokens.
Implementation addresses
Super Token deployments work in a proxy pattern with the original implementation being comon between all super tokens for each chain. The implementation address for the SuperToken is different for each network and can be found in the SuperTokenFactory at the method getSuperTokenLogic.
To get the addresses of all the SuperTokenFactory contracts, you can use the Tagomi Explorer, section Protocol.
ISETH
ISETH is the interface for native Super Tokens.
ABI
In order to interact with any contract satistying the ISETH interface, you can use the following ABI:
Click here to show
Protocol Architecture
The Tagomi Protocol is designed with a modular and upgradable architecture, consisting of several smart contract components that interact with each other to facilitate real-time finance on the blockchain.
Overview
The architecture diagram below provides a high-level overview of the Tagomi Protocol's components and their relationships. It is the protocol deployed when a new TagomiFrameworkDeployer instance is created and the method deployFramework().
Decentralized Exchange (DEX) Support: Tagomi integrates with DEX platforms like Uniswap and PancakeSwap, allowing users to execute trades directly without intermediaries.
High Security: With advanced security measures such as data encryption and multi-factor authentication, Tagomi is committed to protecting users' assets and information safely.
Integrated Wallet: The app comes with an integrated wallet that allows users to easily and conveniently manage various types of digital assets.
struct PoolConfig
The pool configuration (see PoolConfig in IGeneralDistributionAgreementV1.sol)
uint128
The new units of the member.
userData
bytes
User-specific data.
bytes
User-specific data.
contract ITagomiPool
The Tagomi Pool address.
requestedAmount
uint256
The amount of tokens to distribute.
userData
bytes
User-specific data.
contract ITagomiPool
The Tagomi Pool address.
requestedFlowRate
int96
The flow rate of tokens to distribute.
userData
bytes
User-specific data.
contract ITagomiPool
The receiver address (the pool address).
contract ITagomiPool
The pool address.
requestedFlowRate
int96
The requested flow rate.
contract ITagomiPool
The pool address.
requestedAmount
uint256
The requested amount.
int96
host
contract ITagomi
token
contract ITagomiToken
The Super Token address.
admin
address
The pool admin address.
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.
pool
contract ITagomiPool
The Tagomi Pool to claim from.
memberAddress
address
The address of the member to claim for.
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.
[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.
[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.
[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.
actualFlowRate
int96
totalDistributionFlowRate
int96
token
contract ITagomiToken
The Super Token address.
from
address
The sender address.
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.
function updateMemberUnits(
  address pool,
  address memberAddress,
  uint128 newUnits,
  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 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)
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.
The buffer amount required for the given configuration.
Get the buffer amount required for the given token and flowrate. This amount can vary based on the combination of token, flowrate and chain being queried. The result for a given set of parameters can change over time, because it depends on governance configurable protocol parameters. Changes of the required buffer amount affect only flows created or updated after the change.
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.
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.
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.
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.
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.
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.
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.
Updates an index value with userData. This distributes an amount of tokens equal to indexValue - lastIndexValue. See distribute for another way to distribute.
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.
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.
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.
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.
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
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.
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.
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
_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.
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.
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
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.
_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._
_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.
_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._
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.
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.
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.
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.
0xcfA132E353cB4E398080B9700609bb008eceB125
error CFA_FWD_INVALID_FLOW_RATE()
contract IConstantFlowAgreementV1 _cfa
function constructor(
contract ITagomi host
)
public
function getFlowInfo(address token, address sender, address receiver) view returns (
  uint256 lastUpdated,
  int96 flowrate,
  uint256 deposit,
  uint256 owedDeposit
)
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 updateFlowOperatorPermissions(
  address token,
  address flowOperator,
  uint8 permissions,
  int96 flowrateAllowance
) nonpayable returns (bool)
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)
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.
flowrate
int96
The wanted flowrate in wad/second. Only positive values are valid here.
receiver
address
The receiver of the flow
flowrate
int96
The wanted flowrate in wad/second. Only positive values are valid here.
receiver
address
The receiver of the flow
receiver
address
The receiver of the flow
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
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
receiver
address
Receiver address of the flow
flowrate
int96
The flowrate in wad/second to be set initially
userData
bytes
(optional) User data to be set. Should be set to zero if not needed.
receiver
address
Receiver address of the flow
flowrate
int96
The flowrate in wad/second the flow should be updated to
userData
bytes
(optional) User data to be set. Should be set to zero if not needed.
receiver
address
Receiver address of the flow
userData
bytes
(optional) User data to be set. Should be set to zero if not needed.
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.
flowOperator
address
Account to which (possibly) permissions were granted
receiver
address
flowrate
int96
receiver
address
flowrate
int96
userData
bytes
receiver
address
flowrate
int96
userData
bytes
receiver
address
userData
bytes
permissions
uint8
flowrateAllowance
int96
flowRate
int96
The desired flowRate
flowRate
int96
The desired flowRate
userData
bytes
The userdata passed along with call
flowRate
int96
The desired flowRate
flowRate
int96
The desired flowRate
userData
bytes
The userdata passed along with call
receiver
address
The receiver of the flow
receiver
address
The receiver of the flow
userData
bytes
The userdata passed along with call
allowCreate
bool
creation permissions
allowUpdate
bool
allowDelete
bool
flowRateAllowance
int96
The allowance provided to flowOperator
addedFlowRateAllowance
int96
amount to increase allowance by
addedFlowRateAllowance
int96
amount to increase allowance by
userData
bytes
The userdata passed along with call
subtractedFlowRateAllowance
int96
amount to decrease allowance by
subtractedFlowRateAllowance
int96
amount to decrease allowance by
userData
bytes
The userdata passed along with call
permissionsToAdd
uint8
The permissions to add for the flow operator
addedFlowRateAllowance
int96
amount to increase allowance by
permissionsToAdd
uint8
The permissions to add for the flow operator
addedFlowRateAllowance
int96
amount to increase allowance by
userData
bytes
The userdata passed along with call
permissionsToRemove
uint8
The permissions to remove for the flow operator
subtractedFlowRateAllowance
int96
amount to subtract allowance by
permissionsToRemove
uint8
The permissions to remove for the flow operator
subtractedFlowRateAllowance
int96
amount to subtract allowance by
userData
bytes
The userdata passed along with call
allowCreate
bool
creation permissions
allowUpdate
bool
allowDelete
bool
flowRateAllowance
int96
The allowance provided to flowOperator
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
receiver
address
The receiver of the flow
flowRate
int96
The desired flowRate
receiver
address
The receiver of the flow
flowRate
int96
The desired flowRate
userData
bytes
The user provided data
receiver
address
The receiver of the flow
flowRate
int96
The desired flowRate
receiver
address
The receiver of the flow
flowRate
int96
The desired flowRate
userData
bytes
The user provided data
receiver
address
The receiver of the flow
receiver
address
The receiver of the flow
userData
bytes
The user provided data
flowRate
int96
The desired flowRate
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
receiver
address
The receiver of the flow
flowRate
int96
The desired flowRate
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
flowRate
int96
The desired flowRate
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
receiver
address
The receiver of the flow
flowRate
int96
The desired flowRate
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
receiver
address
The receiver of the flow
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
receiver
address
The receiver of the flow
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
receiver
address
The receiver of the flow
receiver
address
The receiver of the flow
deposit
uint256
The amount of deposit the flow
owedDeposit
uint256
The amount of owed deposit of the flow
deposit
uint256
The sum of all deposits for account's flows
owedDeposit
uint256
The sum of all owed deposits for account's flows
flowOperator
address
the address we are checking permissions of for sender & token
allowDelete
bool
is true if the flowOperator can delete flows
flowRateAllowance
int96
The flow rate allowance the flowOperator is granted (only goes down)
indexId
uint32
ID of the index.
totalUnitsApproved
uint128
Units of the index approved by subscribers.
totalUnitsPending
uint128
Units of teh index not yet approved by subscribers.
indexId
uint32
ID of the index.
amount
uint256
Amount of tokens desired to distribute.
unitsList
uint128[]
Units owned of the indices.
indexId
uint32
ID of the index.
subscriber
address
Subscriber to the index.
units
uint128
Units held by the subscriber
pendingDistribution
uint256
If not approved, the amount to be claimed on approval.
to
contract ITagomiPool
to
contract ITagomiPool
requestedFlowRate
int96
to
contract ITagomiPool
requestedAmount
uint256
member
address
userData
bytes
Arbitrary user data field.
indexValue
uint128
New TOTAL index value, this will equal the total amount distributed.
indexValue
uint128
New TOTAL index value, this will equal the total amount distributed.
userData
bytes
Arbitrary user data field.
amount
uint256
- total number of tokens desired to be distributed
NOTE in many cases, there can be some precision loss
This may cause a slight difference in the amount param specified and the actual amount distributed.
See below for math:
//indexDelta = amount the index will be updated by during an internal call to _updateIndex().
It is calculated like so:
indexDelta = amount / totalUnits
(see the distribute() implementatation in ./agreements/InstantDistributionAgreement.sol)
NOTE Solidity does not support floating point numbers
So the indexDelta will be rounded down to the nearest integer.
This will create a 'remainder' amount of tokens that will not be distributed
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
//
amount
uint256
Amount by which the index value should increase.
userData
bytes
Arbitrary user data field.
indexId
uint32
ID of the index.
indexId
uint32
ID of the index.
userData
bytes
Arbitrary user data field.
indexId
uint32
ID of the index.
indexId
uint32
ID of the index.
userData
bytes
Arbitrary user data field.
subscriber
address
Subscriber address whose units are to be updated.
units
uint128
New number of units the subscriber holds.
subscriber
address
Subscriber address whose units are to be updated.
units
uint128
New number of units the subscriber holds.
userData
bytes
Arbitrary user data field.
indexId
uint32
ID of the index.
subscriber
address
Subscriber address whose units are to be deleted.
indexId
uint32
ID of the index.
subscriber
address
Subscriber address whose units are to be deleted.
userData
bytes
Arbitrary user data field.
indexId
uint32
ID of the index.
subscriber
address
Subscriber address that receives the claim.
indexId
uint32
ID of the index.
subscriber
address
Subscriber address that receives the claim.
userData
bytes
Arbitrary user data field.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
indexValue
uint128
New TOTAL index value, this will equal the total amount distributed.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
amount
uint256
Amount by which the index value should increase.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
indexId
uint32
ID of the index.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
indexId
uint32
ID of the index.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
subscriber
address
Subscriber address whose units are to be updated.
units
uint128
New number of units the subscriber holds.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
indexId
uint32
ID of the index.
subscriber
address
Subscriber address whose units are to be deleted.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
indexId
uint32
ID of the index.
subscriber
address
Subscriber address that receives the claim.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
poolConfig
struct PoolConfig
The pool configuration (see below)
memberAddress
address
The address of the member to update.
newUnits
uint128
The new units of the member.
memberAddress
address
The address of the member to update.
newUnits
uint128
The new units of the member.
userData
bytes
User-specific data.
memberAddress
address
The address of the member to claim for.
memberAddress
address
The address of the member to claim for.
userData
bytes
User-specific data.
userData
bytes
User-specific data.
userData
bytes
User-specific data.
pool
contract ITagomiPool
The Tagomi Pool address.
requestedAmount
uint256
The amount of tokens to distribute.
pool
contract ITagomiPool
The Tagomi Pool address.
requestedAmount
uint256
The amount of tokens to distribute.
userData
bytes
User-specific data.
pool
contract ITagomiPool
The Tagomi Pool address.
requestedFlowRate
int96
The flow rate of tokens to distribute.
pool
contract ITagomiPool
The Tagomi Pool address.
requestedFlowRate
int96
The flow rate of tokens to distribute.
userData
bytes
User-specific data.
memberAddress
address
The address of the member to update.
newUnits
uint128
The new units of the member.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
memberAddress
address
The address of the member to claim for.
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)
pool
contract ITagomiPool
The Tagomi Pool address.
requestedAmount
uint256
The amount of tokens to distribute.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
pool
contract ITagomiPool
The Tagomi Pool address.
requestedFlowRate
int96
The flow rate of tokens to distribute.
ctx
bytes
Context bytes (see ITagomi.sol for Context struct)
n
string
s
string
n
string
s
string
admin
address
amount
uint256
userData
bytes
amount
uint256
userData
bytes
operatorData
bytes
userData
bytes
operatorData
bytes
userData
bytes
userData
bytes
recipient
address
amount
uint256
amount
uint256
userData
bytes
User data for the TokensRecipient callback
amount
uint256
Number of tokens to be approved.
addedValue
uint256
subtractedValue
uint256
recipient
address
The recipient of the funds.
amount
uint256
Number of tokens to be transferred.
amount
uint256
Number of tokens to be transferred.
userData
bytes
Arbitrary user inputted data
Bug Bounty
Program Overview
This bug bounty is specifically for Tagomi's smart contract code; client / UI only bugs are omitted.
Tagomi's smart contract is open-source(opens in a new tab).
Severity
The severity guidelines are based on .
Note that these are simply guidelines for the severity of the bugs. Each bug bounty submission will be evaluated on a case-by-case basis.
Submission
Please email with a detailed description of the attack vector. For critical and moderate bugs, we require a proof of concept done on a privately deployed mainnet contract. We will reach back out in 1 business day with additional questions or the next steps on the bug bounty.
Bug Bounty Payment
Bug bounties will be paid in USDC. Alternative payment methods can be used on a case-by-case basis.
Invalid Bug Bounties
The following are out of scope for the bug bounty:
Attacks that the reporter has already exploited themselves, leading to damage
Attacks requiring access to leaked keys/credentials
Attacks requiring access to privileged addresses (governance, admin)
Road map
Explore Tagomi ambitious roadmap and significant milestones
February 2018
Successfully raised $28 million from angel investment funds
Community Building Plan for 2019
Developers
Audits
Trail of Bits
Overview
Tagomi Protocol engaged Trail of Bits (TOB) to audit the security of its decentralized exchange and smart contract. Founded in 2012 and headquartered in New York, TOB provides technical security assessment and advisory services and specializes in software testing and code review projects. TOB is recognized as a Tier-1 security auditor, having worked with notable clients such as Google and Microsoft.
From February 7 to June 2, 2023, the TOB tam conducted a security audit of Tagomi Protocol’s. TOB’s testing efforts were focused on the identification of flaws that could result in a compromise of confidentiality, integrity, or availability of Tagomi’s decentralized exchange and smart contract. The audit was conducted by TOB with full knowledge of the target system, including access to the source code and documentation. TOB utilized a mix of static and dynamic testing of the target system and its codebase, using both automated and manual processes.
Incorrect data supplied by third-party oracles (This does not exclude oracle manipulation/flash loan attacks)
Lack of liquidity
Third-party, off-chain bot errors (for instance bugs with an arbitrage bot running on the smart contracts)
Best practice critiques
Sybil attacks
Attempted phishing or other social engineering attacks involving Tagomi contributors or users
Denial of service, or automated testing of services that generate significant traffic.
Any submission violating Immunefi's rules
Description
Bug Bounty
Critical
Bugs that freeze user funds or drain the contract's holdings or involve the theft of funds without user signatures.
10% of the value of the hack up to $500,000.
High
Bugs that could temporarily freeze user funds or incorrectly assign value to user funds.
$10,000 to $50,000 per bug, assessed on a case-by-case basis
Medium/Low
Bugs that don't threaten user funds
$1,000 to $5,000 per bug, assessed on a case-by-case basis
Create a global marketing campaign that explodes in 2020
Analyze market demand, competitors, and trends in blockchain and crypto technology in 2021
Decide on a suitable blockchain platform (Ethereum, Binance Smart Chain, Solana, Layer-2, etc.) for the project in 2021
Recruit developers, researchers, blockchain experts, and other professionals in 2022
Fully Backed by Coinbase with a Roadmap to 2025
In 2023, research experimental technology to integrate new technology into the Tagomi app in 2024
January 2023
Decentralized Index Deployment: Release the decentralized index system to enhance the decentralization of BRC20.
Optimization of BTC to Layer2 Cross-Chain Bridge: Complete the optimization of the cross-chain bridge from Bitcoin to Layer2 network to improve interaction efficiency and reliability.
Completion of Economic Model Design: Finalize the design of Tagomi economic model, ensuring the rationality of incentive mechanisms and inflation patterns.
Whitepaper Release: Publish the whitepaper of Tagomi, providing detailed explanations of the network's design principles, technical implementations, and development vision.
February 2023
Release of BRC20 Cross-Chain Bridge: Launch the BRC20 cross-chain bridge, facilitating a secure and efficient exchange of assets between Layer2 and Bitcoin.
Bridge Contract Audit: Conduct an audit of the cross-chain bridge contract to ensure contract robustness and security.
Bitcoin Taproot Escape Hatch Test Version Release: Release a test version of the Bitcoin Taproot escape hatch to ensure compatibility with the Bitcoin mainnet.
Alpha Testnet Launch: Initiate the alpha version of the testnet, inviting the community and developers to participate in testing and provide feedback.
March 2023
Release of Economic Model Test Version: Release a test version of the economic model for community members to evaluate and provide feedback.
Release of Data Availability Layer Test Version: Release a test version of the Data Availability layer to ensure reliable retrieval of Layer2 data even in the event of issues on Layer2.
April 2023
Beta Testnet Launch: Launch the beta version of the testnet for more extensive testing, collecting user experience and performance feedback.
Release of Test Version for Forced Exit Module: Release a test version of the Forced Exit module to ensure the reliability of withdrawal operations.
May 2023
Release of Tagomi Stack: Introduce Tagomi Stack, offering tools and services to simplify the development process for developers.
Integration Testing of Tagomi: Conduct integration testing of Tagomi to ensure the collaborative operation of different components and overall stability.
Performance Optimization of Tagomi: Optimize the performance of Tagomi to enhance throughput and response speed.
June 2023
Core Code Audit of Tagomi: Conduct a core code audit to ensure code quality and security.
Security Audit of Tagomi: Perform a security audit to identify and address potential security vulnerabilities.
Open Source of Tagomi DHC Code: Open source the code for Tagomi Dynamic Hide Committee (DHC) to encourage community participation and review.
January 2024
Team building
Make detailed plans for Tagomi
Complete whitepaper
Call for investment funds
February, March, April, May 2024
Release the first version of the main product
Integrate the product with other platforms in the crypto or DeFi ecosystem to enhance usability
Develop new features such as staking, yield farming, and decentralized governance (DAO)
Encourage external developers to participate in finding security vulnerabilities and improving the product
June, July, August, September 2024
Continuously upgrade and update product features based on feedback from the community and the market
Strengthen collaborations with other blockchain projects and expand into international markets
Organize events or promotional campaigns to attract more users and investors
Transfer governance to the community through a DAO, allowing the community to participate in project development decision-making
November and December 2024
Airdrop $9M
Organize token sales for early investors and establish partnerships with investment funds
Develop marketing strategies to grow the community, including through social media platforms
Support MetaMask wallet integration
Pre-sale IDO
Launching Staking
Launching mini games
Negotiate to list the token on major exchanges such as Binance, Huobi, Coinbase, or DEX platforms like Uniswap, PancakeSwap
$TGM listing on DEX
Seek strategic partners, collaborate with crypto exchanges, and related projects
Call for more investment funds
Cooperate with major partners
January 2025
Mainnet Launch of Tagomi: Officially launch the Tagomi mainnet, allowing users to begin transactions and utilize various functionalities on a stable network.
$TGM listing on CEX
Launch Tagomi wallet on CHplay and App store
Launch of trading program on Tagomi app
Multiple payment gateway integration
Reached 1 million app downloads
Integrate all the experiments from 2023 into the Tagomi app
February 2025 and after
Bitcoin Staking: Hold Bitcoin, Earn Altcoin Yield.
Audit Result
The audit did not uncover any high-severity flaws that could impact system confidentiality, integrity, or availability. After the initial audit findings, between January 23 and January 25, 2024, Trail of Bits reviewed the fixes and mitigations implemented by Tagomi Protocol to resolve the issues described in this report.
A summary of outstanding findings is shown below.
A full listing of unresolved or partially resolved findings can be found on page 73 of the TOB Audit Report (Report). The undetermined finding relates to Testing code used in production and is described in further detail on page 77 of the Report.
View the full report here(opens in a new tab).
Neodyme
Scope: protocol-v2
Authored: May 10th 2024
Last Updated: June 27th 2024
View the full report here(opens in a new tab).
Ottersec
Scope: Metamask Snap "Connect" by Drift(opens in a new tab)
