# 🌊💸 Welcome to Fluidity Money Money designed to be moved **Fluidity is a yield generating protocol that rewards people for using their cryptocurrencies.** Fluidity Money tokens (Fluid Assets) are a 1-to-1 wrapped asset that expose holders to randomly paid rewards when they use their cryptocurrencies. Rewards are paid out according to a drawing mechanism held each on-chain transaction of Fluid Assets. These rewards are generated by the cumulative yield generated by the underlying asset, which is deposited and lent on money markets. **With Fluid Assets, yield is gained through utility. The more you utilise your assets, the more yield can be potentially rece*****i*****ved over time.** Existing decentralised finance incentivises leaving interest-bearing products ”idle” – sitting in an account accruing interest. Through wrapping a variety of assets with Fluid functionalities, we effectively grant utility to what would otherwise be stagnant tokens. This has the added benefit of composability and a change in how we interact with blockchain payments as a whole. #### For Senders With Fluidity, you are rewarded for doing what you already do. Using your favourite DEX, paying back a friend, purchasing an NFT, all forms of on-chain value transfer using Fluid Assets can be yield-bearing, at no extra cost. **For Receivers** Senders and Receivers receive the reward amount if a transaction that qualifies wins. You could earn a life-changing amount of money just for receiving a payment. This creates an incentive for a counterparty to accept a Fluid Asset. ### Guides: Jump right in Follow our handy guides to get started on the basics as quickly as possible: {% content-ref url="/pages/0N0bRnYeR3A9tZGL5ira" %} [Learning and getting started](/docs/learning-and-getting-started) {% endcontent-ref %} {% content-ref url="/pages/D7yBJJ2V97cvhCOFaR9E" %} [Use-cases](/docs/use-cases) {% endcontent-ref %} ### Fundamentals: Dive a little deeper Learn the fundamentals of Fluidity to get a deeper understanding of our main features: {% content-ref url="/pages/rwjRlinQqihMqPAcXG3x" %} [Fundamentals](/docs/fundamentals) {% endcontent-ref %} {% content-ref url="/pages/he4HMah3cOoblnHZKZiJ" %} [Utility Mining](/docs/fundamentals/utility-mining) {% endcontent-ref %} *---* *The future of finance excites us. In the world of tomorrow, the way we think about money will be drastically different. The majority of our purchases will be done with digital currencies, and with the utilization of Smart Contracts we can expect a major shift in our economical model.* Fluidity Money is licensed mostly as GPL (). The TRF is licensed with creative commons (license found here) ) ## Useful links Website and whitepapers: Arbitrum Dune: Ethereum Dune: Medium: Telegram: Twitter: Discord: #### Coingecko | Asset | URL | | ----- | ----------------------------------------------- | | fUSDC | | | fUSDT | | | fDAI | | {% embed url="" %} # Learning and getting started {% content-ref url="/pages/GnJB9ZQyFFFlyqhqUEHd" %} [Why Fluidity?](/docs/learning-and-getting-started/why-fluidity) {% endcontent-ref %} {% content-ref url="/pages/vJ1qpFRQ518p0S1ZfXjp" %} [What are Fluid Assets?](/docs/learning-and-getting-started/what-are-fluid-assets) {% endcontent-ref %} {% content-ref url="/pages/A2Ng9wSsE40aCkmCPgxq" %} [How do you get a Fluid Asset?](/docs/learning-and-getting-started/how-do-you-get-a-fluid-asset) {% endcontent-ref %} {% content-ref url="/pages/gJiCTbFGFSmUzI5YcyoG" %} [How are the rewards earned?](/docs/learning-and-getting-started/how-are-the-rewards-earned) {% endcontent-ref %} {% content-ref url="/pages/23HVa3BkTtSy0VGSvuHA" %} [The Economics of a Fluid Asset](/docs/learning-and-getting-started/the-economics-of-a-fluid-asset) {% endcontent-ref %} # Why Fluidity? What is the opportunity cost for using Fluidity? and where is this yield coming from? At times in the present DeFi ecosystem, it may seem that incentives are misaligned. While NFTs and cryptocurrencies are in the public’s eyes, they are being utilised as speculative instruments, instead of their intended utility. Due to the potential of growth, users tend to not spend their crypto assets as the speculative value that they hold is exponentially higher than that of momentary purchases. In a user’s perspective, it would be equivalent to selling a portion of their house to buy pizza, rather than an expendable and fungible asset class. #### **TL;DR: Before now, there was no incentive to spend.** ### What is the opportunity cost for using Fluidity? A person could be holding a yield-bearing asset for the period of time that they hold an asset. Someone could be earning interest and using that to pay through an asset such as *aDAI,* or through the means of a yield generating asset. That is the opportunity cost of utilising a fluid asset to transact with. Instead, what Fluidity does is **aggregate the interest of the people that aren't spending or staking their base assets in the first place.** The interest generated is coming from somewhere where someone might be losing. Even if a user is holding small interest-bearing assets for microtransactions, the opportunity cost from not receiving immediate yield from the small valued interest-bearing asset is so low that users don’t lose from participating in the Fluidity ecosystem. Would a user be willing to lose that opportunity to participate in Fluidity? Is there a potential expected outcome of at least 10x of using our system? Their downside is technically 0. **Example:** > You have $1000 in USDC that you plan on using for various purchases such as NFTs or retail purchases. You could arguably keep your USDC in lending protocols and withdraw it every time you want to spend some of it, but the rewards would likely be measured in cents and depending on the fees and gas the rewards would likely be less that the cost of deposits and withdrawals. > > \ > If that asset were to be swapped into a Fluid version of the base asset, and utilised within a transaction, the user is then subjected to a potential reward as well as having the ability to swap back to their base asset at any time. They have basically lost half a cent, while being exposed to a much higher odds of winning a much larger yield reward.\ > \ > Hence the opportunity cost is extremely low. Even if a user planned on only temporarily interacting with Fluid assets, they can also see that the opportunity cost would be extremely low. Take the USDC example in the same light as *aDAI*, rewarding the user a 5% APY for simply holding the token within that same 1 hour period that they were to interact with Fluid assets instead. By holding that *yield generating asset* for the specified period, you would have generated a return of USD$0.05. As a side note, it is important to mention that a user holding a fluid asset would have an even lower opportunity cost for participating, as they are more likely to transact due to the mechanism presented to them. **The way someone would use on-chain assets then becomes the opposite of staking.** The novelty is that you are now having a system that rewards users for transacting. Even if there were to be an innovation in staking or intermediary transitions, Fluidity would still have the upper hand when it comes to the opportunity cost due to the high-value proposition of rewarding transactions. # What are Fluid Assets? At the core of Fluidity lies Fluid Assets, which pay yield when you use them. A Fluid Asset is a wrapped standard (ERC-20, SPL) token that represents an underlying principal token. A novel property of Fluid Assets is that they expose users to randomly paid rewards or yield when they are used (sent or received). For example, one Fluid USDC (ƒUSDC) would simply be a USDC token deposited into the Fluidity Protocol. It is worth the same as the underlying principal and can always be redeemed for the underlying collateral. **A Fluid Asset is different than a yield-bearing asset. A yield-bearing asset such as cUSDC or aUSDC would pay yield when you hold onto it, whereas a Fluid Asset pays yield when you use it.** **This creates an incentive to utilise your cryptocurrencies instead of holding on to them.** {% content-ref url="/pages/A2Ng9wSsE40aCkmCPgxq" %} [How do you get a Fluid Asset?](/docs/learning-and-getting-started/how-do-you-get-a-fluid-asset) {% endcontent-ref %} {% content-ref url="/pages/23HVa3BkTtSy0VGSvuHA" %} [The Economics of a Fluid Asset](/docs/learning-and-getting-started/the-economics-of-a-fluid-asset) {% endcontent-ref %} # How do you get a Fluid Asset? To mint a Fluid asset, you can go to the [Fluidity Webapp](https://fluidity.money) and swap a supported principal token for a Fluid counterpart. Initially, we will be supporting stablecoins but any asset can be wrapped into a Fluid Asset, as long it has a Money Market with sufficient liquidity available. **For example, converting 1 USDC will allow you to mint 1 ƒUSDC.** **You can always redeem 1 ƒUSDC back for 1 USDC coin at any time.** As the project matures, you will be able to get Fluid assets from multiple sources, such as AMMs or DEXs like (Uniswap, Sushiswap, 0x), NFT marketplaces, and practically any other application where you would be exchanging assets. # How are the rewards earned? ### If using a Fluid Asset can allow a person to potentially earn yield, where does this yield come from? {% hint style="info" %} Fluidity borrows from the yield generation concept to create a 'no-loss' rewards savings pool. {% endhint %} As mentioned earlier, to mint a Fluid Asset a principal token is required to be locked up. When you mint 1 ƒUSDC you have to deposit 1 USDC token in exchange. Fluidity earns yield on the deposited USDC token and distributes it to the reward pool, which is only accessible to people who utilise the respective Fluid asset. The yield is generated from lending the principal asset into Decentralised Finance protocols such as *Compound* or *Solend*, or utilise in yield generating strategies. When a Fluid Asset is swapped back for the principal, the contract withdraws the tokens from the Defi Protocol. This way Fluidity does not charge any fees to utilise Fluid assets, and rewards can be sizeable. In the next section, we explore how these rewards are sized, the expected payouts, probabilities and how Fluidity protects itself. # The Economics of a Fluid Asset How does Fluidity protect itself from sybil attacks? How is the probability of payouts and the associated sizes calculated? ### How Fluidity protects against attackers {% hint style="info" %} #### **Optimistic Solution** The Optimistic Solution is Fluidity’s answer to preventing spam attacks on the protocol by using gas fees as a protection mechanism, ensuring that attackers will always spend more in fees than they would receive in rewards. It works by calculating the expected value for every user and including that variable in the Transfer Reward Function. {% endhint %} At this point you may be wondering, if Fluid Assets, pay yield when you use them, how does the protocol protect against bots sending money back and forth or 'sybil attacks'? Fluidity essentially uses what we call an "Optimistic Solution" where we make a trivial assumption: *"Imagine if the gas fee or platform fee when using the Fluid Asset for example (fUSDC) was more than the yield that one could extract from the protocol?"* Sending or using a Fluid Asset costs a small gas fee or platform fee such as (LP fees or Trading fees). These are network or platform fees, that you would have to pay regardless of using a Fluid Asset or not, hence we utilise them as protection, as we do not charge any extra fees. **For example:** > Imagine an attacker sending Fluid USDC (ƒUSDC) back and forth 1000 times, costs $5,000 in gas fees. ($5/tx). If the yield the attacker earnt was less than $5,000, for example $2,500. The attacker will go bankrupt over time. We call this the **Optimistic Solution**. ### How often and how large are the rewards? {% hint style="info" %} #### Transfer Reward Function (TRF) Fluidity’s payout mechanism is determined by the Transfer Reward Function (TRF for short). In its base form, it includes the Optimistic Solution to prevent spam attacks and ensures that the protocol pays out all of the gathered yields from the underlying assets. The drawing mechanism for picking “winners” is similar to that of a 'lottery", with a pool of “balls” to draw from for a single transaction. {% endhint %} To be able to calculate how often and large the rewards are, we need a few pieces of information. \*\*\*\* Including: 1. The size of the reward pool (**Ξ**) 2. The annual number of fluid txs as moving average (ATX) 3. The gas fee or fee paid to do a transaction (g) 4. The number of reward tiers (m) {% hint style="info" %} This information is required to be able to ensure that we can protect the protocol from attackers and that the protocol is not overtime paying out more in rewards than it is able to generate in yield\*\*.\*\* {% endhint %} We can input this information in the TRF to generate the associated payouts. We recompute the payouts every block to account for changes in **Ξ**, ATX and g. The size and frequency of payouts change every block based on how these variables change. **In the next section, we will explore an example.** {% content-ref url="/pages/CS4DEvrQGwAyYtJPEpNx" %} [Transfer Reward Function (TRF) Example](/docs/learning-and-getting-started/the-economics-of-a-fluid-asset/transfer-reward-function-trf-example) {% endcontent-ref %} ### Elastic Sigmoid Curve The Elastic Sigmoid Curve (ESC) is designed to incentivise and reward good behaviour in the protocol through higher expected outcomes over time. It depends on the holdings of both sender and receiver to ensure larger payouts for providing liquidity and participating in the governance of the DAO. You can learn more [here](https://fluidity.wispform.com/feb5f260). # Transfer Reward Function (TRF) Example An example of a payout table generated by the Transfer Reward Function. {% hint style="success" %} This is a sample example of the TRF in action and how the rewards and expected outcomes change. {% endhint %} ### High to average transaction fee chain and protocols: As an example Fluidity provides the following numbers for a $50M reward pool with 80,000 daily fluid transactions, an average gas fee of $3 and six tiers of rewards: {% hint style="info" %} *Note: the sending party receives 80% and the receiving party receives 20% of the rewards.* {% endhint %} | Probability (%) | Reward Received ($) | | --------------- | ------------------- | | 42.66 | 0.62 | | 15.69 | 1.69 | | 2.39 | 11.06 | | 0.15 | 176.89 | | 3.23e-3 | 8181.33 | | 1.41e-5 | 1,865,342.25 | As can be seen in the example above, **over half of all transactions receive 60 cents up to $1.70, one in every 650 transactions receives $180, and four times a year users can receive $1.8M!** {% hint style="info" %} If you pay a higher gas fee, you will have a higher expected outcome of winning a larger prize, although this caps at the APY %, so paying an extremely large gas fee does not guarantee a 100% win chance. {% endhint %} ### Low transaction fee chain and operating protocols on top: What if you were to use a chain that had low transaction fees? Every event where you send a transaction and there is a difference between senders and receivers in the transaction run all counts in theory as a transaction fee. Let's use Solana as an example. Setting similar parameters as the previous example with some modifications: * $50M in the reward pool * 80K daily fluid TXs * Solana Gas Fee: $0.00025.\\ * **Saber $1000 Swap** * Solana Gas Fee: $0.00025 + 0.3% Saber fee = $3 fee. * **Solanart $100 NFT Purchase** * Solana Gas Fee: $0.00025 + 3% Solanart fee = $3 fee. If you were to do a transaction on top of these protocols will get a similar transaction probability reward metric as above. So in essence, by doing a Saber trade or purchasing an NFT on Solanart, a user has the **same probability of being rewarded millions through Fluid Assets as they do on high gas chains.** # Tutorials # How to use Fluidity In order to receive fAssets and start earning rewards for transacting, you first need to wrap your tokens through the Fluidity webapp. We will explain how to do this in the following. ### 1. **Connect your wallet to the Fluidity webapp** On the dashboard site, you need to connect your wallet with the button in the bottom left corner. We support Browser based wallets (Metamask) and WalletConnect.

