LogoLogo
  • ๐ŸŒŠ๐Ÿ’ธ Welcome to Fluidity Money
  • Docs
    • ๐Ÿ“šLearning and getting started
      • ๐Ÿ”ฎWhy Fluidity?
      • โ“What are Fluid Assets?
      • ๐ŸŒŸHow do you get a Fluid Asset?
      • ๐Ÿ’ฐHow are the rewards earned?
      • ๐Ÿ—ƒ๏ธThe Economics of a Fluid Asset
        • โœ๏ธTransfer Reward Function (TRF) Example
      • ๐Ÿ“‹Tutorials
        • How to use Fluidity
    • ๐ŸกAddresses
      • ๐Ÿ…ฐ๏ธArbitrum
      • โ˜€๏ธSolana
      • ๐Ÿ’งSui
      • ๐Ÿ˜ณSuperposition devnet
    • ๐Ÿ” Fundamentals
      • ๐Ÿ“„FAQ
      • ๐Ÿ”ซFluidity Wars
      • โ›๏ธUtility Mining
      • ๐ŸคFor arbitrage
      • ๐Ÿ›๏ธUnderstanding the $FLY Governance Token
        • ๐Ÿ’ธFluidity $FLY Vaults
        • ๐Ÿช™Understanding $FLY Tokenomics
      • โ›“๏ธLaunch restrictions (mint limits)
      • ๐Ÿ”“Governance structure
      • ๐Ÿš‚Advisory team
      • ๐Ÿ‘ฉโ€๐Ÿซ๐Ÿ‘ฉ๐Ÿซ Laws of Fluidity
      • ๐Ÿ›ฃ๏ธRoadmap
        • ๐Ÿš€Product roadmap
        • ๐ŸŒค๏ธDecentralisation roadmap
      • ๐Ÿ‘ฉโ€๐Ÿš€Why instant rewards?
    • ๐Ÿ’ธUse-cases
      • โŒจ๏ธDevelopers
      • ๐Ÿฆ„DEXs
      • โœจFluid Assets and Utility
      • ๐ŸŽฎMetaverse and Gaming
      • ๐Ÿ–ผ๏ธNFTs
      • ๐Ÿ’ณTransactions and Payments
      • ๐ŸŒŠOther Use-Cases
    • ๐ŸŽชDevelopers
      • ๐ŸขArchitecture
        • ๐Ÿ‘ทWorker architecture
        • ๐Ÿ’ Ethereum contract architecture
        • โ˜€๏ธSolana program architecture
      • ๐ŸŽEVM ABIs
      • โ˜€๏ธSolana account structure
      • ๐Ÿ™‹How can I Fluid Wrap my custom token?
      • ๐Ÿ“ŠGraphQL
      • ๐ŸงพDev Tutorials
        • โ›๏ธCreating a New Utility Mining Client
        • ๐Ÿ‘ฉโ€๐Ÿ’ปSupporting a New Application
        • ๐Ÿ’ธ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
    • ๐Ÿ’ชSecurity
      • ๐ŸคณWebsite/infrastructure security
      • ๐Ÿ“ฅDropboxes
      • ๐Ÿ’ฐBounty program
      • ๐Ÿ“œAudits completed
      • ๐Ÿซ‚Contactable team
    • ๐ŸคPartnerships/collaboration
      • ๐ŸคPartnering with us
      • ๐Ÿ‘Join us!
      • ๐Ÿ’ฌFluidifying your asset
        • ๐Ÿ˜ŽBrand assets
    • Useful links
      • Fluidity website and whitepapers
      • Fluidity Whitepaper v1.0
      • Discord server
      • Medium
      • Telegram
Powered by GitBook
On this page
  • How Fluidity protects against attackers
  • How often and how large are the rewards?
  • Elastic Sigmoid Curve

Was this helpful?

  1. Docs
  2. Learning and getting started

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

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.

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?

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.

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)

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

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.

Elastic Sigmoid Curve

PreviousHow are the rewards earned?NextTransfer Reward Function (TRF) Example

Last updated 1 year ago

Was this helpful?

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 .

๐Ÿ“š
๐Ÿ—ƒ๏ธ
โœ๏ธTransfer Reward Function (TRF) Example
here