Connect your wallet with the button in the bottom left corner

After you have connected your wallet, you will be able to see your own dashboard, your activity, the rewards you have earned so far, and the rewards you are able to claim.\
### **2. Fluidify your money! (and add *****f*****Tokens to your wallet)** Next, click on the “FLUIDIFY MONEY” button in the bottom right corner. From there, you will be able to see the assets that you will be able to fluidify (wrap). Click on the little + next to the token to add them to your Metamask.

Fluidify your money!

Now, you can choose one of the supported stables (USDC, USDT, DAI, FRAX and TUSD) and drag and drop them into the ring in the middle. After choosing the amount, you can click on “Create Fluid Asset”, and a wallet notification will pop up asking you to confirm the transaction. After confirming, your asset will be wrapped and you will receive the fluid version of it in your wallet. If you wish to exchange your fAssets back for your original assets you’re free to do so at any point in time.

Choose which stable to fluidify and the amount

### 3. **Enter the *****Incentive Layer*** Finally, you can send and receive fluid transactions normally with your wallet or just use your fluid assets on other protocols. Around every 2nd transaction will be eligible for a reward, so be sure to try it out and earn those rewards! It’s as simple as that. You can have a look at the rewards page to claim outstanding rewards and look at your history. ## **Bonus** 4\. **Swapping your fluid assets, providing liquidity** Go to any of the DEXs we support, and watch as you earn yield while you swap your fluid assets for other tokens. You can also create your own liquidity pools for different fluid asset pairs or add liquidity to existing pairs. If you’re a marketplace or a merchant you can now earn yield just for accepting fluid assets as a form of payment. Feel free to reach out to us regarding integrations!

Provide liquidity for fluid assets (.- -. -.. ……. . .- .-. -. ……. ..-. .-.. ..- .. -.. ……. … — — — — -.)

{% hint style="info" %} Tweet us screenshots and the tx id of your winnings @fluiditymoney. Who knows, maybe you’ll win more than just those fluid rewards ;) {% endhint %} \

\
# Addresses {% content-ref url="/pages/VVe6p16hHPlckRXGwF8t" %} [Arbitrum](/docs/addresses/arbitrum) {% endcontent-ref %} {% content-ref url="/pages/olXsCEtKYwKlCJAzqUCG" %} [Solana](/docs/addresses/solana) {% endcontent-ref %} {% content-ref url="/pages/3goua70KrEPHRgGxxYzm" %} [Sui](/docs/addresses/sui) {% endcontent-ref %} # Arbitrum | Contract | Address | | ------------------------------------------------------------- | ------------------------------------------ | | FLY Token | 0x000f1720a263f96532d1ac2bb9cdc12b72c6f386 | | StakingV1 | 0x9E8892E443AD6472e4D9362DF6D0C238000028a3 | | fUSDT | 0xC9FA90D24B7103Ad2215DE52afec5e1E4C7a6e62 | | fUSDC | 0x4CFA50B7Ce747e2D61724fcAc57f24B748FF2b2A | | fDAI | 0x1b40e7812E75D02Eef97E4399c33865D2Ff5952b | | ProxyAdmin used for TransparentProxies | 0x80d82aF50EF0277b7A888616a7CE9F2D2F39DAe2 | | Registry | 0x28EE3aCA2DAA47a7585C5c579dBb0998C08f845d | | LootboxStaking | 0x770f77A67d9B1fC26B80447c666f8a9aECA47C82 | | Executor | 0xBdC05dE358bA65720f5cc74BBc615C029220C67D | | Chronos Booster UtilityClient | 0xEB6057AE11BE83fFE0a3C191a41D67728938886B | | LootboxConfirmAddressOwnership | 0x18EB6Ac990BD3a31dD3e5dd9c7744751c8E9DC06 | | Wombat fixed token distribution UtilityClient | 0x62363df6e7B1b06BACFa232B7cb1f0835c8ef0A0 | | Sushi fixed token distribution UtilityClient | 0x4E34F71a48AA3F9d5832D6d419a1De4c39657bc4 | | Trader Joe's Uniswap-powered token distribution UtilityClient | 0xE25324C1410f98ae18848a96678892f9EA5d9D03 | | Arbitrum global amounts given away UtilityClient | 0x77f56d00fB78a701Af3A09c79f2B11cfa38f9Ff2 | | Camelot Uniswap-powered token distribution UtilityClient | 0xe18f872f2FaE38EbC20B0d49dAf9cAa74D887701 | ## Specifics ### fUSDT | Description | Value | | ----------------------- | ------------------------------------------ | | Token address | 0xC9FA90D24B7103Ad2215DE52afec5e1E4C7a6e62 | | WorkerConfig | 0xf3fd0c0c1ae303F5D46CFb510eBa07F1323529Af | | AAVE liquidity provider | 0xad7e2165FEa1d29030dF806cE4d530fa7a44511B | | aToken address | 0x6ab707Aca953eDAeFBc4fD23bA73294241490620 | | Beacon address | 0x90AEfF2D9376476F770463c77aF979dfd115Bbf0 | | Emergency council | 0x5bC5DB835Af82Ab2333b1a60f529038F6508c94C | | Decimals | 6 | | Short name | fUSDT | | Name | Fluid USDT | ### fUSDC | Description | Value | | ----------------------- | ------------------------------------------ | | Token address | 0x4CFA50B7Ce747e2D61724fcAc57f24B748FF2b2A | | WorkerConfig | 0xf3fd0c0c1ae303F5D46CFb510eBa07F1323529Af | | AAVE liquidity provider | 0x91beB5C41dF001175b588C9510327D53f278972A | | aToken address | 0x625E7708f30cA75bfd92586e17077590C60eb4cD | | Beacon address | 0x90AEfF2D9376476F770463c77aF979dfd115Bbf0 | | Emergency council | 0x5bC5DB835Af82Ab2333b1a60f529038F6508c94C | | Decimals | 6 | | Short name | fUSDC | | Name | Fluid USDC | ### fDAI | Description | Value | | ----------------------- | ------------------------------------------ | | Token address | 0x1b40e7812E75D02Eef97E4399c33865D2Ff5952b | | WorkerConfig | 0xf3fd0c0c1ae303F5D46CFb510eBa07F1323529Af | | AAVE liquidity provider | 0xB7D37C5b15CDF29265C20668c20cD78586c423A8 | | aToken address | 0x82E64f49Ed5EC1bC6e43DAD4FC8Af9bb3A2312EE | | Beacon address | 0x90AEfF2D9376476F770463c77aF979dfd115Bbf0 | | Emergency council | 0x5bC5DB835Af82Ab2333b1a60f529038F6508c94C | | Decimals | 18 | | Short name | fDAI | | Name | Fluid DAI | ### Registry | Description | Address | | -------------- | ------------------------------------------ | | Implementation | 0x0079e56FA522281512B1b7ef1414905d712e3457 | | Proxy | 0x28EE3aCA2DAA47a7585C5c579dBb0998C08f845d | | ProxyAdmin | 0x80d82aF50EF0277b7A888616a7CE9F2D2F39DAe2 | ### Executor | Description | Address | | -------------- | ------------------------------------------ | | Implementation | 0x5d9cc13554A01cB9eF0EA4079053a3630044C1DD | | Proxy | 0xBdC05dE358bA65720f5cc74BBc615C029220C67D | | ProxyAdmin | 0x80d82aF50EF0277b7A888616a7CE9F2D2F39DAe2 | ### LootboxStaking | Description | Address | | ----------------------- | ------------------------------------------ | | Implementation | 0xe95E8C4Ad64015046807272E492588119929E97b | | Proxy | 0x770f77A67d9B1fC26B80447c666f8a9aECA47C82 | | ProxyAdmin | 0x80d82aF50EF0277b7A888616a7CE9F2D2F39DAe2 | | Camelot fUSDC/USDC pair | 0x1Cb94adFd3314d48Ca8145b2c6983419257c0486 | | Camelot fUSDC/WETH pair | 0x85DF70e1636D28AB29bB81dF93B68834F4308750 | # Solana ## Mainnet ### At a glance... | Text | Value | | ---------------- | -------------------------------------------- | | Program ID | HEvunKKgzf4SMZimVMET6HuzAyfGJS4ZMShUz94KLUdR | | Program PDA | CBrYRFyEwyn9gMPVFbRBwfcoU6JnViTEBaYyvFZGgZnc | | fUSDC token mint | Ez2zVjw85tZan1ycnJ5PywNNxR6Gm4jbXQtZKyQNu3Lv | | fUSDT token mint | D5zHHS5tkf9zfGBRPQbDKpUiRAMVK8VvxGwTHP6tP1B8 | ### USDC | Text | Value | | ----------------------------------------------------------- | -------------------------------------------- | | The address of the regular USDC token, as used by Solend | EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v | | The address of the fUSDC token | Ez2zVjw85tZan1ycnJ5PywNNxR6Gm4jbXQtZKyQNu3Lv | | Obligation account | J6ZHkcCiAKSKTmoUZzozZ2L1Wwm34WF2VQamyu2Sno6A | | Reserve account | BgxfHJDzm44T7XG68MYKx7YisTjZu73tVovyZSjJMpmw | | The public key of Pyth (used as an oracle for price lookup) | Gnt27xtC473ZT2Mw5u8wZ68Z3gULkSTb5DuxJy7eJotD | | The public key of the Switchboard oracle for USDC | CZx29wKMUxaJDq6aLVQTdViPL754tTR64NAgQBUGxxHb | | The name of the token | fUSDC | | The number of decimals in the token | 6 | | Data account | Gy6weHjgTxqFqosH1sGdECC2jG4j9h8t347KrumsQzce | | PDA | CBrYRFyEwyn9gMPVFbRBwfcoU6JnViTEBaYyvFZGgZnc | | Base token account | PwXvsW9wzK3cBryYa8xXNm9gfamfmDGdWUE9YLiuhHD | | Fluid token account | 3GCJGw174tvJfP4vXrZ3Xoev1c9sG1HNzUep84AAPHoM | | Solend program | So1endDq2YkqhipRh3WViPa8hdiSpxWy6z3Z6tMCpAo | | Collateral account | 8uXbxhRBGijWWgFhCw6kPAMHBBnqijwvKCZ1GGVLjErc | | Reserve | BgxfHJDzm44T7XG68MYKx7YisTjZu73tVovyZSjJMpmw | | Reserve liquidity supply | 8SheGtsopRUDzdiD6v6BR9a6bqZ9QwywYQY99Fp5meNf | | Collateral mint | 993dVFL2uXWYeoXuEBFXR4BijeXdTv4s6BzsCjJZuwqk | | Lending market | 4UpD2fh7xH3VP9QQaXtsS1YY3bxzWhtfpks7FatyKvdY | | Market authority | DdZR6zRFiUt4S5mg7AV1uKB2z1f1WzcNYCaTEEWPAuby | | Collateral supply | UtRy8gcEu9fCkDuUrU8EmC7Uc6FZy5NCwttzG7i6nkw | ### USDT | Text | Value | | ----------------------------------------------------------- | -------------------------------------------- | | The address of the regular USDT token, as used by Solend | Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB | | The address of the fUSDT token | D5zHHS5tkf9zfGBRPQbDKpUiRAMVK8VvxGwTHP6tP1B8 | | Obligation account | 446FsyYfANPuiK18DYGLwQm6B5b2MecTUvm1KtnDMGca | | Reserve account | 8K9WC8xoh2rtQNY7iEGXtPvfbDCi563SdWhCAhuMP2xE | | The public key of Pyth (used as an oracle for price lookup) | 3vxLXJqLqF3JG5TCbYycbKWRBbCJQLxQmBGCkyqEEefL | | The public key of the Switchboard oracle for USDT | 5mp8kbkTYwWWCsKSte8rURjTuyinsqBpJ9xAQsewPDD | | The name of the token | fUSDT | | The number of decimals in the token | 6 | | Data account | DrKwQQrKcbNCLkVfAVasxk1j7ccCaXVfdVdS6RijRZo | | PDA | 5tCSTEkozvUw9YZxZzsGkR9upMQNacFEBiYN21nfCj77 | | Base token account | jBFDkQVdhX5E3EDtisNGozg2zQR1ZGMgX2edWbuao1T | | Fluid token account | 45u3LjY7ehw6ZGh8KK2HVPRdYY52BQJskja9J2PUQUEu | | Solend program | So1endDq2YkqhipRh3WViPa8hdiSpxWy6z3Z6tMCpAo | | Collateral account | DHoXhJ53JJit81q9zTUCCxkDCQBMh3C75wqW4jSjEPeo | | Reserve liquidity supply | 3CdpSW5dxM7RTxBgxeyt8nnnjqoDbZe48tsBs9QUrmuN | | Collateral mint | BTsbZDV7aCMRJ3VNy9ygV4Q2UeEo9GpR8D6VvmMZzNr8 | | Lending market | 4UpD2fh7xH3VP9QQaXtsS1YY3bxzWhtfpks7FatyKvdY | | Market authority | DdZR6zRFiUt4S5mg7AV1uKB2z1f1WzcNYCaTEEWPAuby | | Collateral supply | CXDxj6cepVv9nWh4QYqWS2MpeoVKBLKJkMfo3c6Y1Lud | | Pyth account | 3vxLXJqLqF3JG5TCbYycbKWRBbCJQLxQmBGCkyqEEefL | | Switchboard account | 5mp8kbkTYwWWCsKSte8rURjTuyinsqBpJ9xAQsewPDD | ## Devnet | Text | Value | | --------------------------------------------- | -------------------------------------------- | | The program’s address | GjRwsHMgCAX2QUrw64tyT9RQhqm28fmntNAjgxoaTztU | | The time to update the prize pool | 1m | | The TVL data account public key | CAKG5gr5ZFGyEXb98pXMqUCdu8gqc5VtXxXkonpcZixW | | The Solend public key | ALend7Ketfx5bxh6ghsCDXAoDrhvEmsXT3cynB6aPLgx | | The starting slot to begin reading slots from | latest | | The Solend TVL account public key | The TVL account containing Solend | | Saber RPC url | | | Saber program ID for swapping | SSwpkEEcbUqx4vtoEByFjSkhKdCT862DNVb52nZg1UZ | | Pyth program public key | J83w4HKfqxwcq3BEMMkPFSppX3gqekLyLJBexebFVkix | ### USDC | Text | Value | | ----------------------------------------------------------- | -------------------------------------------- | | The address of the regular USDC token, as used by Solend | zVzi5VAf4qMEwzv7NXECVx5v2pQ7xnqVVjCXZwS9XzA | | The address of the fUSDC token | 2XGVdHsAiMM9QDM9tV4fwQ2JnyWdSJaiXp2KifLJD1oa | | Obligation account | HbmfhzwMF71jWxfKoD7sjCLrsVhvt2zEEux8t8oWqFAH | | Reserve account | FNNkz4RCQezSSS71rW2tvqZH1LCkTzaiG7Nd1LeA5x5y | | The public key of Pyth (used as an oracle for price lookup) | 5SSkXsEKQepHHAewytPVwdej4epN1nxgLVM84L4KXgy7 | | The public key of the Switchboard oracle for USDC | CZx29wKMUxaJDq6aLVQTdViPL754tTR64NAgQBUGxxHb | | The name of the Fluid token | fUSDC | | The number of decimals in the token | 6 | | Data account | 5HYs9eC9nwCur1buYA6KiXAxzb2ouhaU1UEZUYXGHcsN | | PDA | 89B3rmx8nL7Zc2t6AhFEbC7g2bkzBZTGGdWEibLe3jBW | | Base token account | 4tSKX8iF6Ps6R8GjFsGS1UtxDxAMRUyACTzJaeE1ywSJ | | Fluid token account | Em9aU6TJRHntxm6yqtpMH4amAYSZWmTxKeueg22mKa5f | | Solend program | ALend7Ketfx5bxh6ghsCDXAoDrhvEmsXT3cynB6aPLgx | | Collateral account | HAWufrXb8ajGkeEVQTi3GNGNypeKzLGYCiCRJhvsCuA4 | | Reserve liquidity supply | HixjFJoeD2ggqKgFHQxrcJFjVvE5nXKuUPYNijFg7Kc5 | | Collateral mint | E2PSSXsXJGdpqhhaV3rYPpuy1inRCQAWxcdykA1DTmYr | | Lending market | GvjoVKNjBvQcFaSKUW1gTE7DxhSpjHbE69umVR5nPuQp | | Market authority | EhJ4fwaXUp7aiwvZThSUaGWCaBQAJe3AEaJJJVCn3UCK | | Collateral supply | FiUyeMAnZYkLCbrPGwjJWQwzYJ5AjD6p9N9fx6VxDPMt | | Pyth account | 5SSkXsEKQepHHAewytPVwdej4epN1nxgLVM84L4KXgy7 | | Switchboard account | CZx29wKMUxaJDq6aLVQTdViPL754tTR64NAgQBUGxxHb | ### USDT | Text | Value | | ----------------------------------------------------------- | -------------------------------------------- | | The address of the regular USDT token, as used by Solend | Bp2nLuamFZndE7gztA1iPsNVhdJeg9xfKdq7KmvjpGoP | | The address of the fUSDT token | 97JpYk6S7i9ydzjNwb92DQEfsA1KUUWSwnWGaGDFe6bk | | Obligation account | 2VmszETnb3HkvuMKYqTaPbr7zWh8jfhHut6bUQPwAdrR | | Reserve account | ERm3jhg8J94hxr7KmhkRvnuYbKZgNFEL4hXzBMeb1rQ8 | | The public key of Pyth (used as an oracle for price lookup) | 38xoQ4oeJCBrcVvca2cGk7iV1dAfrmTR1kmhSCJQ8Jto | | The public key of the Switchboard oracle for USDC | 5mp8kbkTYwWWCsKSte8rURjTuyinsqBpJ9xAQsewPDD | | The name of the Fluid token | fUSDT | | The number of decimals in the token | 6 | | Data account | 2qHv5TKk6QS9GA48cGTsYmJU6Y8FqBrqCueM5GFsY1Js | | PDA | F8Hi4Vjgv9dnyfVnyhkFUejvUbycSoSRBUL62QkBbMgX | | Base token account | 3CrzEhddx2fRbSY4dKwcefeZk23A2Bhw2zyshCTgcxH6 | | Fluid token account | DaX514BjysF5pfoaCk4U6QYBxCWdVfqvBEhyQWzCVvXn | | Solend program | ALend7Ketfx5bxh6ghsCDXAoDrhvEmsXT3cynB6aPLgx | | Collateral account | EhjQvMiRjM3TRTZFieNMppVVBtSSmqVL3hENK5SJGbNj | | Reserve liquidity supply | 45WeSuv9fwiG1Z1t9j4Mj8D3Rto4BXkGq8huTRupdbVt | | Collateral mint | ACo8zUxnXNaTvjvN5S56C7KLWzCH4pXjSMU7iAg6dHj8 | | Lending market | GvjoVKNjBvQcFaSKUW1gTE7DxhSpjHbE69umVR5nPuQp | | Market authority | EhJ4fwaXUp7aiwvZThSUaGWCaBQAJe3AEaJJJVCn3UCK | | Collateral supply | 8vC5UkqSAJkrZ5Srwbn243sCx7s8UC1nBZ5cbtNv1ui3 | # Sui ### fUSDC | Description | Object ID/address/setting | | ------------------------ | -------------------------------------------------------------------------------------------------- | | Deployed `fluidity_coin` | `0x11d8b87037c386df1e32487dbde48b1d7659679a6c370630fb834114140e1c69` | | Scallop version | `0x07871c4b3c847a0f674510d4978d5cf6f960452795e8ff6f189fd2088a3f6ac7` | | Scallop market ID | `0xa757975255146dc9686aa823b7838b507f315d704f428cbadad2f4ea061939d9` | | TreasuryCap object | `0x3bed0f0b197676b66f1025ba406a2e91774b453056921cc4c8fd90ff38382ae1` | | Coin contract ID | `0x11d8b87037c386df1e32487dbde48b1d7659679a6c370630fb834114140e1c69::fluidity_coin::FLUIDITY_COIN` | | Global object | `0x18365d5be14497ee171efb95738b5eb46b103bed4847a24a3ec00f16c0f1bcc8` | | Coin reserve | `0x17793e2620b3227244be3b7023debb6966877d4b48f6599010a027d236d9c5a0` | | UserVault object | `0xefc770fd224aa13a8a4b182c7a32db4526f561d30608284709628cc98d7f0c2e` | | PrizePoolVault object | `0x51f10410463b8561a6e0030767dd2d973dfd8983b526c48dc163ead1e932455d` | | AdminCap object | `0x5492f2400bcf04e41137bb7c95b7c82dd39f2c9305ace57f6d0525f6a4d26536` | | WorkerCap object | `0xc517768521fe7d12491b6d328b58b2414f1cecc0aa8f1c7d6949a242e558a6eb` | | DAOCap object | `0xc31834e3d49e698caff39ccc5b4d8dd2a6fbad83cc9af6495b57203ff10f592d` | | EmergencyCap object | `0xc232b72053e3c088a9e98953e35e48a692d3c23d6011539c96c04cb107aa4bfb` | | Underlying token | `0x5d4b302506645c37ff133b98c4b50a5ae14841659738d6d733d59d0d217a93bf::coin::COIN` | # Superposition devnet | Name | Address | | ------------------ | ------------------------------------------ | | | | | Super USDC (sUSDC) | | | Test Token 1 | 0x2F26b901590801476C5bAC1dEbc4E42379127A44 | | Test Token 2 | 0x3F511b0F5Ce567899DeeE6A3c80A2742272687D0 | | Test Token 3 | 0x3eBb6Ac8E85F3E77976DF2Fa95b3Dc2b06Ac2741 | | Superposition AMM | | | Permit2 router | 0x43A878df882AF63cAa81d0267D49ec4Bb31C57d8 | # Fundamentals {% content-ref url="/pages/1zypIPFBQWhl8wy6Ilg4" %} [FAQ](/docs/fundamentals/faq) {% endcontent-ref %} {% content-ref url="/pages/eL4SD9UFLQbNjXNBHOKv" %} [Fluidity Wars](/docs/fundamentals/fluidity-wars) {% endcontent-ref %} {% content-ref url="/pages/he4HMah3cOoblnHZKZiJ" %} [Utility Mining](/docs/fundamentals/utility-mining) {% endcontent-ref %} {% content-ref url="/pages/jPSDAMjtt3rSR6hrrF2C" %} [Understanding the $FLY Governance Token](/docs/fundamentals/understanding-the-usdfluid-governance-token) {% endcontent-ref %} {% content-ref url="/pages/67dDAdQk4Mra59rEWIk1" %} [Governance structure](/docs/fundamentals/governance-structure) {% endcontent-ref %} {% content-ref url="/pages/LlDIGqKMDzKeBI5rY3d4" %} [Launch restrictions (mint limits)](/docs/fundamentals/launch-restrictions-mint-limits) {% endcontent-ref %} {% content-ref url="/pages/pj5BrrgKd2shVka6uITs" %} [Advisory team](/docs/fundamentals/advisory-team) {% endcontent-ref %} {% content-ref url="/pages/heqPQAPxCqFoFzqlV9qn" %} [👩🏫 Laws of Fluidity](/docs/fundamentals/laws-of-fluidity) {% endcontent-ref %} {% content-ref url="/pages/UQxsRrkOw9K6uIeeMkRr" %} [Roadmap](/docs/fundamentals/roadmap) {% endcontent-ref %} # FAQ Frequently asked questions about the security of Fluidity and its mechanisms. ### Do I need to integrate or use special wallets to use Fluidity? Fluid Assets are a regular token to the corresponding blockchain, (ERC-20, SPL Token). As long as Fluid Assets are supported on your chain of choice and your protocol or application supports regular tokens then you are able to participate in the Fluid Economy. ### **Do I own my Fluid assets? Is there a risk of me losing my base asset?** You have total ownership of your Fluid Assets. A Fluid Asset is essentially a wrapped token whose value is tied to that of the underlying base cryptocurrency. There is no risk of losing the base asset as Fluid Assets are 1:1 pegged to their base asset counterparts and can be redeemed fully at any time. ### **How are rewards distributed?** When you use a Fluid Asset, your balance may increase. This means you have received a reward. The number of rewards you win changes based on several variables. You do not have to claim them; they will be airdropped to the wallets that originated and received the Fluid Assets. See : [The Economics of a Fluid Asset](/docs/learning-and-getting-started/the-economics-of-a-fluid-asset#how-often-and-how-large-are-the-rewards) Rewards are distributed in an 80-20 manner. The sending party receives 80% of the reward and the receiving party receives 20% of the reward. ### **1:1 exchange rate?** Fluid Assets are pegged to the collateral and Fluidity does not hold custody of your tokens - they are escrowed on the smart contract. You are free from market volatility risk when exchanging your Fluid Assets to the base asset you have deposited at any point in time through our web application, and if it is down, through the method call on the corresponding swap smart contract. ### Where can I use a Fluid Asset? What are some use cases? You can use Fluid Assets in any supported Blockchain and Protocol. We are currently live on both Ethereum and Arbitrum mainnet, and plan on releasing on Solana, Polygon as well as other chains in the near future! There are a variety of use-cases where Fluid Assets may be used, some of which include: * Sending, receiving, and swapping tokens * Minting, trading, and selling NFTs * Blockchain-based gaming * Performing transactions in a DEX Anything that requires a transaction of value to be made can be enhanced through the interaction within the Fluidity ecosystem. You can have a more detailed read on Fluidity utility and use-cases below: {% content-ref url="/pages/D7yBJJ2V97cvhCOFaR9E" %} [Use-cases](/docs/use-cases) {% endcontent-ref %} # Fluidity Wars Fluidity Wars, Utility Mining, Curve Wars and a snapshot of the present state of liquidity mining and DeFi. ### A snapshot of the present. Let's have a look at *Curve Wars*. Curve’s governance, attractive yields, and token lockup distribution system are and will be a prominent manner of moving liquidity within the crypto space. It also allows for protocols to create attractive liquidity mining programs. Liquidity, however, is not directly correlated to users. It is also important to note that protocols sustaining liquidity mining programs usually see a brief spike in users without creating stickiness, as well as having costly liquidity mining programs. We are building the utility version, hence the coined term ‘[**Utility Mining**](/docs/fundamentals/utility-mining)’. {% hint style="info" %} Protocols can utilise Fluidity’s ‘[**Utility Mining**](/docs/fundamentals/utility-mining)’ to distribute their Governance Tokens to end-users and attract new users to their protocols. {% endhint %} *Curve Wars* focuses on where liquidity moves in the DeFi space, Fluidity is about where users move in the space, and luckily for us, users have a direct positive correlation with liquidity and its flow. ### Fluidity and the future of DeFi In the Fluidity ecosystem, [**Utility Mining**](/docs/fundamentals/utility-mining) rewards users with governance tokens and other incentives, such as higher yield, when targeted on-chain interactions are taken by a user. **For example:** Using a Fluid Asset, performing a specific action in the protocol (Swapping a certain pair, transacting a certain amount, etc.). Other protocols can also utilise Utility Mining to provide a fairer mechanism for the distribution of their Governance Tokens to end-users and attract new users to their protocols, helping bootstrap themselves. **Example:** *Users swapping on an AMM can earn supplement yield in native tokens through Fluidity. Allowing an AMM to target users, revenue and liquidity to be moved.* \_\_ ### Fluidity Wars As Fluidity allows for user attention and behaviour to be incentivized, protocols can capture users by participating in the Fluidity governance mechanism and affecting how the [Utility Mining](/docs/fundamentals/utility-mining) mechanism behaves. In Fluidity, governance tokens, yield and rewards are extracted through actions, this means that specific action can pay higher yield than other actions, allowing protocols to consolidate user attention.\\ #### **Governance can effect not only emissions/ yield differences on using specific protocols, but even effect specific Fluid Asset pairs, and chains.** {% hint style="info" %} An example outcome of Fluidity Governance can result in users of Fluid Assets on Sushiswap receiving higher expected outcome and payouts than users of Uniswap. This results in potentially users of Fluid Assets on Uniswap migrating to Sushiswap to capture higher emissions and yield, when they trade using Fluid Assets.\ \ A secondary example outcome of Fluidity Governance can result in users of Fluid Frax receiving higher expected outcome or governance token emissions that users of Fluid USDT for the same actions. (A $1000 trade using Fluid Frax (fFRAX) results in higher expected outcome/yield than a $1000 trade using Fluid USDT (fUSDT). This creates more demand for fFRAX and FRAX.\ \ The decisions can be extrapolated to different chains, and dApps (such as NFT Marketplaces, or games). {% endhint %} #### The Potential Significance of Fluidity Wars As Fluidity allows protocols to capture user attention and eventually incentivize specific behaviour, this can have significant effect on how protocols engage with Fluidity governance mechanism. Given critical mass of Fluid assets in circulation. protocols can significantly be affected by the outcome of Fluidity Governance. Contrary to Curve Wars, that affects liquidity on specific stable coins pairs, the outcome of Fluidity Wars can effect products ranging from Dexes, NFT Marketplaces and even specific Stable Coins.\ \ Rational users will aim towards maximizing their expected outcome and yield from participating in the Fluidity ecosystem, this may cause protocols to lose or gain users, revenue. liquidity and network effects as users migrate or react to the yield/ emission changes.\ \ To receive yield using Fluid Assets, actions need to be taken such as swaps, trades, transfers, purchases, hence as users migrate, so does revenue and liquidity, as a second order effect. Theoretically users will concentrate their activity in the higher yield bearing actions/ protocols, this suggests that potentially revenue and liquidity will also be concentrated as LPs move to capture this change. # Utility Mining A new way to think about token distribution mechanics and liquidity mining {% hint style="info" %} Traditional strategies of bootstrapping protocols such as Liquidity Mining are not working as intended. Protocols are paying expensive fees to rent liquidity and receive little to no long-term benefits or stickiness. {% endhint %} Fluidity proposes utilising an adaptation to Liquidity Mining titled Utility Mining, to distribute a significant portion of the Governance Tokens. Although Liquidity Mining will still be utilised, a significant portion of the Fluidity governance tokens will be distributed through Utility Mining.\ \ Utility Mining utilises Fluidity’s Transfer Reward Function, to provide a fairer mechanism for the distribution of governance tokens, incentivising proactive participation in the protocol and broader ecosystem.\ \ Utility Mining rewards users with governance tokens and other incentives such as higher yield when targeted on-chain interactions are taken by a user. For example, using a Fluid Asset. {% hint style="info" %} Other protocols can utilise Utility Mining to distribute their Governance Tokens to end-users and attract new users to their protocols, helping bootstrap themselves. {% endhint %} Fluidity will extend the Transfer Reward Function utility to other protocols that wish to bootstrap users by rewarding them through the TRF mechanism. In essence, through this program when a user uses a Fluid Asset on another protocol, they may also get exposure to additional yield in that protocol's native governance token. We believe that this will allow protocols to bootstrap themselves, by rewarding and attracting new and engaged users, instead of passive liquidity farmers. **For example:** Dex A decides to distribute a portion of their tokens ($DEX), through utility mining. This may incentivise rational users of for example Dex B to use Dex A for a period of time to maximise their yield. A user using Dex A will potentially be able to get exposure to: * Yield distributed in the in-kind currency example: (ƒUSDC) * Yield distributed in Fluidity Governance tokens ($FLUID) * Yield distributed in DEX A tokens ($DEX) However, to claim this yield the user has to learn and understand how to use Dex A and be actively engaged in deriving utility out of Dex A. The user may also be paying revenue to Dex A for the services provided. Once the rewards are reduced, the user may remain as a long term user of Dex A, as they were able to derive value out Dex A and potentially keep using it for its value proposition. # For arbitrage # Understanding the $FLY Governance Token Governance is the core of the Fluidity Ecosystem as it provides guidance and structure on determining the size and frequency of payouts, the sources of yield and the token distribution policies. The governance token also entitles the holders to have increased expected outcome overtime of receiving larger dividends when utilising their Fluid Assets The $FLY Governance token serves multiple purposes including: * Utility Mining. * Bootstrapping and Rewarding Protocols. * Receiving Higher Expected Outcomes * Utility as a Service. * Changing Protocol Parameters. * Staking in Fluidity Vaults {% content-ref url="/pages/t3IEyeePOLNSCyMpAIjY" %} [Fluidity $FLY Vaults](/docs/fundamentals/understanding-the-usdfluid-governance-token/fluidity-usdfly-vaults) {% endcontent-ref %} {% content-ref url="/pages/QPmIawbG5CY4uMxw8pfx" %} [Understanding $FLY Tokenomics](/docs/fundamentals/understanding-the-usdfluid-governance-token/understanding-usdfluid-tokenomics) {% endcontent-ref %} The FLY token will act as a governance token allowing for direct vote casting powers, allowing users to select protocols or behaviours that will result in an increased expected outcome. This will also allow for users to discover new merchants and be incentivised to participate in retail payments. This is important as it will allow for a symbiotic relationship where protocols are able to receive revenue and utility, and users have an incentive to participate as intended. These types of incentives can be used in different use cases, increasing user retention as well as bootstrapping new protocols. High-value Merchants or DAOs can potentially receive higher expected outcomes of winning and better incentives over time when participating in the Fluidity ecosystem. We can go to broader categories, we have a list of the top smart contracts, and we give yield to the users interfacing with those, including specific DAOs or use cases. {% hint style="info" %} The Fluidity Governance token allows the protocol to pay higher yields for specifications or use cases.\ \ This is significant as this can cause liquidity, revenue, and users to be transferred between protocols in the wider crypto space.\ \ An example decision can be: Fluid Assets pay 2x higher yield if you use them on Dex A vs Dex B. This may potentially cause users of Dex B to switch to Dex A. {% endhint %} Protocols can also create incentive pools to pay out their governance token to Fluid Asset users in order to bootstrap themselves. For example: From a Fluidity user's point of view, Missions are a great way to look at it, however, we would be taking a very generalist approach to it. A protocol would be creating a pool that once you interact with this contract you will be able to obtain the reward from that pool. Swap/Transfer/Deposit, once you call a method from these you are able to be rewarded. In this scenario, a Fluidity user does not need to do anything special, to get exposure to this yield. As a user uses their fluid assets. We aren’t asking people to change their habits, and they do not even need to know this program exists and they earn more yield. # Fluidity $FLY Vaults On the $FLY token launch, outside of being able to steer orderflow and participate in the 'Fluidity Wars' (Think Curve Wars, but for orderflow and volume rather than liquidity), we plan on launching $FLY Vaults. Some of the benefits include: * Multipliers and rewards in upcoming airdrop epoch campaigns * $ARB and Utility mining rewards from participating partners and protocols. * \[REDACTED] in [Superposition (SPN)](https://superposition.so) * Staking points (cumulative point system). # Understanding $FLY Tokenomics The total supply of Fluid Governance tokens is 1,000,000,000 FLY tokens, which will be fully circulating no earlier than 4 years post Token Generation Event (TGE.) You can learn about how we distributed the tokens on our [Economics Whitepaper](https://whitepapers.fluidity.money/fluidity-economics-wp-v1.0.pdf). The objective of the governance token distribution is to maximise diversification amongst genuine users while incentivising positive value creation within the ecosystem. The development of the protocol must be funded and incentives need to be provided to stimulate long-term growth. Much of the funding required to build and grow the protocol, is received and given to a centralised and small number of entities. If these entities have the majority of the circulating supply of governance tokens, they may be able to vote on governance decisions that are favourable to their outcomes over the best interests of the wider ecosystem. Fluidity will minimise and control for this bad behaviour by distributing the majority of the float within the community using its novel Transfer Reward Function distribution. # Launch restrictions (mint limits) | Date | User mintable per Fluid Asset | Global mintable per Fluid Asset | | ---- | ----------------------------- | ------------------------------- | | | 10k | 1m | | | 10k | 1m | | | 10k | 1m | | | 15k | 1.5m | | | 20k | 2m | | | 25k | 2.5m | | | 30k | 3m | | | 35k | 3.5m | | | 40k | 4m | | | 45k | 4.5m | | | 50k | 5m | | | 55k | 5.5m | | | 60k | 6m | | | 65k | 6.5m | | | 70k | 7m | | | 75k | 7.5m | | | 80k | 8m | | | 85k | 8.5m | | | 90k | 9m | | | 95k | 9.5m | | | 100k | 10m | # Governance structure Fluidity is governed by a pair of multisigs: * The **community multisig** (the operator) - a 4/6 multisig operated by [members of the advisory team](/docs/fundamentals/advisory-team) and well-respected members of the community at large * The **emergency multisig** (the emergency council) - a 2/6 multisig operated by the same members of the advisory team These multisigs protect the community and the protocol. ### Multisig powers | Community multisig | Emergency multisig | | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | |
  • Can enable emergency mode (can freeze swap-ins, prevent payouts and allow transfers and swap outs)
|
  • Can enable emergency mode (can freeze swap-ins, prevent payouts and allow transfers and swap outs)
| |
  • Can upgrade the contract/program
| | |
  • Can adjust and release minting limits
| | |
  • Can unblock large payouts
| | |
  • Can change the worker operator key once a month
| | ### Ethereum mainnet multisig #### Community {% embed url="" %} Community multisig {% endembed %} | Owner name/pseudonym | Address/ENS | | ---------------------------------------- | ------------------------------------------ | | Shahmeer Chaudhry, Fluidity (shahmeerch) | 0xF8bd8362eDFf4a9D4F11e1727eca40AfA6026901 | | Bayge, Fluidity | bayge.eth | | Daniel T, Verilog | 0x1763b71D0c12DD4Ad51cEf56C16Cd19C436C5c71 | | ZachXBT | | #### Emergency {% embed url="" %} Emergency multisig {% endembed %} | Owner name/pseudonym | Address/ENS | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Shahmeer Chaudhry, Fluidity (shahmeerch) | 0xd86f18bEB63574C2169f6fD8Aa0C6235A6FC4c8E | | Bayge, Fluidity | 0xdcbcc6773aaf289a880037cbaffc316d4f1c96a4 | | Daniel T, Verilog | 0xddbd06a518627286a05822ef103ba57058650ae9 | | ZachXBT | | | Fluidity team | 0x3099705e1F53419A2233dFE78F3B04bDBD234dD9,0x3099705e1F53419A2233dFE78F3B04bDBD234dD9,0x63a5B6497F01BB876EA3a343Ec8991252aABAEaF,0x8Cb300ebb3028c15AB69c3E9CDFf1bE60aAa43a2,0x9735Ab34d1c822E81c56c904C99Dd473aaD7431F,imbrium.eth | (in progress) ### Arbitrum mainnet #### Community {% embed url="" %} Arbitrum mainnet community multisig {% endembed %} | Owner name/pseudonym | Address/ENS | | --------------------------- | ----------- | | Shahmeer Chaudhry, Fluidity | | | Bayge, Fluidity | bayge.eth | | Daniel T, Verilog | | | ZachXBT | | #### Emergency {% embed url="" %} Arbitrum mainnet emergency multisig {% endembed %} | Owner name/pseudonym | Address/ENS | | --------------------------- | ----------- | | Shahmeer Chaudhry, Fluidity | | | Bayge, Fluidity | | | Daniel T, Verilog | | | ZachXBT | | # Advisory team * ZachXBT * DCFGod * MrBlock * Eden (from The Block) * Igor (from The Block) * Big D Senpai * Ivan (LobsterDAO & Gearbox) # 👩🏫 Laws of Fluidity Fluidity is built with three hard constraints: ### Instant rewards Rewards should be relatively instant. Users love a responsive application that doesn't take time to reward them for using it. ### No extra fees In some cases, Fluid Assets are **cheaper than other standard ERC20 tokens** to transact. This feeds into the Fluidity objective of **financial inclusion** and that blockchain technology is not exclusively for the wealthy to use. ### No special software Users and protocols win rewards for using Fluid Assets without any special software. You are free to use what you want to transact Fluid Assets, with no restrictions. # Roadmap # Product roadmap ### Road to Mainnet and Current state of the product: Given the successful testnet and devnet deployments as well as the massive community support, feedback, and engagement, Fluidity has been able to collect sufficient data and experience in order to be able to confidently strive forwards towards mainnet. Fluidity's mainnet will launch on Ethereum, with other chains followed right after in order to allow for testing and contingency plans to be enacted upon given any emergency situation that occurs. ## Where We Are Going **Now it’s time to become the ultimate platform for protocols, developers, creators, and millions of users.** To reach these ambitious goals, **we are** **building a chain-agnostic incentive layer.** **Key Points:** 1. Fluidity Mainnet Launch: A New Primitive to incentivise utility and participation :white\_check\_mark: 2. Fluidity DAO 1. DAO Framework :white\_check\_mark: 2. Fluid Token :eyes: 3. Utility Mining & Fluidity Wars 1. Utility Mining and Special UM :white\_check\_mark: 2. Utility Gauges :white\_check\_mark: 3. Governance and protocol/user participation 🚧🛠️ 4. The Incentive Layer: Fluidity as a chain agnostic incentive middle layer 1. Ethereum 🌅 2. Arbitrum :white\_check\_mark: 3. Solana :white\_check\_mark: 4. Sui 🚧🛠️ 5. ???? :eyes: 5. Fluidity $FLY Vaults 6. Security and Decentralisation 1. Randomness 🚧🛠️ 2. System Architecture 🚧🛠️ 7. Ambassador program and Fluidity Ecosystem Fund :eyes: 8. Web2 - Web3 and retail: Bridging adoption 9. (🌊 ,💸 ) Join The Movement # Decentralisation roadmap (WIP) 🚧🛠️ 1. Fluidity worker/contract architecture - centralised, little trust in the randomness generation <- **we are here** 2. Distributed worker/contract architecture - publicly sourced randomness from a multiparty computation with leader election, competition with batching powered by members of the community 3. 100% decentralised architecture including randomness generation, zero dependency on Fluidity services We're at **stage 1**. We built the second stage of the architecture in the past using Merkle Proofs mixed with randomness sourced off-chain (random.org), including signature verification and a suite of protections to prevent abuse that happen entirely on-chain. We found in practice that bar building an off-chain platform (sidechain?) it was too unreliable given the [Laws of Fluidity constraint 1](/docs/fundamentals/laws-of-fluidity#instant-rewards): instant rewards. We found that a fork would significantly degrade the user experience overall. We found that Solana lacks cryptographic primitives well understood by our team (and the community at large following discussions in some cases) to build trustworthiness into the platform without validating the product. Fluidity takes steps to ensure we properly maintain the systems by [engaging trustworthy members of the community at large](/docs/fundamentals/advisory-team) to "peer behind the curtain" and to quarantine large rewards until the second stage is built. **Stage 2** is possible to build with a relaxation of the instant rewards law, with hyper efficient markets, with an off-chain platform and with something in between. It's also possible to build with RANDAO and the beacon chain. We found that an on-chain approach to randomness violates the [second law of Fluidity](/docs/fundamentals/laws-of-fluidity#no-extra-fees): no extra fees. With the randomness generated by the beacon chain being accessible from userspace, we can generate randomness entirely on-chain including the leader election. When Fluidity was started and we begun experimenting with approaches, the timing of the merge was unknown and historically RANDAO has been shown to be biasable - given the number that could be possibly won in one foul sweep we didn't eliminate the possibility that an attacker would understand one stage of the VDF enough to attack the second. A natural suggestion would be to use a service provided by Chainlink (an oracle or a VRF) but we found with the latter we would violate the [first law of Fluidity: instant rewards.](/docs/fundamentals/laws-of-fluidity#instant-rewards) We didn't investigate the former. The problem with a large fixed number that could be won instantaneously means there's a way to estimate within a margin of error the amount that would be needed to drain the amount instantly. So there's a large incentive to "move the needle" in markets with leveraged positions then close them out following draining the prize pool. **Stage 3** is possible to build following solving some of the randomness challenges and the development of the token and incentive program overall. The three laws make this system a challenge, but by relaxing the instant reward constraint in attacker-led scenarios and matching large payouts with a market (a la Boba) it can be done. We can guarantee liveliness with the token and the staking incentive system and generate the graph needed for the longterm infrastructure including the sell-down of accumulated randomness. There are other considerations in our decentralisation roadmap including: 1. IPFS hosting everything We've since spent some time ideating these in a pair of whitepapers which explores these further:[Whitepapers](/docs/developers/whitepaper-source-code) Stay tuned to this page and look forward to an announcement. # Why instant rewards? # Use-cases {% content-ref url="/pages/0JeyiP5n2JNp4BlTkrfE" %} [Developers](/docs/use-cases/developers) {% endcontent-ref %} {% content-ref url="/pages/WCkAKa47wfPqNQGnO6rL" %} [DEXs](/docs/use-cases/dexs) {% endcontent-ref %} {% content-ref url="/pages/osPTiEibLR0n1nv4TN0F" %} [Fluid Assets and Utility](/docs/use-cases/fluid-assets-and-utility) {% endcontent-ref %} {% content-ref url="/pages/XqppnZGGzMQ4Ha8K5X4s" %} [Metaverse and Gaming](/docs/use-cases/metaverse-and-gaming) {% endcontent-ref %} {% content-ref url="/pages/SWaeIPajM04AvmkteMM9" %} [NFTs](/docs/use-cases/nfts) {% endcontent-ref %} {% content-ref url="/pages/p9Njyzz9IhDvBqYOM7Ho" %} [Transactions and Payments](/docs/use-cases/transactions-and-payments) {% endcontent-ref %} {% content-ref url="/pages/0iJvVAw1o0nAZoikB5jV" %} [Other Use-Cases](/docs/use-cases/other-use-cases) {% endcontent-ref %} # Developers dApp developers don't necessarily have to charge a fee for it to be used. Their focus is now on increasing engagement rather than revenue modeling through high transaction costs or gimmicks that would limit users to experience the Dapp. As users use a dapp and transact within it through the use of fluid assets, a portion of the prices could go to the dev's wallet. In that instance the Dev is a partial receiver of a, say item trade, where the two parties conducting the trade earn 35% each of the reward, fluidity earns 10%, and the developer 20% (as an example). Let's say 10k daily users, you are gaining quite a bit of money, you aren't charging your users anything extra. In fact, you could remove fees in total which would generate high transaction volume, seeing more potential reward distribution being gained by that developer. # DEXs From a fundamental perspective, trading, transaction, and asset movement are activities that are integral within decentralised programs and their applications. **Let’s look at an example:** Imagine there is a new DEX, and they need users. Liquidity mining program and have a lot of liquidity, they have a lot of attention to their LPs but this is not equal to a lot of users and actual use. Through the use of Fluidity’, users would need to interact with the protocol to earn yield. Hence when users do swaps and trades through Fluid Assets they are earning yield. # Fluid Assets and Utility Fluid assets are quite composable in nature and as a result, are able to promote both user and platform engagement through their reward distribution mechanisms as well as allow for developers to customise and compose how and when these rewards are distributed. Fluidity increases the utility of assets in the broader ecosystem. By the creation of Fluid Assets, users are now incentivised to utilise their principal rather than holding it idle. By adding modifications to Fluidity’s TRF, Fluidity can incentivise participation in value-add use-cases. When a user uses Fluidity, roughly 70-80% of transactions will be yield-bearing, between several cents to potentially millions. The yield is also distributed to both the sending and receiving parties. Over time, especially if an entity such as a merchant is receiving high inbound volume, they will gain significant yield passively as a consequence of accepting Fluid Assets. {% hint style="info" %} It cannot be stressed enough that the examples provided are not the only possible applications and integrations for Fluidity and fluid assets. These are only possible examples that allow for a greater overview of where the use of Fluidity might be appropriate. In the future, any use case of value transfer on the chain can be incentivised and rewarded through Fluidity and Fluid assets. {% endhint %} ### **All forms of value transfer can now be incentivised.** Incentives are of extreme importance when designing systems with humans for continual integral usage. Use cases include marketplaces, decentralised exchanges, and any use-case where tokens are being transacted on-chain. Utility Mining creates an incentive for users to participate in these very use-cases and aligns the communities with genuine participation within the protocol. As seen in the previous following, incentives are of extreme importance in our system design. Customers and merchants are both able to be incentivised to transact through the use of Fluid assets. ### Fluidity is realigning incentives by rewarding utility and usage. We have created a general all-purpose incentive mechanism that basically anyone can utilize in any on-chain use case that can incentivise actions. It is a system that is able to be embedded into different things very easily. # Metaverse and Gaming Even though initally it may seem Fluidity is a financial system, Metaverse-based applications can benefit significantly from Fluid assets. Each metaverse needs to have its own method or a shared method of value transfer. These separate metaverses are their own universes, a parallel to the real world, they follow the exact same mechanics however as they have the same agents. You can replicate the same models, however, by turning the base model into a fluid token. People buy items, trade them, purchase subscriptions, sign up and participate in events, etc. Each of these transactions could have its use cases enhanced through Fluidity. The idea is that this goes further than just payments. {% tabs %} {% tab title="🌐 Metaverse Economy" %} #### Purchase of land or items: You are now in a sandbox environment with how an entire economy would look through Fluid assets, and you don’t need government intervention. If users want to utilise, we will see that instead of speculation happening through land hoarding, we will see the value exchange because of the way that we can earn yield. As a result, instead of the way of what we are currently seeing bots and agents hoarding assets, we will see them transacting. This is because the CURRENT incentive is to **Stake and Speculate.** *** ***Fluidity introduces a new incentive structure that promotes liquid utility and the transfer of assets.*** *\*\*\*\** The novel part of experimenting with games is that you can potentially build the first economies that are utilising Fluids Assets as a basis of value transfer. Economies of scale will pop up that may be utilising this as a value transfer. ***"Money works for me"***, as people say, will become a reality and at a point, people will expect their economics to work this way. {% endtab %} {% tab title="👾 Gaming and Earning" %} Through the introduction of gaming in Ethereum came the ‘Play to Earn’ games such as Axie Infinity, allowing players, particularly those in third world countries, to earn their incomes through playing said games!\\ *** If we want a more sustainable model, paying to earn through Fluidity would be more sustainable. **Our payout is sustainable and will be better adapted for this use case.** *** **Fluidity can be utilised as a way to enhance pay to earn platforms.** *** The people that are playing these games for the pay-to-earn transfer would be making these transactions even if we weren’t there, so our presence is more of a value add and incentive that could even be making minimal recurring contributions such as paying for their fees.\\ Fluidity then allows for **Enhanced Earning:** Enhancing earnings of people to make a living, without deviating from their habits. {% endtab %} {% endtabs %} # NFTs NFT marketplaces facilitate significant value transfer and commerce. Fluidity can provide an incentive to purchase or sell NFTs, by rewarding yield when users pay or sell for Fluid Assets. Both parties receive yield, including the marketplace, causing positive feedback loops and incentives for all parties in a transaction to utilise Fluid Assets. Even fractionalisation and interacting with NFTs in different protocols can generate a yield generating event, allowing for users to more fluidly transact and trade their assets accordingly. # Transactions and Payments Cashback programs and incentives have always been a consumer-facing affair. It is unusual to have merchants being rewarded and gaining yield through transactions made by their clients. Through accepting Fluid assets as payments, merchants are able to earn yield and rewards, **as the reward obtained from Fluid Assets is split between sender and receiver.** Every purchase made using Fluid Assets Potentially benefits the store as well as the consumer. There is then a positive feedback loop as both customers and merchants are incentivised to participate and use the system. ### **Customer side example:** A customer (Jeremy) performs his usual grocery shopping in a supermarket that accepts cryptocurrency. His bills come up to 100$ and he chooses to pay by using ƒUSDC (a Fluid wrapped version of the USDC token). As soon as the payment goes through, they receive a notification with an ‘Airdrop’ of 10,000$. Not only have they paid their bills, but they have now earned 100x the amount paid! ### **Merchant Side example:** A small convenience store is trendy and allows its customers to pay through cryptocurrency. They promote fluid assets by providing a discount per purchase! Jeremy comes in and performs his usual shopping. After Jeremy pays, the cashier sees that an ‘Airdrop’ has taken place! Not only has the money been deposited by Jeremy, but the store wallet has received an additional 100$! *** # Other Use-Cases There may be use cases that may not be evident on how Fluidity may be utilised in conjunction with, we can allow developers to define custom triggers and behaviours that would allow their systems to be compatible with Fluidity. ***Superfluid*** would be one such example: {% hint style="info" %} Currently, this is purely an example. {% endhint %} ### Superfluid: * Payment stream * Custom API/Tools/Interfaces in tandem with Fluidity. A superfluid can actually define the trigger event for payouts. For instance: superfluid focuses on streaming payments which makes it non-trivial to decide when to trigger a potential payout, we can allow the Super Fluid team to define this such asL * The trigger of payout is when the funds are withdrawn. (ie. the stream is complete). * We call the trigger mechanism for the payout when x % of the stream is done. Even though the way they work is quite different from Fluidity, we can make them work together through these custom-defined triggers. We can allow developers to define the trigger points and the rules to how fluidity would work with their use case, within the context of their system. Such as in games or other platforms like b2b applications or storage use cases. They have the tools to create the payment mechanism whenever they want but we are not fundamentally changing the way our system behaves, hence putting them in control of when a payout occurs. # Developers ### **Introduction** Fluid Assets (Fluid-wrapped tokens) are [ERC20](https://eips.ethereum.org/EIPS/eip-20)-compatible on Ethereum and [`SPL-token`](https://spl.solana.com/token) tokens on Solana. Ethereum the following lending protocols are supported: * [Compound](https://compound.finance) * [AAVE](https://aave.com/) On Solana: * [Solend](https://solend.fi/) Fluid Assets support the following additional features: * Swapping in * Swapping out {% content-ref url="/pages/nmKl1K0NXz2USHdZI3z4" %} [Addresses](/docs/addresses) {% endcontent-ref %} # Architecture Fluidity is a mostly off-chain technology that: * Determines winners according to the TRF with all data available * Aggregates transfers made * Calculates future probabilities of winning with regards to past data * Decodes interactions with protocols and applications for fee structure reasons * Receives its constraints using on-chain DAO (:wink:) Events produced on-chain are aggregated into winners below a threshold while rewarding massive winners instantly. A redemption feature is built into the webapp that lets users instantly redeem small prizes. {% content-ref url="/pages/ElG7w74pUyuNfqzEVUSX" %} [Worker architecture](/docs/developers/fluidity-architecture/worker-architecture) {% endcontent-ref %} {% content-ref url="/pages/9YOppajdCrBwrs15dmFw" %} [Ethereum contract architecture](/docs/developers/fluidity-architecture/ethereum-contract-architecture) {% endcontent-ref %} {% content-ref url="/pages/P3o8vFNOEQqE0720asBl" %} [Solana program architecture](/docs/developers/fluidity-architecture/solana-program-architecture) {% endcontent-ref %} # Worker architecture The two currently supported platforms (Ethereum and Solana) follow a similar process: 1. Application server becomes aware of a block/slot 2. Application server classifies Fluid Asset interactions in the block/slot as either * a standard Fluid Asset transfer * an application transaction utilising a Fluid Asset (e.g. a swap on Uniswap, Saber use) 3. For application transactions, the Application server decodes the interaction and attaches a decorated structure containing information such as its associated fees 4. Application server sends all Fluid Asset interactions to the Worker Server 5. Worker computes the current state of the TRF using every available variable (fees paid for each application used, past state history, averages if there are any) and sends it to the Worker client queue 6. Worker optionally computes more variables after fetching data (this system is disintermediated since some upstream dependencies are unreliable and can dilute the calculation in the previous stage) 7. Worker either sends the transaction depending on the backend (Solana) or sends it to the final stage which aggregates the batched payouts (Ethereum) # Ethereum contract architecture Ethereum support is built as a trio of contracts: 1. Token - the token for the wrapped asset being traded/transferred, supporting swapping in, swapping out, ERC20 features 2. WorkerConfig - configuration for each token 3. LiquidityProvider - abstract wrapper that holds custody of ctokens/atokens

Ethereum high level

### Features in pseudocode form #### Wrapping in/swapping in (erc20In) 1. Token takes the user's unwrapped tokens and moves it into the contract 2. Token sends the unwrapped tokens to the LiquidityProvider 3. LiquidityProvider provides it to the underlying liquidity provider (Compound or AAVE) 4. Underlying liquidity provider (Compound/AAVE) mints cToken/aToken with the amount given 5. LiquidityProvider receives cToken/aToken adjusted to the "exchange rate" of the cToken/aToken (unwrapped token/exchange rate) 6. Token sends the user an amount equal to the initial unwrapped token of the Fluid Asset form using the mint function #### Wrapping out/swapping out (erc20Out) 1. Token burns the minted amount owed to the user wrapping out of the contract 2. Underlying LiquidityProvider "redeems" the amount of token that the user wishes to unwrap - the underlying redemption process (Compound/AAVE) calculates the amount owed using the amount of the cToken/aToken - on Compound this is cToken \* exchange rate 3. The LiquidityProvider sends the Token the amount redeemed 4. The Token sends the user their unwrapped asset after redemption #### Batch reward process (batchReward) 1. Worker sends to the Token a batch of winners and the span of blocks that was won 2. Token aggregates the amounts that should be paid out to each winner 3. Token aggregates the remaining pool amount 4. Token rewards each user with the internal reward function `rewardPool` #### Reward pool amount calculation (rewardPool) 1. LiquidityProvider calculates the balance of the underlying assets based on the exchange rate of the cTokens/aTokens held in the Compound/AAVE pool 2. Token calculates the difference between the amount deposited by users with the amount reported by the LiquidityProvider for the prize pool amount 3. Token calls the reward from pool function (`rewardFromPool`) - which simply calls the mint function and emits a log # Solana program architecture Solana is built as a program that derives new accounts for its supported tokens.

Solana architecture simplified

Each account's layout can be read at [Solana account structure](/docs/developers/solana-account-structure). The program supports the following instructions: ```rust // wrap fluid token Wrap(u64, String, u8), // unwrap fluid token Unwrap(u64, String, u8), // payout two accounts Payout(u64, String, u8), // initialise solend obligation account InitSolendObligation(u64, u64, String, u8), LogTVL, // initialise the data account for this token InitData(String, u64, u64, u8, u64, u64), // move from prize pool to account MoveFromPrizePool(u64, String, u8), // update mint limit to an amount UpdateMintLimit(u64, String), // update the payout restriction limit UpdatePayoutLimit(u64, String), // update the payout authortity (the rng oracle) UpdatePayoutAuthority(String), // update the operator (the multisig) UpdateOperator(String), // confirm the payout authority in the two step replacement process ConfirmUpdatePayoutAuthority(String), // trigger emergency mode Emergency(String) ``` ### Features in pseudocode form #### Wrapping in (Wrap) 1. Using Solend, the program deposits the user's given amount as liquidity 2. The program determines the collateral account from Solend 3. The program stores the collateral in the obligation account for the token 4. Using the SPL token, user tokens are minted proportionate to the amount deposited #### Wrapping out (Unwrap) 1. Contract burns the user's SPL tokens 2. Refreshes the Solend reserve 3. Calculates the Solend collateral amount in the obligation account 4. Withdraws from Solend to the user's token account # EVM ABIs The following ABIs can be compiled in the [repository](https://github.com/fluidity-money/fluidity-app/) (using `make build`.) ### Token {% embed url="" %} Source code {% endembed %} The Token is an ERC20-compatible contract featuring swap-in (`erc20In`) and swap-out (`erc20Out`) . ### LiquidityProvider {% embed url="" %} Source code {% endembed %} Interface that contains liquidity tokens to redeem for the underlying based on the implementation. ### AAVE v2 LiquidityProvider {% embed url="" %} Source code {% endembed %} LiquidityProvider frontend for AAVE. ### AAVE v3 LiquidityProvider {% embed url="" %} Source code {% endembed %} LiquidityProvider frontend for AAVE, this time for version 3. ### Compound LiquidityProvider {% embed url="" %} LiquidityProvider frontend for Compound. ### Worker config {% embed url="" %} Source code {% endembed %} The worker config is a single contract deployed which is referred to by the various deployed Tokens to get information on the RNG oracle and global emergency status. # Solana account structure The following structures are literally copied from the contract source code: ```rust pub struct LendingMarket { /// Version of lending market pub version: u8, /// Bump seed for derived authority address pub bump_seed: u8, /// Owner authority which can add new reserves pub owner: Pubkey, /// Currency market prices are quoted in /// e.g. "USD" null padded (`*b"USD\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"`) or a SPL token mint pubkey pub quote_currency: [u8; 32], /// Token program id pub token_program_id: Pubkey, /// Oracle (Pyth) program id pub oracle_program_id: Pubkey, /// Oracle (Switchboard) program id pub switchboard_oracle_program_id: Pubkey, } ``` ```rust pub struct Obligation { /// Version of the struct pub version: u8, /// Last update to collateral, liquidity, or their market values pub last_update: LastUpdate, /// Lending market address pub lending_market: Pubkey, /// Owner authority which can borrow liquidity pub owner: Pubkey, /// Deposited collateral for the obligation, unique by deposit reserve address pub deposits: Vec, /// Borrowed liquidity for the obligation, unique by borrow reserve address pub borrows: Vec, /// Market value of deposits pub deposited_value: Decimal, /// Market value of borrows pub borrowed_value: Decimal, /// The maximum borrow value at the weighted average loan to value ratio pub allowed_borrow_value: Decimal, /// The dangerous borrow value at the weighted average liquidation threshold pub unhealthy_borrow_value: Decimal, } ``` ```rust pub struct Reserve { /// Version of the struct pub version: u8, /// Last slot when supply and rates updated pub last_update: LastUpdate, /// Lending market address pub lending_market: Pubkey, /// Reserve liquidity pub liquidity: ReserveLiquidity, /// Reserve collateral pub collateral: ReserveCollateral, /// Reserve configuration values pub config: ReserveConfig, } ``` ```rust pub struct ReserveLiquidity { /// Reserve liquidity mint address pub mint_pubkey: Pubkey, /// Reserve liquidity mint decimals pub mint_decimals: u8, /// Reserve liquidity supply address pub supply_pubkey: Pubkey, /// Reserve liquidity pyth oracle account pub pyth_oracle_pubkey: Pubkey, /// Reserve liquidity switchboard oracle account pub switchboard_oracle_pubkey: Pubkey, /// Reserve liquidity available pub available_amount: u64, /// Reserve liquidity borrowed pub borrowed_amount_wads: Decimal, /// Reserve liquidity cumulative borrow rate pub cumulative_borrow_rate_wads: Decimal, /// Reserve liquidity market price in quote currency pub market_price: Decimal, } ``` ```rust pub struct FluidityData { token_mint: Pubkey, fluid_mint: Pubkey, pda: Pubkey, payout_authority: Pubkey, // can turn on emergency mode, reward users, update mint limits operator: Pubkey, // can turn on emergency mode, unblock rewards, update payout limits, change // the payout auth emergency_council: Pubkey, // can turn on emergency mode pending_payout_authority: Option, // wrapping and payouts no_emergency: bool, block_payout_threshold: u64, global_mint_remaining: u64, } ``` # How can I Fluid Wrap my custom token? Want to wrap assets that aren't currently supported? At this stage, reach out via this form: {% embed url="" %} Fluid Asset onboarding questionnaire {% endembed %} # GraphQL Fluidity exposes a rich GraphQL on its webapp and landing page. The endpoint is here: # Dev Tutorials # Creating a New Utility Mining Client 1. Deploy a contract implementing the interface `IFluidClient`. Essentially the client must implement `batchReward()` and `getUtilityVars()`, with the former emitting the event `Reward` for each reward paid out and the latter returning your desired utility variables. 2. Update the registry by calling `updateUtilityClients` in `Registry.sol`. This requires the above client, an address for the relevant token, and a name for the client. This call must be made by the operator, which is currently a centralised entity, with plans in the works to decentralise this responsibility to the DAO. 3. Update the automation used by the offchain worker. Namely, update `ENV_FLU_ETHEREUM_UTILITY_CONTRACTS` in the application server for the given network (`automation//application-server/mainnet.yml`) to include the client name and address as set in the previous step. In the worker server and spooler automation (`automation//worker-server/mainnet.yml` and `automation//worker-spooler/mainnet.yml` respectively), update `ENV_FLU_ETHEREUM_UTILITY_TOKEN_DETAILS` to include the client name, token name, and token decimals. For example, adding Wombat: ```diff diff --git a/automation/arbitrum/application-server/mainnet.yml b/automation/arbitrum/application-server/mainnet.yml --- a/automation/arbitrum/application-server/mainnet.yml +++ b/automation/arbitrum/application-server/mainnet.yml @@ -1,8 +1,8 @@ DOCKER_IMAGE: microservice-arbitrum-application-server DOCKERFILE_PATH: ./cmd/microservice-ethereum-application-server -ENV_FLU_ETHEREUM_UTILITY_CONTRACTS: 'chronos initial boost:0x0176416bdc885b1bb751b0a014d495760a972a73:0x62030690385A481Ab0c6039fEA75AC6658B7b961' +ENV_FLU_ETHEREUM_UTILITY_CONTRACTS: 'chronos initial boost:0x0176416bdc885b1bb751b0a014d495760a972a73:0x62030690385A481Ab0c6039fEA75AC6658B7b961,wombat initial boost:0x956454c7be9318863297309183c79b793d370401' diff --git a/automation/arbitrum/worker-server/mainnet.yml b/automation/arbitrum/worker-server/mainnet.yml --- a/automation/arbitrum/worker-server/mainnet.yml +++ b/automation/arbitrum/worker-server/mainnet.yml @@ -10,7 +10,7 @@ SERVICES: SERVICE_NAME: microservice-arbitrum-worker-server-usdt ENV_FLU_WORKER_ID: arbitrum-microservice-arbitrum-worker-server-usdt ENV_FLU_ETHEREUM_CONTRACT_ADDR: "0xc9fa90d24b7103ad2215de52afec5e1e4c7a6e62" - ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:USDT:6,chronos initial boost:USDC:6" + ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:USDT:6,wombat initial boost:WOM:18,chronos initial boost:USDC:6" ENV_FLU_ETHEREUM_AMQP_QUEUE_NAME: arbitrum.worker.usdt ENV_FLU_ETHEREUM_WORK_QUEUE: worker.arbitrum.server.work.usdt @@ -18,7 +18,7 @@ SERVICES: SERVICE_NAME: microservice-arbitrum-worker-server-usdc ENV_FLU_WORKER_ID: arbitrum-microservice-arbitrum-worker-server-usdc ENV_FLU_ETHEREUM_CONTRACT_ADDR: "0x4cfa50b7ce747e2d61724fcac57f24b748ff2b2a" - ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:USDC:6,chronos initial boost:USDC:6" + ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:USDC:6,wombat initial boost:WOM:18,chronos initial boost:USDC:6" ENV_FLU_ETHEREUM_AMQP_QUEUE_NAME: arbitrum.worker.usdc ENV_FLU_ETHEREUM_WORK_QUEUE: worker.arbitrum.server.work.usdc @@ -26,6 +26,6 @@ SERVICES: SERVICE_NAME: microservice-arbitrum-worker-server-dai ENV_FLU_WORKER_ID: arbitrum-microservice-arbitrum-worker-server-dai ENV_FLU_ETHEREUM_CONTRACT_ADDR: "0x1b40e7812e75d02eef97e4399c33865d2ff5952b" - ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:DAI:18,chronos initial boost:USDC:6" + ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:DAI:18,wombat initial boost:WOM:18,chronos initial boost:USDC:6" ENV_FLU_ETHEREUM_AMQP_QUEUE_NAME: arbitrum.worker.dai ENV_FLU_ETHEREUM_WORK_QUEUE: worker.arbitrum.server.work.dai diff --git a/automation/arbitrum/worker-spooler/mainnet.yml b/automation/arbitrum/worker-spooler/mainnet.yml --- a/automation/arbitrum/worker-spooler/mainnet.yml +++ b/automation/arbitrum/worker-spooler/mainnet.yml @@ -11,18 +11,18 @@ SERVICES: ENV_FLU_WORKER_ID: arbitrum-microservice-arbitrum-worker-spooler-usdc ENV_FLU_ETHEREUM_WINNERS_AMQP_QUEUE_NAME: arbitrum.winners.usdc ENV_FLU_ETHEREUM_BATCHED_WINNERS_AMQP_QUEUE_NAME: arbitrum.winners.batched.usdc - ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:USDC:6,chronos initial boost:USDC:6" + ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:USDC:6,wombat initial boost:WOM:18,chronos initial boost:USDC:6" - SPOOLER_USDT: SERVICE_NAME: microservice-arbitrum-worker-spooler-usdt ENV_FLU_WORKER_ID: arbitrum-microservice-arbitrum-worker-spooler-usdt ENV_FLU_ETHEREUM_WINNERS_AMQP_QUEUE_NAME: arbitrum.winners.usdt ENV_FLU_ETHEREUM_BATCHED_WINNERS_AMQP_QUEUE_NAME: arbitrum.winners.batched.usdt - ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:USDT:6,chronos initial boost:USDC:6" + ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:USDT:6,wombat initial boost:WOM:18,chronos initial boost:USDC:6" - SPOOLER_DAI: SERVICE_NAME: microservice-arbitrum-worker-spooler-dai ENV_FLU_WORKER_ID: arbitrum-microservice-arbitrum-worker-spooler-dai ENV_FLU_ETHEREUM_WINNERS_AMQP_QUEUE_NAME: arbitrum.winners.dai ENV_FLU_ETHEREUM_BATCHED_WINNERS_AMQP_QUEUE_NAME: arbitrum.winners.batched.dai - ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:DAI:18,chronos initial boost:USDC:6" + ENV_FLU_ETHERUEM_UTILITY_TOKEN_DETAILS: "FLUID:DAI:18,wombat initial boost:WOM:18,chronos initial boost:USDC:6" ``` 4. Set up an instance of `microservice-ethereum-track-winners` in `automation//track-winners/mainnet.yml`, using the following template: ```yaml - TRACK_WINNERS_: SERVICE_NAME: microservice--track-winners- ENV_FLU_WORKER_ID: -microservice--track-winners- ENV_FLU_ETHEREUM_CONTRACT_ADDR: "contract address of the underlying token" ENV_FLU_ETHEREUM_UNDERLYING_TOKEN_NAME: TOKEN_NAME ENV_FLU_ETHEREUM_UNDERLYING_TOKEN_DECIMALS: 6 ``` # Supporting a New Application Brief overview of integrating fee calculation for a new application * Obtain the address of the Fluid pool(/s) or other Fluid-related contracts for the application. Add to the application server's `mainnet.yml` (e.g. `automation/arbitrum/application-server/mainnet.yml`) in the format described by the application server README.md, i.e. `app_name:addr1,addrn,...` * Determine the event emitted by the pool contract when a application interaction is made. Often this will have a name like "Swap" or "Swapped". Note the log topic of this event, as well as its ABI. * Create the directory `common/ethereum/applications/`, containing `init.go` and `.go`. `init.go` should initialise an ABI object to decode relevant events, and `.go` should contain function(/s) to calculate volume and fees for application events. * Create a function as above that decodes application events and determines their volume and fee amounts. Ensure events are filtered by the contract/fluid token address and log topic. * Update types to include the new application * `common/ethereum/applications/applications.go` enum * Timescale ethereum\_application enum * Worker emissions Timescale type * Worker emissions Go type (`EthereumAppFees` in `lib/types/worker/worker.go`) * Update `GetApplicationFee` in `common/ethereum/applications/applications.go` to return fee data for the new application * Update `GetApplicationTransferParties` in `common/ethereum/applications/applications.go` to return sender/recipient data for the new application * Write an integration test * Add a JSON encoded test to `tests/integrations/ethereum/.go`, then append it to the test suite in `tests/integrations/ethereum/main_test.go` * JSON test includes an encoded transfer, expected values (sender, recipient, fee, volume, emission), and mocked RPC responses for contract calls # Sending and receiving a Fluid Asset # Supporting a Fluid Asset on your DEX/AMM/exchange # Wrapping and unwrapping a Fluid Asset in your app # Providing liquidity for a Fluid Asset # Whitepapers {% embed url="" %} Whitepaper repo {% endembed %} # Security {% content-ref url="/pages/h8XzdAmTm3yyY7i8COVG" %} [Dropboxes](/docs/security/dropboxes) {% endcontent-ref %} {% content-ref url="/pages/T5ZXyKscY0l0sHTUxg8A" %} [Bounty program](/docs/security/bounty-program) {% endcontent-ref %} {% content-ref url="/pages/kfVTNLeZG96fRqA9aFjW" %} [Audits completed](/docs/security/audits-completed) {% endcontent-ref %} # Website/infrastructure security For vulnerability submissions for our web application, services or adjacent infrastructure, we encourage you to reach out to . Alternatively, you can email . If the issue is urgent, please reach out via Telegram @doggish (). Alternatively, you can contact Ivan at @iNash\_ISN (). If THAT doesn't work, you can contact Shahmeer at @shahmeerch (). # Dropboxes {% embed url="" %} Jump dropbox post {% endembed %} The following dropbox addresses are available for whitehats urgently seeking to move funds: | Network | Address | | -------- | ------------------------------------------ | | Ethereum | 0xe0ead43d9266154f777Cb831476be99f6c40B96d | | Arbitrum | 0xfA763219492AE371b35c524655D8972F2D2AF197 | Responsible disclosures are detailed in the [Bounty program](/docs/security/bounty-program). Whitehats utilising the dropbox will be compensated for their fees in doing so additionally to the bounty program. # Bounty program Fluidity ran a successful bounty program with Immunefi. The program is currently not running, but the prize pool was $100,000, and medium vulnerabilities were disclosed that protected the protocol. The program is not currently running, though it's planned to restart in the future. If you identify any vulnerabilties, and you believe the team needs to know immediately, contact a member of the team at [Contactable team](/docs/security/contactable-team). # Audits completed Fluidity has been audited by multiple parties in order to ensure the security of our contracts and our systems. {% embed url="" %} Verilog Solutions audit {% endembed %} {% embed url="" %} Hashlock audit {% endembed %} {% embed url="" %} Bramah Systems audit {% endembed %} # Contactable team ### Alex (CTO) | Contact method | Contact | | -------------- | ------------------------------- | | Telegram | [doggish](https://t.me/doggish) | | Discord | bayge | | Email | | ### Ivan (Head of product) | Contact method | Contact | | -------------- | ------------------------------------ | | Telegram | [iNash\_ISN](https://t.me/iNash_ISN) | | Discord | Ivan | | Email | | # Partnerships/collaboration We're super excited you want to work with us! We request you fill out one of these forms, so we can ensure that your request is met with the right member of the team. {% content-ref url="/pages/D8e55rpzDHmobtyvJzjy" %} [Partnering with us](/docs/partnerships-collaboration/partnering-with-us) {% endcontent-ref %} {% content-ref url="/pages/ortHwZwhgolSKl1D70sK" %} [Join us!](/docs/partnerships-collaboration/work-with-us) {% endcontent-ref %} {% content-ref url="/pages/WKzdWo9A3SN8dvniwwNs" %} [Fluidifying your asset](/docs/partnerships-collaboration/partnerships) {% endcontent-ref %} # Partnering with us {% embed url="" %} # Join us! We're always on the lookout for talented people. If you think you can create value and are excited to work with us, please email us at: jobs @ fluidity.money What we're most interested in from you in these emails is: 1. What makes you interested in Fluidity? 2. How do you see yourself fitting in with what we're building? 3. What's something you see us growing into? 4. What's your favourite technology stack, and how does it relate to what we're building? 5. What's your favourite non-mainstream dapp? Hope to hear from you! Also, please include your resume and a link to your socials (if any.) # Fluidifying your asset {% embed url="" fullWidth="true" %} Drop us a line! {% endembed %} # Brand assets {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} # Useful links {% embed url="" %} Status tracking {% endembed %} {% embed url="" %} Website and whitepapers {% endembed %} {% embed url="" %} {% embed url="" %} Medium {% endembed %} {% embed url="" %} **Telegram** {% endembed %} {% embed url="" %}