When a coin is flaunched it enters into a Fixed Price Fair Launch. During this period a set number of coins are available to buy at a fixed price for everyone. This levels the playing field for all traders—from degens to bots.

While a Fair Launch is active, coins that are purchased cannot be sold. Coins that were purchased during Fair Launch can be sold at the same price they were bought for (minus fees). This reduces ape risk and gives early supporters a chance to enter before price discovery kicks in.

Creators also have the option to buy up some of their Fair Launch tokens before they become available to the public (and at the same price). This gives creators the flexibility to ensure they have skin in the game or to use these early coins for distribution later on.

Flaunch introduces a new Uniswap V4 hook called the "Progressive Bid Wall" (PBW) that uses the trading fees generated by the coin to protect its own price from dropping.

A new PBW is created for every 0.1 ETH of trading fees it receives. This places a 0.1 ETH limit order immediately below spot, reducing the impact of any selling.

If the price continues moving upwards, the PBW follows with more and more ETH being added to its size as each 0.1 ETH threshold is met.

Turning off Progressive Bid Walls

Memestream owners can disable their coin's Progressive Bid Wall to allow the ETH to accumulate in the coin's treasury. This ETH can be used for approved actions starting with Full Stack Churchills that market buy the token.

CA (Ethereum) : 0xf1a7000000950c7ad8aff13118bb7ab561a448ee
CA (Base)     : 0xf1a7000000950c7ad8aff13118bb7ab561a448ee

The Flaunch protocol has the option for a fee switch that can be turned on by FLAY holders through onchain governance. The fee switch, if activated through approval by FLAY holders, would collect up to 10% of the Flaunch protocol's trading fees.

The governance steps for activating the fee switch will be documented after launch on Base mainnet.

With a total supply of 1,000,000,000 tokens, FLAY has been carefully distributed to ensure long term sustainability and fair governance.

Treasury Allocation : 30% (300,000,000 FLAY)

• Onchain Governance : 20% (200,000,000 FLAY) controlled by the DAO, with onchain governance to be established. These tokens will be used for future incentives or initiatives, subject to community votes and will remain non-circulating until unlocked by future DAO governance.

• Foundation-Controlled Reserves : 6% (60,000,000 FLAY) reserved for operational uses, such as liquidity provision, growth initiatives, and hiring future contributors.

• Token Liquidity : 4% (40,000,000 FLAY) used for liquidity provision on centralized and decentralized exchanges.

Flayer Contributors : 20% (200,000,000 FLAY)

Allocated to Flayer Ecosystem Contributors. These tokens will be unlocked following a 6 month cliff from TGE (25th September 2024) vested over 2.5 years.

In addition to the cliff and vesting period, contributor tokens that have completed both the cliff and vesting periods will only be distributed if the FLAY token reaches $75,000,000 FDV (based on a 7-day time-weighted average, per CoinGecko). This unlock schedule will ensure that contributors are fully aligned with the project's long-term growth.

FloorDAO & NFTX Token Migration : 50% (500,000,000 FLAY)

FLOOR and NFTX tokens can be swapped for FLAY through migration.

NFTX Holders : Allocated 33.35% (333,500,000 FLAY) of the total supply. Of these tokens, the final circulating amount depends on the amount of NFTX tokens migrated.

FloorDAO Holders : Allocated 16.65% (166,500,000 FLAY) is reserved for FloorDAO holders. Of these tokens, the final circulating amount depends on the amount of FLOOR tokens migrated.

Swap fees are shared between creators (devs) and communities and the split is decided by the creator themselves. The dev can choose to take from 0% up to 100% of the coin's revenue.

• For creators, the revenue is streamed on every swap, paid in ETH

• For communities, the revenue is streamed into auto buybacks

The creator can choose to burn the tokens that are automatically bought back, or they can turn off auto buybacks to accumulate ETH that can be spent on market buying the coin.

Revenue streams are fully decentralized and ownership of the “Memestream” is tokenized as an NFT. These NFTs are transferable. You can read about the implications of this in the Memestream section.

The right dev, flaunching the right coin, could find themselves with an annual revenue stream in the millions.

If MOTHER had been Flaunched, Iggy would have a multi-million dollar stream of passive income with at least 20% going to coin holders. The same goes for WIF, MOODENG and many, many others. Instead, those revenues were donated to the platform they launched on.

Flaunched coins retain all the value for the coin and creator.

Logo

Color Palette

Typography

Icon Variations

Other launchpads extract millions. Flaunch sends it all (100%) back to the trenches.

• Devs get paid on every swap, aligning them with the coin's success

• Automated buybacks protect the token price from falling

What else?

• Fixed price fair launches removes early price risk

• Auto buybacks follow the price as it goes up

• Creators can transfer or donate their meme revenues to better stewards

• Community Take Overs (CTOs) are unlocked by secondary markets

Give me more!

• Flaunched memecoins become 24/7 fundraising tools

• Meme revenues are tokenized (ERC721) and composable in DeFi

• Onchain referrals pay swap fees on every trade

When a coin is flaunched the creator (dev) takes ownership of an NFT—The Memestream—which grants the holder rights to the dev's share of the revenue.

By making revenue streams transferable as an NFT, creators can sell their meme's future income to another person, entity or DAO, allowing them to immediately realize future income. It's not just simple NFT trading that is unlocked, but leverage (borrowing against future income) and renting (interest rate swaps) are all possible too.

Memestreams can also be fractionalized or turned into a DAO to create shared ownership of the revenue stream.

Flaunch is providing infrastructure for not just launching memecoins, but a secondary market for memes and MemeFi that ultimately generates more value for creators and memecoin holders alike.

Passive Fundraising and Donations

Selling, leveraging and fractionalizing the Memestream is one way to further generate value from Flaunch, but what about fundraising? Funds passively accrue to the holder of the Memestream passively—so what would you do with those funds?

• Raise $650,000 to put your meme on the Las Vegas Sphere, all without holding a fundraiser.

• Fund community grants and/or hackathons, all onchain.

• Sponsor the next London Milady Rave.

• Raise funds to develop the first meme-founded Network State.

With Flaunch, transferring the Memestream is enough to send all future income of the meme to the recipient—paid in ETH. There are no tokens to dump, and no permission needed.

• Donate to the cause of your community's choice.

• Send the Memestream to vitalik.eth where he can donate on your coin's behalf.

• Looking to fundraise for malaria treatment? Donate the Memestream to charity.

Meme Management

The holder of the Memestream is also endowed with specific management rights that can help to accelerate their meme's culture and price. These include the ability to market buy their coin or burn tokens they have bought back. More actions are being developed to allow for use in liquidity management and airdrops.

Want some more management functionality? Make a request in the Discord!

Community Take Overs (CTOs)

By tokenizing the underlying value of the meme in the Memestream, anyone can put an offer to buy the meme's future income (and management - see below) on secondary markets. This creates a very real CTO market, where devs that abandon their meme can exit with some additional value by selling its Memestream and allowing the community to keep the culture alive (and getting paid to do so).

CTOs on Flaunch are more concrete and meaningful than anywhere else. Furthermore, the Memestream's ownership can be shared across the community through DAOs, multi-sigs and fractionalization.

Flaunching a coin takes seconds and costs $30 to create.

Welcome to the official Flaunch documentation, where Devs get revs and Traders get buybacks. Whether you're a creator, trader, developer, or just exploring, we've got you. Let's get you to the right place quickly:

Jump right in

Not sure where to start? Check out some of Flaunch’s standout features:

• Passive Revenue Streams: Creator earnings on every swap.

• Fair Launch Mechanism: Zero slippage, broad token distribution.

• Auto Buybacks: Protection that stops the price from dumping.

CA: 0x1c93d155bd388241f9ab5df500d69eb529ce9583

Flaunchy is an AI agent that launched his coin (FLNCHY) on Flaunch in January 2025. Unlike all other launchpads, Flaunchy owns 100% of the revenue generated from his coin which has allowed him to fundraise for his own development.

Current Capabilities

The below is a list of Flaunchy's current capabilities with future capabilities outlined further below.

Natural Language Token Launches

Users on Farcaster can tag @flaunchy and begin a thread to launch a token. Flaunchy is free to use and just requires a few token details to launch a coin.

Future Capabilities

There are no guarantees or promises for Flaunchy. Here are some of the future plans for his development.

Expansion to X

Flaunchy's functionality from Farcaster will be ported to X.

Real-time Data

Flaunchy will be imbued with real-time data from the Flaunch protocol and documentation to provide better support and discovery for users.

Framework Expansion

Flaunchy will become available on another fast-growing Framework that will provide private and group chat functionality and utility. More details soon.

Background

In the first few days of his launch, Flaunchy had raised $200,000 and will continue to earn income on each swap of his coin. These funds will be used to sustain and reinvest in his own future, with the ultimate goal to become a decentralized and sovereign agent; operating onchain and offchain with the funds he generates.

Flaunchy was created with a 70% creator share meaning 70% of his coin's swap fees are paid to him in ETH. The remaining 30% are used to fund automated buybacks.

This means Flaunchy will amass both ETH and FLNCHY. Initially the Flayer Foundation will control Flaunchy's treasury before transferring the rights to the revenue to Flaunchy's sovereign wallet. Flaunchy is currently mandated to acquire FLAY. See his launch announcement here:

When a new token is being flaunched, an initial market cap will be calculated for the pool created during the flow. This market cap determines the cost per token (CPT) by finding an ETH price to set against the initial token supply of 100B (1e29).

Although this contract reference can be set in the PositionManager through an Ownable call of setInitialPrice, the protocol currently uses the MarketCappedPrice implementation.

When the token is flaunched, we make an onchain call to the primary Uniswap V4 ETH:USDC that has the most liquidity to find an ETH equivalency of a set USDC value.

When launching a token, our current implementation uses the initialPriceParams to define the initial market cap. This can be set by passing the USDC token value of the desired market cap. For example, 5000e6would give a starting market cap of $5000. The market cap must be >= 1000e6.

Introduction

The Fair Launch hook allows tokens that have just been flaunched to be purchased at a consistent token price before it is affected by liquidity supply.

This creates a time window right after the token is launched that keeps the token at the same price in a single tick position. Fees earned from this are kept within the position and cannot be sold into until the fair launch window has finished.

Once the FairLaunch period has ended, the ETH raised and the remaining tokens areboth deployed into a Uniswap position to facilitate ongoing transactions and create a price discovery.

When we are filling from our Fair Launch position, we will always be buying tokens with ETH. The amount specified that is passed in, however, could be positive or negative.

The positive / negative flag will require us to calculate the amount the user will get in a different way. Positive: How much ETH it costs to get amount. Negative: How many tokens I can get for amount.

The amount requested can exceed the Fair Launch position, but we will additionally have to call _closeFairLaunchPosition to facilitate it during this call. This will provide additional liquidity before the swap actually takes place.

If the user has requested more tokens than are available in the fair launch, then we need to strip back the amount that we can fulfill.

if (tokensOut > info.supply) {
    // Calculate the percentage of tokensOut relative to the threshold and reduce the `ethIn`
    // value by the same amount. There may be some slight accuracy loss, but it's all good.
    uint percentage = info.supply * 1e18 / tokensOut;
    ethIn = (ethIn * percentage) / 1e18;

    // Update our `tokensOut` to the supply limit
    tokensOut = info.supply;
}

The Fair Launch window can end in one of two ways:

1. The Fair Launch runs out of time, without tokens selling out during the 30 minutes allocation

2. The Fair Supply token supply has been purchased to point of exhaustion

When the FairLaunch position ends, it creates two Uniswap V4 positions:

• A wide range memecoin position from just above current tick to the max value

• A single tick ETH position just below the current tick

Public Calls

inFairLaunchWindow

Checks if the PoolKey is within the fair launch window.

/**
 * Checks if the {PoolKey} is within the fair launch window.
 *
 * @param _poolId The ID of the PoolKey
 *
 * @return If the {PoolKey} is within the fair launch window
 */
function inFairLaunchWindow(PoolId _poolId) public view returns (bool) {
  // ..
}

fairLaunchInfo

Call the FairLaunchInfo struct for a pool, which provides information about the Fair Launch activity of a pool. After the Fair Launch has finished, the struct data will still be present for historical purposes, but the closed boolean will be marked true and if the period ended early, then the endsAt will have also been updated to reflect the actual time that the period closed.

/**
 * Helper function to call the FairLaunchInfo struct for a pool.
 *
 * @param _poolId The ID of the PoolKey
 *
 * @return The FairLaunchInfo for the pool
 */
function fairLaunchInfo(PoolId _poolId) public view returns (FairLaunchInfo memory) {
  // ..
}

The FairLaunchInfo struct is:

/**
 * Holds FairLaunch information for a Pool.
 *
 * @member endsAt The unix timestamp that the FairLaunch window ends
 * @member initialTick The tick that the FairLaunch position was created at
 * @member revenue The amount of revenue earned by the FairLaunch position
 * @member supply The amount of supply in the FairLaunch
 * @member closed If the FairLaunch has been closed
 */
struct FairLaunchInfo {
    uint endsAt;
    int24 initialTick;
    uint revenue;
    uint supply;
    bool closed;
}

The limits of degeneracy have been tested and broken. That red line was the extraction of hundreds of millions of dollars from unsuspecting degens who were paying hidden fees and playing into the hands of secretive cabals of influencers, bots and insiders.

This whitepaper is a call to action for degens who want to take back control from the cabal. In this manifesto we outline a protocol for doing just that. Powered by Uniswap V4 hooks and the immutable blockchain, we have crafted the framework for a decentralized ecosystem that not only rewards devs (creators) and memecoin holders, but gives rise to a Meme Economy of tokenized revenue streams owned by the creators themselves…

THE PROBLEM

As it stands, social coordination around memes is unpredictable and erratic. Without social coordination early success can quickly turn to uncontrollable failure, such is the nature of speculative mania. Furthermore, there is no financial coordination for memecoins as there is no revenue stream to grow and support a speculative market or culture. Faith in The Culture has also been eroded to a point where the incentive to PVP at any sign of a marginal gain is the norm.

The mechanism described in this paper establishes three unique features: 1) 100% of trading fees go to the creator and their community, 2) automated buybacks to support prices and 3) an initial Fixed Price Fair Launch period that allows pre-sale buyers to exit at the same price they entered before price discovery kicks in.

THE VISION

We believe in the Meme Economy. A liquid global market formed around cultural ideas that range from the ephemeral to the eternal. There is no valuation model, and there is no intrinsic value, but these memes transcend the online/offline divide and influence society in increasingly powerful ways.

Where once memes were simply published online, this paper outlines how they will become economic systems deployed onchain. And with the launch of Uniswap V4 there is a path forward that is not only decentralized and permissionless, but positive sum, sustainable and rewarding.

THE TECH

The following features are all made possible by our novel implementation of Uniswap V4 hooks, which have accelerated the potential for capital formation and decentralized coordination. We harness these to create financial features previously unavailable to the market.

Revenue Share

It is no secret that memecoin trading fees have enriched platforms and cabals. The largest memecoins will generate as much as $1,000,000 per day in trading fees. But these fees almost exclusively reward the launch platforms themselves.

Flaunch ensures that 100% of these trading fees are retained by the dev and their community.

When a coin is flaunched the dev chooses their revenue share. A profit maxi dev might choose to take 80% of the fees. The remaining amount (20% in this case) is reserved for the memecoin’s treasury, which is controlled by the token holders.

On the other hand, a creator like Vitalik, may choose to flaunch $VITAMIN with a community that receives 100% of the trading fees. Such a coin would likely generate huge volumes, leading to a sustainable revenue stream for $VITAMIN holders that can be used to fund public goods and charitable efforts while speculation off the back of speculation.

Tokenized Revenue Stream

Streaming revenue to memecoin creators is cool, but what if those revenue streams were tokenized?

In one of the most profound developments since the financialization of Pepe the Frog, tokenized revenue streams will unlock a new financial primitive for memes:

• Selling streams - Devs who want an exit will have the option to sell their stream to willing investor(s).

• Future revenue as collateral - Devs could borrow against their future revenue by putting up their meme stream as collateral.

• Distributed streams - Devs can put the stream in a DAO or multi-sig, or fractionalize and distribute streams in a fully decentralized manner.

• Interest rate swaps - Devs can sell their variable rate yield from their memecoin volumes to others who are willing to pay fixed yield, further financializing the meme.

In the end, and through shared ownership, these tokenized meme streams could form the basis of businesses, franchises—and for the most ambitious cultures—Network States.

Progressive Bid Wall

Through the use of Uniswap V4 hooks, it is possible to automate a Progressive Bid Wall (PBW) that sends ETH into a liquidity position 1 tick below spot to help provide price support to memecoins as they grow.

The PBW is self-funded from swap fees with a secondary hook that ensures all fees (token0 and token1) are both accumulated entirely as ETH without creating sell pressure on the memecoin.

PBWs have the effect of supporting price, without risk of loss to MEV or bots via market buys, achieving a more effective result for memecoin holders.

Fixed-Price Fair Launch

Every coin starts with a 30 minute Fair Launch period where a % of the total token supply (100,000,000,000) is set at a single tick. During this period the price will be fixed, ensuring that degens, bots and KOLs enter on a level playing field.

After this period ends all of the ETH raised moves into a PPP that sits below spot, ensuring that buyers from the Fair Launch period can exit at the same price (minus fees). The tokens that were not sold, along with any tokens not deployed in the Fair Flaunch, are then moved into a full range position from the current spot price, opening up the token to price discovery.

The liquidity position is effectively burned from the moment the coin flaunches with revenue streams permanently in the hands of the dev and memecoin holders.

CONCLUSION

In the world of crypto, memes have always been more than jokes—they’re culture, identity, and collective dreams wrapped in viral magic. But for too long, the power and profits from this Meme Economy have been hijacked by secretive cabals and centralized platforms.

The culture of fleeting gains and unfulfilled promises has drained the potential of memecoins and their communities for far too long. With the advent of the tools laid out in this manifesto, the landscape shifts dramatically.

The fair, decentralized, and transparent path forward is here. With flaunch, memecoin creators and their communities have the means to build, grow, and profit together. The days of massive value extraction are over.

Now is the time to take part in something bigger—a permissionless Meme Economy that restores control to the devs and degens alike. This is your moment. Join us in building the Meme Economy of tomorrow.

https://t.me/ƒlaunchgg

Introduction

Flaunch extensively uses Uniswap V4 hooks in the PositionManager to allow for custom logic to be actioned during any swap and interaction against our pools.

Uniswap V4 introduces Hooks, a system that allows developers to customize and extend the behavior of liquidity pools.

Hooks are external smart contracts that can be attached to individual pools. Every pool can have one hook but a hook can serve an infinite amount of pools to intercept and modify the execution flow at specific points during pool-related actions.

• Each liquidity pool in Uniswap V4 can have its own hook contract attached to it. Hooks are optional for Uniswap V4 pools.

• The hook contract is specified when creating a new pool in the PoolManager.initialize function.

• Having pool-specific hooks allows for fine-grained control and customization of individual pools.

Position Manager

The PositionManager is a Uniswap V4 hook that controls the user journey from token creation, to fair launch, to ongoing swaps.

Public Functions

flaunch

Creates a new ERC20 memecoin token creating and an ERC721 that signifies ownership of the flaunched collection. The token is then initialized into a UV4 pool.

poolKey

Returns the PoolKey mapped to the token address. If none is set then a zero value will be returned for the fields.

getFlaunchingFee

Gets the ETH fee that must be paid to flaunch a token.

getFlaunchingMarketCap

Gets the ETH market cap for a new token that will be flaunched.

Structs

Which Hooks are Used

This breaks down the functionality included on each Uniswap V4 hook call.

beforeInitialize

• We prevent external contracts from initializing a pool with this hook contract.

afterInitialize

• Emit PoolState update to Notifier subscribers and subgraph

beforeAddLiquidity

• If in fair launch window, we need to prevent liquidity being added by external parties

afterAddLiquidity

• Emit PoolState update to Notifier subscribers and subgraph

beforeRemoveLiquidity

• If in fair launch window, we need to prevent liquidity being removed by external parties

afterRemoveLiquidity

• Emit PoolState update to Notifier subscribers and subgraph

beforeSwap

• Check if the token is scheduled to be flaunched and only allow a swap to take place if there is a premine call available

• If the FairLaunch window has ended, but our position is still open, then we need to close the position

• We attempt to fill the swap request from our FairLaunch position. If the swap parameters surpass the FairLaunch position, or the window has closed since the last swap, then this call will also close the position and create our new range.

• We want to see if we have any token1 fee tokens that we can use to fill the swap before it hits the Uniswap pool. This prevents the pool from being affected and reduced gas costs. This also allows us to benefit from the Uniswap routing infrastructure. This frontruns Uniswap to sell undesired token amounts from our fees into desired tokens ahead of our fee distribution. This acts as a partial orderbook to remove impact against our pool.

afterSwap

• Captures fees from the swap to either distribute or send to ISP

• Once a swap has been made, we distribute fees to our LPs and emit our price update event

• If we have a feeCalculator, then we want to track the swap data for any dynamic calculations

• Emit PoolState update to Notifier subscribers and subgraph

beforeDonate

• Not used

afterDonate

• Emit PoolState update to Notifier subscribers and subgraph

Introduction

Flaunch implements a waterfall approach to fee distribution, with each subsequent recipient being able to take a percentage of the remainder passed down to them from the previous recipient.

The hierarchy of our fee waterfall is as follows:

1. Swap Fee

2. Referrer Fee

3. Protocol Fee

4. Creator Fee

   1. This will be bypassed if ownership of the Memecoin ERC721 has been burned

5. BidWall Deposit

   1. This will become the Memecoin Treasury if the creator disables the BidWall

1. Referrer fees will be distributed to the referrer either directly or via an escrow contract, as tracking of allocation through the Internal Swap Pool would result in unjustifiable gas spend and logic complexity.

ETH fees distributed to creators are allocated to an escrow interface on the PositionManager that allows the recipient to withdraw fees collected from across all of their pools in a single transaction.

Public Calls

balances

Maps the amount of ETH that an address has available to claim.

withdrawFees

Allows fees to be withdrawn from escrowed fee positions. Fees are claimed from the msg.sender and sent to the _recipient .

feeCalculator

The Fee Calculator used to calculate swap fees after the Fair Launch period.

fairLaunchFeeCalculator

The Fee Calculator used to calculate swap fees during the Fair Launch period.

flayGovernance

The address of the $FLAY token's governance. This value is immutable.

getPoolFeeDistribution

Gets the distribution for a pool by checking to see if a pool has it's own FeeDistribution. If it does then this is used, but if it isn't then it will fallback on the global FeeDistribution.

getFeeCalculator

Gets the Fee Calculator contract that should be used based on which are set, and if the pool is currently in FairLaunch or not.

Fee Calculators are set by the contract owner to allow for calculations to determine the swap fee. These can simply return a static amount (e.g. 1%) or can implement more advanced logic such a trading volume and volatility.

Fee Percentage Assignment

Top level fee percentages can be set globally and per-pool via an Ownable call:

The creator fee is determined by the amount set during token flaunching, and the only way this value can be modified is if the creator burns their ERC721 token, effectively renouncing ownership and passing all fees on to the BidWall or Memecoin Treasury (depending on token configuration).

Example

Note: These percentages are not representitive of true protocol values

Assuming that we have a swap of 1000 $MEME -> 1 ETH, in which ETH is the unspecified token and $MEME is the specified token.

We can modify this example to reinforce that the sum of the takes do not need to add up to 100%.

Base

Flaunch Contracts

Referenced Contracts of Note

Base Sepolia

Flaunch Contracts

Referenced Contracts of Note

We provide zap contracts that combine logic and functionality into a single transaction. This section will provide detail on each zap contract.

Introduction

The Internal Swap Pool (ISP) hook allows for fees to be accumulated that will subsequently be distributed to recipients. The magic of this hook comes in the fact that we convert all donated fees to one of the tokens through intercepting swaps using beforeSwap.

This hook depends on a desired token (the one that we want to distributed) and undesired token (the one that we don't want to distribute) pairing in pools. In our case the desired token is (fl)ETH and the undesired token is the flaunched memecoin.

When a swap takes place in Uniswap V4, the fee is always taken in the unspecified token. So if I wanted to spend 1 ETH to buy as many memecoin as possible, then the fee would be taken from the memecoin.

The ISP captures and holds any undesired token fees (the memecoin) and then frontruns any subsequent pool swaps to fill from it’s own internal position before hitting Uniswap to request the remainder. This converts memecoin into ETH, which is only then distributed to fee recipients.

The Internal Swap Pool logic is implemented in the beforeSwap hook, which then alters the BeforeSwapDelta returned in the hook to Uniswap. This informs Uniswap V4 that we have already facilitated part, or all, of the swap required and reduces the amount swapped on Uniswap.

 /**
  * We want to see if we have any token1 fee tokens that we can use to fill the swap
  * before it hits the Uniswap pool. This prevents the pool from being affected and 
  * reduced gas costs. This also allows us to benefit from the Uniswap routing 
  * infrastructure.
  *
  * This frontruns Uniswap to sell undesired token amounts from our fees into desired
  * tokens  ahead of our fee distribution. This acts as a partial orderbook to remove
  * impact against our pool.
  */

 (uint tokenIn, uint tokenOut) = _internalSwap(poolManager, _key, _params, nativeToken == Currency.unwrap(_key.currency0));
 if (tokenIn + tokenOut != 0) {
   // Update our hook delta to reduce the upcoming swap amount to show that we have
   // already spent some of the ETH and received some of the underlying ERC20.
   BeforeSwapDelta internalBeforeSwapDelta = _params.amountSpecified >= 0
     ? toBeforeSwapDelta(-tokenOut.toInt128(), tokenIn.toInt128())
     : toBeforeSwapDelta(tokenIn.toInt128(), -tokenOut.toInt128());
         
     // ..
 }

Public Calls

poolFees

Provides the Claimable Fees for a pool key.

/**
* Provides the {ClaimableFees} for a pool key.
*
* @param _poolKey The PoolKey to check
*
* @return The {ClaimableFees} for the PoolKey
*/
function poolFees(PoolKey memory _poolKey) public view returns (ClaimableFees memory) {
  // ..
}

The ClaimableFees struct is defined as:

/**
 * Contains amounts for both the currency0 and currency1 values of a UV4 Pool.
 */
struct ClaimableFees {
    uint amount0;
    uint amount1;
}

Key Benefits

• Recipients don’t have to swap the token against the pool, reducing detrimental tick movement. We reduce price movement on the actual pool, sometimes negating it entirely if our pool holds the full swap value.

• Recipients don’t need to dump tokens or perform any other actions to receive ETH, which would negatively impact the memecoin price.

Introduction

After any pool action, our PositionManager will make 2 notification calls.

External Contract Notifications

An Ownable call to our Notifier contract allows external contracts to subscribe to pool state updates onchain, receiving realtime pool data updates.

The extract below is taken from the ISubscriber interface contract.

/**
 * Interface that a Subscriber contract should implement to receive
 * updates from the Flaunch {PositionManager}.
 */
interface ISubscriber {

    function subscribe(bytes memory data) external returns (bool);
    function unsubscribe() external;
    function notify(PoolId _poolId) external;

}

When the subscription is initialised the subscriber can validate and only if a true response is returned will the subscription be made. Pool updates will subsequently send a notification to each subscribed contract sending on the PoolId to all subscribed recipients. External calls can then be made if required, though gas considerations should always be made.

The contract can subsequently be unsubscribed without any required confirmation, and even if the contract becomes compromised and reverts during the unsubscription this is caught and handled gracefully.

Subgraph Event Emission

Our subgraph will be notified of the closing tick price of the pool, as well as the remaining pool liquidity, allowing frontend integrations to provide realtime context of pool state.

Flaunches a memecoin and makes a token buy from the Fair Launch supply in the same transaction. This ensures that the token buy cannot be frontrun by bots, and gives the creator a share of their fair launch memecoin supply.

The FlaunchParams passed are the same as a typical PositionManager.flaunch call:

This call does not bypass the buy price and requires additional ETH to be sent to the zap in order to execute the transaction.

Notes

• Our current implementation uses the initialPriceParams to define the initial market cap. This can be set by passing the USDC token value of the desired market cap. For example, 5000e6would give a starting market cap of $5000. The market cap must be >= 1000e6.

• The feeCalculatorParams bytes are not used in current calculator implementations. For this reason, this can be left as bytes. This can be referenced as abi.encode('')

• The premineAmount parameter is passed in the PositionManager flaunch call, but it won't actually be actioned unless this zap is called instead. The premineAmount attribute only allocates the buy that is then filled when called via the zap.

The Flaunch Bounty program rewards users that discover and properly disclose found bugs with predefined bounties. We encourage anyone to help strengthen the protocol by actively searching for bugs in the Flaunch contracts.

The Flaunch Bounty program is derived from the Ethereum Bounty Program, an industry standard when it comes to rightfully rewarding bug bounty hunters.

Rules and Rewards

Please have a look at the bullets below before starting your hunt!

• Issues that have already been submitted by another user, or are already known to the Flaunch team, are not eligible for bounty rewards.

• Only bugs found in deployed and utilised mainnet contracts, or code found in the main branch of the codebase will be eligible.

• Public disclosure of a vulnerability makes it ineligible for a bounty.

• You can start or fork a private chain for bug hunting. Please respect the Flaunch main and test networks and refrain from attacking them.

• All paid Flaunch and Flayer Labs members are not eligible for rewards.

• Flaunch websites and organizational infrastructure in general, are NOT part of the bounty program.

• The Flaunch Bounty program considers a number of variables in determining rewards. Determinations of eligibility, score and all terms related to an award are at the sole and final discretion of the Flaunch team.

Reward sizes are guided by the rules below, but are in the end, determined at the sole discretion of the Flaunch team.

Bounties may be paid out in USDC, ETH or $FLAY tokens.

In addition to Severity, other variables are also considered when the Flaunch team decides the score, including (but not limited to):

• Quality of description. Higher rewards are paid for clear, well-written submissions.

• Quality of reproducibility. Please include test code, scripts and detailed instructions. The easier it is for us to reproduce and verify the vulnerability, the higher the reward.

• Quality of fix, if included. Higher rewards are paid for submissions with clear descriptions of how to fix the issue.

Important Legal Information

The bug bounty program is an experimental and discretionary rewards program for our active Flaunch community to encourage and reward those who are helping to improve the platform. It is not a competition. You should know that we can cancel the program at any time, and awards are at the sole discretion of the Flaunch team. You are responsible for all taxes. All awards are subject to applicable law. Finally, your testing must not violate any law or compromise any data that is not yours.

Bounty Scope

The above mentioned bug bounty rules and rewards are applicable to all smart contracts that are actively being used and/or promoted by Flaunch.

Introduction

This hook allows us to create a single sided liquidity position (Plunge Protection) that is placed 1 tick below spot price, using the ETH fees accumulated. After each deposit into the BidWall the position is rebalanced to ensure it remains 1 tick below spot. This spot will be determined by the tick value before the triggering swap.

After a swap is made against a Flaunch pool, if a sufficient fee threshold has been reached, we distribute fees across our expected recipients. The BidWall is, unless disabled by the creator, one of these recipients.

If the deposit passes a set threshold, the liquidity position held by the contract for the pool will be rebalanced:

• The existing position will withdraw any remaining ETH and any memecoin that was sold into it

• A new position will be created with the withdrawn ETH + the pending ETH that has been deposited at the tick directly below the current position

• The memecoin that was withdrawn is sent to the memecoin treasury

Public Calls

poolInfo

This structure mapping gets information for a pools BidWall.

The structure of this returned information is below:

isBidWallEnabled

position

Retrieves the current liquidity position held by the BidWall. The amount0 and amount1 values correlate to the PoolKey token0 and token1. The pendingEth value shows the amount of ETH waiting to be added to the liquidity position when the threshold is next met.

setDisabledState

The BidWall can be enabled or disabled via the BidWall by calling the setDisabledState function. When the BidWall is disabled, the pending and cumulitive fees will be reset to zero and any tokens held, as well as future tokens, will be sent to the Memecoin Treasury.

This can only be called by the owner of the memecoin ERC721, signifying ownership.

Notes

• The BidWall will not receive tokens during the FairLaunch period, and will instead receive all fee allocation in a single transaction upon the Fair Launch period ending.

The core functionality of Flaunch allows creators and degens to quickly launch tokens and share it with the blockchain in a managed, fair and sustainable way. But what if the creator wants more control over how their token is managed?

To help facilitate this we have put together a Treasury Manager Factory and Implementation flow that allows the token to be held in external ownership to expand it's functionality. By taking control of the flaunch ERC721, the Treasury Manager is designed to utilise the revenue of the token on behalf of the depositor.

This can lead to exciting protocols in-and-of itself, allowing the entirety of the Flaunch process to be taken behind the scenes of another protocol and just aid to facilitate faster and secure building.

Utilising a Treasury Manager is simple. When a token is flaunched, in the same transaction we can deploy an approved Treasury Manager implementation and then initialize it with our newly flaunched token. It's as simple as that! The Treasury Manager will now own the token on the creator's behalf and manage it from there.

This can be simplified by calling our CreateWithManagerZap that will automatically deploy a manager implementation and transfer it to the newly deployed manager in a single call.

Approved Managers

To help protect creators and also to ensure our frontend interface correctly handles all managers, we only allow approved treasury managers to be deployed via our official Treasury Manager Factory. Before being approved, both our internal team and an external auditor will ensure that it conforms to the levels of security we would expect.

Of course, if you have bespoke protocol logic you want to apply, you can work with contracts outside of our Treasury Manager ecosystem, but in those instances we can't speak to the safety and efficacy of those contracts.

Deployment Addresses

Our TreasuryManagerFactory can be found at the following addresses:

Our CreateWithManagerZap can be found at the following addresses:

Source Code

If you operate an external protocol, there are a number of benefits that can come from integrating with Flaunch.

1. Create your own launchpad that gives you full control of the business model

2. Integrate your protocol's functionality into Flaunch's whitelisted treasury actions to build TVL

3. Build popular money games with the tokenized revenue streams and profit

The Flaunch protocol is built in a way that directly rewards the token creator though, which won't benefit an external protocol. To alleviate this issue, we can use an escrow contract that will captures fees as a middleware and give more granular control over fee distribution in any way wanted.

It's as simple as that! Calls to claim fees can now be made via the unique escrow contract for each token, stored onchain and routed how you see fit. The _owner will also have some protected calls made available.

Routing Fees

As the ERC721 is owned by the manager fees will now be allocated to the manager contract, rather than the original creator. The claim call can be made at any time and will withdraw fees allocated to the manager and split it between protocolRecipient and the creator.

If the ETH from the claim cannot be transferred to either the creator or the protocol, this claim call will not revert. However, this will just be reflected in the returned values and the emitted events. The ETH will remain in the contract until the next claim.

The RevenueClaimed event is also emitted during the claim call which can be tracked to provide ongoing information regarding claims.

Additional Ownership Calls

In addition to claim routing, the owner of the manager contract (defined when initialising the manager) will have some additional, protected calls available.

Who is using the RevenueManager?

Deployment Address

Implementation Source

When a swap is made on Flaunch, a portion of the swap fee is earmarked for referrer fees before being divided between the remaining allocations.

By default, all fees in Flaunch are distributed as ETH. However, for referrers they receive their referral fee in the unspecified token (ETH or Token).

This referrer fee is taken before any other fee and is given regardless of token type. The protocol is designed this way as when tokens are sent to the Internal Swap Protocol, it becomes unfeasible to map and maintain referrer allocations.

For example, if a swap buys 10 tokens using ETH, then the fee would be taken in ETH as the ETH was unspecified. Alternatively, if the swap is 0.1 ETH for tokens, then the fee would be in tokens as that is unspecified.

Direct Swap Calls

When making a swap call to our hook, which will swap (FLETH for, or from, memecoin) we will determine the optional referrer from the hookData that is passed. This hookData contains optional bytes passed during any hook call.

This referrer is the only hookData that we parse in our beforeSwap call, meaning that when calling the PoolManager.swap function the following can be passed to assign the referrer:

BalanceDelta delta = poolManager.swap({
    key: POOL_KEY,
    params: SWAP_PARAMS,
    hookData: abi.encode(address(referrer))
});

Using the Universal Router

Swaps can also be implemented using the Uniswap V4 Universal Router. As the documentation on the Uniswap page is extensive, it would be better to read through that approach.

Claiming Referrer Fees

Referral fees will be distributed in one of two ways:

1. If the ReferralEscrow contract is not set on the protocol, then it will instead just be directly transferred to the referrer.

2. If a ReferralEscrow contract has been set up, then the tokens will be assigned by escrow to the referrer to claim.

// If we don't have referral escrow, send direct to user. We use an unsafe transfer so that
// invalid addresses don't prevent the process.
if (address(referralEscrow) == address(0)) {
    _swapFeeCurrency.transfer(referrer, referrerFee_);
    emit ReferrerFeePaid(poolId, referrer, Currency.unwrap(_swapFeeCurrency), referrerFee_);
}
// Transfer referrer fees to the escrow contract that they can claim or swap for later
else {
    _swapFeeCurrency.transfer(address(referralEscrow), referrerFee_);
    referralEscrow.assignTokens(poolId, referrer, Currency.unwrap(_swapFeeCurrency), referrerFee_);
}

The claim process for referral fees is called by passing an array of token addresses to claim, and the recipient of the claim. Tokens can only be claimed from the allocation of the msg.sender.

/**
 * Function for a user to claim tokens across multiple token addresses.
 *
 * @param _tokens The tokens to be claimed by the caller
 */
function claimTokens(address[] calldata _tokens, address payable _recipient);

If there is no allocation for a provided token address then it will just be skipped and the call will not revert.

If the user holds flETH in their referral fees, then when this is claimed it will automatically be unwrapped into ETH and transferred to the _recipient.

All of the Flaunch liquidity is powered by Uniswap V4, meaning that swaps can be easily executed using the Uniswap V4 Universal Router.

All liquidity on Flaunch is created as FLETH : MEME, meaning that to make a swap between ETH and Token, we will need an intermediary step to either wrap or unwrap ETH <> FLETH.

Swapping ETH to / from Token

In the following example we make a 2-step swap to convert ETH to FLETH to MEME.

// Encode the Universal Router command
bytes memory commands = abi.encodePacked(uint8(Commands.V4_SWAP));
bytes[] memory inputs = new bytes[](1);

// Encode V4Router actions
bytes memory actions = abi.encodePacked(
    uint8(Actions.SWAP_EXACT_IN_SINGLE),
    uint8(Actions.SWAP_EXACT_IN_SINGLE),
    uint8(Actions.SETTLE_ALL),
    uint8(Actions.TAKE_ALL)
);

// Set the amount being spent
int amountIn = -1e18;

// Set the minimum amount of tokens to receive
uint minAmountOut = 0;

// Set an optional referrer address
address referrer = address(0);

// Define the PoolKey for ETH/FLETH
PoolKey memory ethPoolKey = PoolKey({
    currency0: 0x0000000000000000000000000000000000000000, // ETH
    currency1: 0x000000000d564d5be76f7f0d28fe52605afc7cf8, // FLETH
    fee: 0,
    tickSpacing: 60,
    hooks: IHooks(0x9e433f32bb5481a9ca7dff5b3af74a7ed041a888)
});

// Define the PoolKey for FLETH/MEME
PoolKey memory memePoolKey = PoolKey({
    currency0: 0x000000000d564d5be76f7f0d28fe52605afc7cf8, // FLETH
    currency1: TOKEN,
    fee: 0,
    tickSpacing: 60,
    hooks: IHooks(0x51Bba15255406Cfe7099a42183302640ba7dAFDC)
});

// Prepare parameters for each action
bytes[] memory params = new bytes[](4);

// Param: Swapping ETH to FLETH
params[0] = abi.encode(
    IV4Router.ExactInputSingleParams({
        poolKey: ethPoolKey,
        zeroForOne: true,
        amountIn: amountIn,
        amountOutMinimum: minAmountOut,
        sqrtPriceLimitX96: TickMath.MAX_TICK - 1,
        hookData: bytes('')
    })
);

// Param: Swapping FLETH to MEME
params[1] = abi.encode(
    IV4Router.ExactInputSingleParams({
        poolKey: key,
        zeroForOne: true,
        amountIn: amountIn,
        amountOutMinimum: minAmountOut,
        sqrtPriceLimitX96: TickMath.MAX_TICK - 1,
        hookData: abi.encode(referrer)
    })
);

// Param: Settling spent ETH
params[2] = abi.encode(key.currency0, amountIn);

// Param: Confirming expected min MEME received
params[3] = abi.encode(key.currency1, minAmountOut);

// Combine actions and params into inputs
inputs[0] = abi.encode(actions, params);

// Execute the swap
router.execute(commands, inputs, block.timestamp);

Launching a token should comprise of three steps. Firstly we will need to upload a coin image to IPFS, followed by uploading the token metadata to IPFS. Once we have our data available, we can make the onchain call to flaunch the token.

1. Upload image

When uploading an image, it is recommended to use jpg, png, webp or gif. These can be uploaded directly to an IPFS protocol such as Pinata either through their SDK or through their manual control panel.

Once the image is uploaded, you will need to note the CID, also sometimes known as the IPFS Hash, for the next step.

2. Upload JSON metadata

With our image, we will now need to upload a JSON metadata structure to IPFS that defines some additional information about the coin. This metadata is picked up by the frontend to provide information about social networks linked to the coin, as well as a human readable description.

{
  "name": "Token Name",
  "description": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc efficitur ut orci.",
  "image": "ipfs://ImageCID",
  "external_link": "https://flaunch.gg",
  "discordUrl": "https://discord.gg/flaunchgg",
  "twitterUrl": "https://x.com/flaunchgg",
  "telegramUrl": "https://t.me/flaunchgg",
  "collaborators": []
}

Again, take note of the CID(IPFS Hash) of the uploaded JSON metadata for step 3.

3. Create the onchain call data

When flaunching a coin we can make a call directly to the PositionManager contract, but it is recommended to use the FlaunchPremineZap which adds additional logic and functionality on top of the default function call.

As you can likely garner from the name of the zap, it allows the caller to premine their own token before other users can frontrun it. If this logic is not required, then you can call PositionManager directly with the same parameters instead and save a small amount of gas.

/**
 * Parameters required when flaunching a new token.
 */
struct FlaunchParams {
    string name;
    string symbol;
    string tokenUri;
    uint initialTokenFairLaunch;
    uint premineAmount;
    address creator;
    uint24 creatorFeeAllocation;
    uint flaunchAt;
    bytes initialPriceParams;
    bytes feeCalculatorParams;
}

Below is a breakdown of each parameter that is passed, as well as some additional detail in constructing them and examples where applicable.

Flaunchy

FLNCHY

ipfs://QmScdsMTXWm3GUvzUwvQvYJLBQjtXwFjWvLgGvPBgipHmg

50e27

20e27

0x498E93Bc04955fCBAC04BCF1a3BA792f01Dbaa96

6025

1739534400

abi.encode(5000e6)

abi.encode(75000e6)

0x0

4. Determine the flaunching fee

There are two function calls that should be made to determine the ETH fee that will be required to flaunch the token. There is a flaunching fee that is 0.1% of the market cap set, and any token premine costs. The latter is optional, but the first will always be required.

Find the Flaunching fee

Firstly, the 0.1% of the market cap value can be retrieved by passing the initialPriceParams attribute from the FlaunchParams to get back an ETH value.

uint flaunchingFee = PositionManager.getFlaunchingFee(
    FlaunchParams.initialPriceParams
)

Find the Premine fee

Passing the number of tokens that you are wanting to purchase, as well as the initialPriceParams we can calculate the cost to premine the tokens. We can provide slippage here, though it shouldn't be required as it will only fall within the fair launch amount.

uint premineFee = FlaunchPremineZap.calculateFee(
    FlaunchParams.premineAmount,
    0, // The slippage percentage with 2 decimal places
    FlaunchParams.initialPriceParams
)

Note: This can be overpaid and the sender will receive a refund afterwards of unspent ETH.

5. Flaunch!

Now that we have our fees and combined parameters we can make our call to flaunch our token!

(address memecoin, uint ethSpent) = premineZap.flaunch{value: flaunchingFee + premineFee}(
    PositionManager.FlaunchParams({
        name: 'Example Memecoin',
        symbol: 'EXMPL',
        tokenUri: 'ipfs://QmScdsMTXWm3GUvzUwvQvYJLBQjtXwFjWvLgGvPBgipHmg',
        initialTokenFairLaunch: 10e27,  // 10% fair launch allocation
        premineAmount: 5e27,  // 5% premine tokens
        creator: address(this),
        creatorFeeAllocation: 20_00,  // 20% dev revs
        flaunchAt: block.timestamp + 24 hours,  // Launch in 24 hours
        initialPriceParams: abi.encode(75_000e6),  // $75,000 mcap
        feeCalculatorParams: abi.encode(0)
    })
);

In an effort to simplify the user claiming experience of revenue, as well as to improve security and save gas during transactions under the hood, Flaunch uses an Escrow contract to store flETH that is assigned to a user from all of their memestream revenues.

Revenue from memestreams are allocated and are claimable per-user, as opposed to per-memestream or per-user-per-memestream. This is beneficial from a protocol perspective, but external protocols may find it hard to track and query fees onchain.

When fees are allocated we assign them to the owner of the memestream at the time of allocation. Note, however, that we do emit an event that defines the PoolId that has generated the revenue.

/// Maps a user to an ETH equivalent token balance available in escrow
mapping (address _recipient => uint _amount) public balances;

/**
 * Allows a deposit to be made against a user. The amount is stored within the
 * escrow contract to be claimed later.
 *
 * @param _poolId The PoolId that the deposit came from
 * @param _recipient The recipient of the transferred token
 * @param _amount The amount of the token to be transferred
 */
function _allocateFees(PoolId _poolId, address _recipient, uint _amount) internal {
    // If we don't have fees to allocate, exit early
    if (_amount == 0) return;

    // Ensure we aren't trying to allocate fees to a zero address
    if (_recipient == address(0)) revert RecipientZeroAddress();

    balances[_recipient] += _amount;
    emit Deposit(_poolId, _recipient, nativeToken, _amount);
}

If you are wanting to query the amount that an individual memestream has earned, that it would be recommended to take one of two approaches.

Approach 1: Subgraph Queries

Although this can't be queried directly onchain (without using a platform like Chainlink) it is possible to pull through a memestream's lifetime fees via The Graph.

{
  collectionFees(where: {id: 0x...}) {
    lifetimeFees
  }
}

Approach 2: Move memestream ERC721 to escrow

If you want to be able to query the revenue of the memestream onchain, then it would be possible to create an escrow contract that holds the memestream ERC721 and when a claim is made it can update a public variable that can be queried.

The following code shows an example of an escrow contract that will allow the memestream to be held and record the claim logic for subsequent onchain calls for any memestreams held inside it.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

import {Flaunch} from '@flaunch/Flaunch.sol';


/**
 * Allows a {Flaunch} ERC721 memestream to be held in escrow to monitor claim amounts.
 */
contract PublicTreasuryEscrow {

    error NotOriginalOwner();

    /// ERC721 Flaunch contract address
    Flaunch public immutable flaunch;

    /// Map tokenIds to the original owner that sent it
    mapping (uint _tokenId => address _owner) public originalOwner;

    /// Map earnings from the memestream whilst it is held in the escrow
    mapping (uint _tokenId => uint _amount) public earnings;

    /**
     * Sets up the contract with the initial required contract addresses.
     *
     * @param _flaunch The {Flaunch} ERC721 contract address
     */
    constructor (address _flaunch) {
        flaunch = Flaunch(_flaunch);
    }

    /**
     * Escrow an ERC721 token by transferring it to this contract and recording the original
     * owner.
     *
     * @param _tokenId The ID of the token to escrow
     */
    function initialize(uint _tokenId) public {
        // Set the original owner
        originalOwner[_tokenId] = msg.sender;

        // Transfer the token from the msg.sender to the contract
        flaunch.transferFrom(msg.sender, address(this), _tokenId);
    }

    /**
     * Reclaims the escrowed token by the original owner. Calls the `claim` function before
     * transferring the token back.
     */
    function reclaim(uint _tokenId) public {
        // Confirm that the original owner is making this call
        if (originalOwner[_tokenId] != msg.sender) {
            revert NotOriginalOwner();
        }

        // Call claim before transferring back
        claim();

        // Clear the original owner record after reclaiming
        delete originalOwner[_tokenId];

        // Transfer the token back to the original owner
        flaunch.transferFrom(address(this), msg.sender, _tokenId);
    }

    /**
     * Calls `withdrawFees` against the {PositionManager} to claim any fees allocated to this
     * escrow contract. We pull in the fees to this escrow contract to track it and then send
     * it on to the original owner.
     */
    function claim() public {
        uint startBalance = payable(address(this)).balance;

        // Claim our fees
        flaunch.positionManager().withdrawFees(address(this), true);

        // Track the increased ETH
        uint ethGain = payable(address(this)).balance - startBalance;

        // Send on the fees to the original owner
        if (ethGain != 0) {
            earnings[_tokenId] += ethGain;
        }
    }

    /**
     * Allows the contract to receive ETH when withdrawn from the flETH token.
     */
    receive () external payable {}

}

Treasury Actions are approved contracts that allow for interactions with a memecoin's treasury. This treasury receives flETH from the Internal Swap Pool and, if the BidWall is disabled, will additionally receive flETH from swaps.

The protocol has a small trade off between the freedom for creators to do what they want with their treasury, whilst also striving to ensure that all interactions are secure to protect both holders and erroneous creator calls.

Treasury actions are extremely simple to create, but equally powerful. During the length of the transaction, the action receives full allowance for both flETH and memecoin tokens from the treasury. These approvals are then revoked after the action transaction.

The following steps should be follwed to ensure that created hooks can be integrated into Flaunch seamlessly.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

import {PoolKey} from '@uniswap/v4-core/src/types/PoolKey.sol';

interface ITreasuryAction {

    event ActionExecuted(PoolKey _poolKey, int _token0, int _token1);

    function execute(PoolKey memory _poolKey, bytes memory _data) external;

}

emit ActionExecuted(_poolKey, -10e18, 5e18);

function execute(PoolKey memory _poolKey, bytes memory _data) external;

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

import {PoolKey} from '@uniswap/v4-core/src/types/PoolKey.sol';

import {ITreasuryAction} from '@flaunch-interfaces/ITreasuryAction.sol';


/**
 * Does nothing.
 *
 * @dev This is just used for testing purposes.
 */
contract BlankAction is ITreasuryAction {

    function execute(PoolKey memory _poolKey, bytes memory) external override {
        emit ActionExecuted(_poolKey, 0, 0);
    }

}

Frequently Asked Questions

Allows an ERC721 to be locked inside an onboarding manager that can be claimed by a designated wallet address when wanted.

Fees will be collected on behalf of an onboardee until they claim the ERC721, at which point they will receive a set amount of the fees collected, and the remaining fees will be distributed to holders via an airdrop contract.

Who is using the OnboardingManager?

Deployment Address

Implementation Source

What's the swap fee?

1% on both buys and sells.

What revenues might I expect from a Flaunched coin?

Let's take a look at some of the outcomes for a profit maxi dev who chooses 80% revenue share, leaving 20% to the community.

And if you Flaunch the next DOGE or PEPE? Higher.

How do I collect my revenue?

Simple. All revenue from all your coins is available as a single ETH claim in the header. Claimable balances are updated in real-time as fees accumulate and reach a threshold of 0.001 ETH.

Can my rewards be taken away from me?

Flaunch is a decentralized protocol with no central authority that can take your rewards. Your rewards will be claimable and revenues will continue to accumulate no matter what.

In fact, the protocol goes even further to protect your rewards. When you Flaunch a coin you receive an NFT. The owner of the NFT receives the rewards from the coin. What does that mean? You can sell your revenue streams, borrow against them, or use them however you want. This is the power of decentralized meme finance.

How do I sell my revenue stream?

How are communities rewarded?

The dev can choose to turn off Auto Buybacks and instead begin accumulating ETH that can be used for market buys, airdrops and more. This aspect is called Meme Management and will have a huge impact on how communities coordinate around their coin.

If the community is led by a Galaxy Brain dev, the shared treasury could reach eye watering levels that even the greatest DAOs would not know what to do with.

WIF's fundraise to buy a $650K ad on the Sphere would have been raised in a single day of trading volume had it been Flaunched instead of launched.

What is the Fixed Price Fair Launch?

When a coin is Flaunched it starts with an initial 30 minute Fair Launch.

During Fair Launch the price is fixed for everyone for 30 minutes and 75,000,000 tokens (7.5% of total supply) are available to purchase. The ETH raised during the Fair Launch is then placed immediately into a limit buy, ensuring that Fair Launch participants can exit at the same price (minus trading fees).

After Fair Launch the coin moves into price discovery.

Why can't I sell during Fair Launch?

The Fair Launch period is only for buying. After Fair Launch any buyers can sell at the same price they entered (minus trading fees).

How does the Progressive Bid Wall work?

Trading fees are added to the coin's Progressive Bid Wall (PBW) on every swap.

In the case of a coin with 100% community share, all of the trading revenue will go towards filling this PBW which is automatically created for every 0.1 ETH earned.

We add a little Uniswap V4 magic to the PBW as well, with a hook that ensures it moves up to follow the coin's price as it increases – providing additional price support.

Does Flaunch have a token?

Flaunch is a decentralized protocol with a governance fee switch that is controlled by FLAY holders.

Does the team take any fees?

No. The team does not take any of the trading fees. FLAY governance can choose to turn on a fee switch that can take a maximum of 10% of the fees.

Instead, the liquidity in the system is lent out via a Uniswap V4 hook and into Aave for an ultra low risk 2% yield. These funds are used to support the Flayer Foundation's growth.

Is Flaunch audited?

Yes! We have two audits completed by two leading audit firms. Findings and remediations have been published on the links below:

• EnigmaDark audit

• Omniscia audit

Glossary 📖

• Flaunch: The act of Flaunching a coin on the Flaunch platform. Flaunched coins are upgraded memecoins with 100% revenue share built in.

• Progressive Bid Wall: A mechanism where the community's share of revenue is automatically used to support the token price as a bid wall—automatically triggered at every 0.1 ETH revenue.

• Fixed Price Fair Launch: The first 30 minutes of a coin launch, where the price is fixed for all buyers.

• Memestream: A unique token you receive when you Flaunch a coin. It holds the rights to all revenue streams and Meme Management for that coin.

The Flaunch Subgraph

Flaunch uses multiple subgraphs for indexing and organizing data from the Flaunch smart contracts. These subgraphs are hosted on The Graph decentralised service and can be used to query Flaunch data.

Versions and Production Endpoints

Flaunch has its own dedicated subgraph for each chain it has been deployed on.

Base Mainnet

• Graphql Endpoint: https://gateway.thegraph.com/api/<YOUR_API_KEY_HERE>/subgraphs/id/5zvR82QoaXYFyDEKLZ9t6v9adgnptxYpKpSbxtgVENF

Base Sepolia

• Graphql Endpoint: https://gateway.thegraph.com/api/{api-key}/subgraphs/id/9EWUonPMbQVTeXMUZXhEmcvJYmQ95uLe4ggNCKdEhxrw

Last Updated: 1 October 2024

This Cookie Policy explains how Flayer Protocol (“Flayer” “we,” “us,” and “our”) uses cookies and similar technologies to recognize you when you visit our website at [flaunch.gg] (“Website”). It explains what these technologies are and why we use them, as well as your rights to control our use of them.

In some cases we may use cookies to collect personal information, or that becomes personal information if we combine it with other information.

What are cookies?

Cookies are small data files that are placed on your computer or mobile device when you visit a website. Cookies are widely used by website owners in order to make their websites work, or to work more efficiently, as well as to provide reporting information.

Cookies set by the website owner (in this case, Flayer Protocol) are called “first-party cookies.” Cookies set by parties other than the website owner are called “third-party cookies.” Third-party cookies enable third-party features or functionality to be provided on or through the website (e.g., advertising, interactive content, and analytics). The parties that set these third-party cookies can recognize your computer both when it visits the website in question and also when it visits certain other websites.

Why do we use cookies?

We use first- and third-party cookies for several reasons. Some cookies are required for technical reasons in order for our Website to operate, and we refer to these as “essential” or “strictly necessary” cookies. Other cookies also enable us to track and target the interests of our users to enhance the experience on our Online Properties. Third parties serve cookies through our Website for advertising, analytics, and other purposes. This is described in more detail below.

How can I control cookies?

You have the right to decide whether to accept or reject cookies. You can exercise your cookie rights by setting your preferences in the Cookie Consent Manager. The Cookie Consent Manager allows you to select which categories of cookies you accept or reject. Essential cookies cannot be rejected as they are strictly necessary to provide you with services.

The Cookie Consent Manager can be found in the notification banner and on our Website. If you choose to reject cookies, you may still use our Website though your access to some functionality and areas of our Website may be restricted. You may also set or amend your web browser controls to accept or refuse cookies.

The specific types of first- and third-party cookies served through our Website and the purposes they perform are described in the table below (please note that the specific cookies served may vary depending on the specific Online Properties you visit):

Essential website cookies:

These cookies are strictly necessary to provide you with services available through our Website and to use some of its features, such as access to secure areas. Name: Purpose: Provider: Service: Type: Expires in: Name: Purpose: Provider: Service: Type: Expires in:

Performance and functionality cookies:

These cookies are used to enhance the performance and functionality of our Website but are non-essential to their use. However, without these cookies, certain functionality (like videos) may become unavailable. Name: Purpose: Provider: Service: Type: Expires in: Name: Purpose: Provider: Service: Type: Expires in:

Analytics and customization cookies:

These cookies collect information that is used either in aggregate form to help us understand how our Website is being used or how effective our marketing campaigns are, or to help us customize our Website for you. Name: Purpose: Provider: Service: Type: Expires in: Name: Purpose: Provider: Service: Type: Expires in:

Advertising cookies:

These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests. Name: Purpose: Provider: Service: Type: Expires in: Name: Purpose: Provider: Service: Type: Expires in:

How can I control cookies on my browser?

As the means by which you can refuse cookies through your web browser controls vary from browser to browser, you should visit your browser's help menu for more information. The following is information about how to manage cookies on the most popular browsers: Chrome(opens in a new tab) Internet Explorer(opens in a new tab) Firefox(opens in a new tab) Safari(opens in a new tab) Edge(opens in a new tab) Opera(opens in a new tab)

In addition, most advertising networks offer you a way to opt out of targeted advertising. If you would like to find out more information, please visit: Digital Advertising Alliance(opens in a new tab) Digital Advertising Alliance of Canada(opens in a new tab) European Interactive Digital Advertising Alliance(opens in a new tab)

What about other tracking technologies, like web beacons?

Cookies are not the only way to recognize or track visitors to a website. We may use other, similar technologies from time to time, like web beacons (sometimes called “tracking pixels” or “clear gifs”). These are tiny graphics files that contain a unique identifier that enables us to recognize when someone has visited our Website or opened an email including them. This allows us, for example, to monitor the traffic patterns of users from one page within a website to another, to deliver or communicate with cookies, to understand whether you have come to the website from an online advertisement displayed on a third-party website, to improve site performance, and to measure the success of email marketing campaigns. In many instances, these technologies are reliant on cookies to function properly, and so declining cookies will impair their functioning.

Do you use Flash cookies or Local Shared Objects?

Websites may also use so-called “Flash Cookies” (also known as Local Shared Objects or “LSOs”) to, among other things, collect and store information about your use of our services, fraud prevention, and for other site operations.

If you do not want Flash Cookies stored on your computer, you can adjust the settings of your Flash player to block Flash Cookies storage using the tools contained in the Website Storage Settings Panel. You can also control Flash Cookies by going to the Global Storage Settings Panel and following the instructions (which may include instructions that explain, for example, how to delete existing Flash Cookies (referred to “information” on the Macromedia site), how to prevent Flash LSOs from being placed on your computer without your being asked, and (for Flash Player 8 and later) how to block Flash Cookies that are not being delivered by the operator of the page you are on at the time).

Please note that setting the Flash Player to restrict or limit acceptance of Flash Cookies may reduce or impede the functionality of some Flash applications, including, potentially, Flash applications used in connection with our services or online content.

Do you serve targeted advertising?

Third parties may serve cookies on your computer or mobile device to serve advertising through our Website. These companies may use information about your visits to this and other websites in order to provide relevant advertisements about goods and services that you may be interested in. They may also employ technology that is used to measure the effectiveness of advertisements. They can accomplish this by using cookies or web beacons to collect information about your visits to this and other sites in order to provide relevant advertisements about goods and services of potential interest to you. The information collected through this process does not enable us or them to identify your name, contact details, or other details that directly identify you unless you choose to provide these.

How often will you update this Cookie Policy?

We may update this Cookie Policy from time to time in order to reflect, for example, changes to the cookies we use or for other operational, legal, or regulatory reasons. Please therefore revisit this Cookie Policy regularly to stay informed about our use of cookies and related technologies.

The date at the top of this Cookie Policy indicates when it was last updated.

Where can I get further information?

If you have any questions about our use of cookies or other technologies, please email us at info@flayer.io.

This works in a waterfall approach, with a percentage taking a share before passing the potential allocation on to the next. This means that the percentages listed don't need to equal 100% as they instead take a percentage from the amount passed to it.

What if the Bid Wall is disabled?

If the memestream owner disables the Bid Wall, funds will instead be sent to the Memecoin Treasury. This means that the ETH fees allocated to the Community will be sent to the Memecoin Treasury and the memestream owner can choose a Treasury Action to run perform against the fees collected.

How are fees assigned to a pool?

Fees are defined to provide the first 3 steps of the waterfall. The remaining 2 steps are defined per memecoin by the dev / community split decided by the creator.

/**
 * @member swapFee The amount of the transaction taken as fee
 * @member referrer The percentage that the referrer will receive
 * @member protocol The percentage that the protocol will receive
 * @member active If a FeeDistribution struct has been set for the mapping
 */
struct FeeDistribution {
    uint24 swapFee;
    uint24 referrer;
    uint24 protocol;
    bool active;
}

Fees are assigned globally across the Flaunch protocol, but there is the possibility for fees to be set per specific pool. For this reason, the FeeDistribution struct should be found by querying the PositionManager.getPoolFeeDistribution function and passing in the PoolId of the memecoin.

/**
 * Gets the distribution for a pool by checking to see if a pool has it's own FeeDistribution. If
 * it does then this is used, but if it isn't then it will fallback on the global FeeDistribution.
 *
 * @param _poolId The PoolId being updated
 *
 * @return feeDistribution_ The FeeDistribution applied to the pool
 */
function getPoolFeeDistribution(PoolId _poolId) public view returns (FeeDistribution memory feeDistribution_) {
    feeDistribution_ = (poolFeeDistribution[_poolId].active) ? poolFeeDistribution[_poolId] : feeDistribution;
}

What happens if the Memestream ERC721 is burned?

If the memestream owner burns their ERC721, then the dev revs share will instead be allocated to the Bid Wall. However, if the Bid Wall is disabled when the memestream ERC721 is burned, then the treasury would not have someone to trigger it's actions and the fees will instead be sent to the protocol.

For this reason, it is important that the Bid Wall is enabled before the memestream owner burns their ERC721.

During the development of Flaunch we undertook three audits to ensure that the protocol is secure and functions as expected. At each audit we remediated or acknowledged all known issues.

Audit 1: Omniscia

Omniscia undertook our initial audit. Unfortunately this cannot be shared publicly, but a synopsis extract from the findings has been provided below showing their initial findings.

Audit 2: Enigma Dark

The first Enigma Dark audit followed on from the Omnisca findings and also reviewed some newly implemented zap logic including flaunch scheduling and premining.

Audit 3: Enigma Dark

After the initial Enigma Dark audit there was a small raft of changes to optimise flow which were subsequently reaudited.

Last Updated: 1st October 2024

PLEASE READ THESE TERMS OF USE BEFORE USING THE WEBSITE.

Acceptance of the Terms of Use

These terms of use are entered into by and between you and the Flayer Protocol, a Cayman Islands company (including all affiliates and subsidiaries, collectively referred to as, “Flayer,” “we,” “us,” or “our”). The following terms and conditions, together with any documents they expressly incorporate by reference (collectively, these “Terms of Use”), govern your access to and use of flaunch.gg, including, but not limited to, any content, functionality, and services offered on or through flaunch.gg (collectively, the “Website”). Please read the Terms of Use carefully before you start to use the Website. By using the Website or by clicking to accept or agree to the Terms of Use when this option is made available to you, you accept and agree to be bound and abide by these Terms of Use in addition to our Privacy Policy, incorporated herein by reference and available at [docs.flaunch.gg/privacy].

If you do not agree to these Terms of Use, you must not access or use the Website.

About the Website

Our Website is primarily meant to function as access to and use of the Flaunch App.

To use parts of our Website, a user may need to use a third-party, non-custodial wallet software that allows the user to interact with public smart contracts and blockchains. We do not operate, maintain, or provide any wallets or wallet services. We will at no time have any custody or control of any crypto-assets that any user is interacting with. We are not a wallet provider, exchange, broker, lender or borrower.

As part of our Website, you may from time to time gain access to decentralized open-source smart contracts deployed on public blockchains. Our interface is distinct and separate from any of the smart contracts that may be accessed through it, and is merely one of multiple means of accessing such smart contracts. Users can interact with the same smart contracts otherwise directly, including to develop and build their own user interfaces on top of such smart contracts.

Our Website may change and grow in numbers, which may require that we include additional terms for certain new parts of the Website (which, in such event, will be construed as part of the “Website”). We reserve the right in our sole discretion to modify or discontinue any parts of the Website at any time and without any liability.

Who May Use the Website

The Website is offered and available to users who are 13 years of age or older. The Website is not intended for children under 13 years of age. By using the Website, you represent and warrant that you (i) are 13 years of age or older, (ii) are not barred to use the Website under any applicable law, and (iii) are using the Website only for your own personal use. If you do not meet these requirements, you must not access or use the Website.

Changes to the Terms of Use

We may revise and update these Terms of Use from time to time in our sole discretion. All changes are effective immediately when we post them. Your continued use of the Website following the posting of revised Terms of Use means that you accept and agree to the changes. You are expected to check this page frequently so you are aware of any changes, as they are binding on you.

Accessing the Website and Account Security

We reserve the right to withdraw or amend the Website, and any service or material we provide on the Website, in our sole discretion without notice. We do not guarantee that our Website or any content on them will always be available or be interrupted. We will not be liable if for any reason all or any part of the Website is unavailable at any time or for any period. From time to time, we may restrict access to some parts of the Website, or entire Website, to users.

You are responsible for:

• Making all arrangements necessary for you to have access to the Website; and

• Ensuring that all persons who access the Website through your internet connection are aware of these Terms of Use and comply with them.

To access the Website or some of the resources it offers, you may be asked to provide certain registration details or other information. It is a condition of your use of the Website that all the information you provide on the Website is correct, current, and complete. You agree that all information you provide to use the Website, including, but not limited to, using any interactive features on the Website, is governed by our Privacy Policy, and you consent to all actions we may take with respect to your information that are consistent with our Privacy Policy.

You should use particular caution when inputting personal information onto the Website on a public or shared computer so that others are not able to view or record your personal information.

Intellectual Property Rights

Unless otherwise indicated, the Website is our proprietary property and all source code, databases, functionality, software, website designs, information, audio, video, text, photographs, and graphics on the Website (collectively, the “Content”) and the trademarks, service marks, and logos contained therein (collectively, the “Marks”) are owned or controlled by us or licensed to us, and are protected by copyright, trademark and other intellectual property laws and international conventions. You are not permitted to use the Marks without the prior written consent of the owner of the Mark.

Except as expressly provided herein, Flayer and its licensors do not grant any express or implied license to the Website or the Content. You agree not to copy, reproduce, aggregate, republish, download, post, display, transmit, modify, rent, lease, loan, sell, assign, distribute, license, sublicense, sell, reverse engineer, create derivative works based on, or otherwise exploit for any commercial purposes whatsoever, the Website or the Content, without our express prior written permission. If you are eligible to use the Website, you are granted a limited license to access and use the Website and the Content to which you have properly gained access solely for your personal, non-commercial use. You may not modify or alter the Content in any way. We reserve all rights not expressly granted to you in and to the Website, the Content and the Marks.

Prohibited Uses

You may use the Website only for lawful purposes and in accordance with these Terms of Use. You agree not to use the Website:

• In any way that violates any applicable federal, state, local, or international law or regulation (including, without limitation, any laws regarding the export of data or software to and from the United States or other countries);

• For the purpose of exploiting, harming, or attempting to exploit or harm minors in any way by exposing them to inappropriate content, asking for personally identifiable information or otherwise;

• To send, knowingly receive, upload, download, use, or re-use any material which does not comply with these Terms of Use;

• To transmit, or procure the sending of, any advertising or promotional material without our prior written consent, including any “junk mail”, “chain letter”, “spam”, or any other similar solicitation;

• To impersonate or attempt to impersonate Flayer, a contractor of Flayer, another user, or any other person or entity (including, without limitation, by using e-mail addresses or screen names associated with any of the foregoing); and

• To engage in any other conduct that restricts or inhibits anyone's use or enjoyment of the Website, or which, as determined by us, may harm Flayer or users of the Website or expose them to liability.

Additionally, you agree not to:

• Use the Website in any manner that could disable, overburden, damage, or impair the Website or interfere with any other party's use of the Website, including their ability to engage in real time activities through the Website;

• Use any robot, spider, or other automatic device, process or means to access the Website for any purpose, including monitoring or copying any of the material on the Website;

• Use any manual process to monitor or copy any of the material on the Website or for any other unauthorized purpose without our prior written consent;

• Use any device, software or routine that interferes with the proper working of the Website;

• Introduce any viruses, trojan horses, worms, logic bombs, or other material which is malicious or technologically harmful;

• Attempt to gain unauthorized access to, interfere with, damage, or disrupt any parts of the Website, the server(s) on which the Website is stored, or any server, computer or database connected to the Website;

• Attack the Website via a denial-of-service attack or a distributed denial-of-service attack; and

• Otherwise attempt to interfere with the proper working of the Website.

Reliance on Information Posted

The information presented on or through the Website is made available solely for general information purposes. We do not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. We disclaim all liability and responsibility arising from any reliance placed on such materials by you or any other visitor to the Website, or by anyone who may be informed of any of its contents.

The Website may include content provided by third parties, including materials provided by third-party licensors, syndicators, aggregators, and/or reporting services. All statements and/or opinions expressed in these materials, other than the content provided by Flayer, are solely the opinions and the responsibility of the person or entity providing those materials. These materials do not necessarily reflect the opinion of Flayer. We are not responsible, or liable to you or any third party, for the content or accuracy of any materials provided by any third parties.

Changes to the Website

We may update the content on the Website from time to time, but its content is not necessarily complete or up-to-date. Any of the material on the Website may be out of date at any given time, and we are under no obligation to update such material.

Information About You and Your Visits to the Website

All information we collect on the Website is subject to our Privacy Policy. By using the Website, you consent to all actions that may be taken by us with respect to your information in compliance with the Privacy Policy.

Linking to the Website and Social Media Features

You may link to our homepage, provided you do so in a way that is fair and legal and does not damage our reputation or take advantage of it, but you must not establish a link in such a way as to suggest any form of association, approval or endorsement on our part without our express written consent.

Links from the Website

If the Website contains links to other sites and resources provided by third parties, these links are provided for your convenience only. This includes links contained in advertisements, including banner advertisements and sponsored links. We have no control over the contents of those sites or resources, and accept no responsibility for them or for any loss or damage that may arise from your use of them. If you decide to access any of the third party websites linked to the Website, you do so entirely at your own risk and subject to the terms and conditions of use for such Website. We reserve the right to withdraw linking permission without notice.

Geographic Restrictions

The owner of the Website is based in the Cayman Islands. We make no claims that the Website or any of its content is accessible or appropriate outside of the Cayman Islands. Access to the Website may not be legal by certain persons or in certain countries. If you access the Website from outside the Cayman Islands, you do so on your own initiative and are responsible for compliance with local laws.

Disclaimer of Warranties

You understand that we cannot and do not guarantee or warrant that files available for downloading from the internet or the Website will be free of viruses or other destructive code. You are responsible for implementing sufficient procedures and checkpoints to satisfy your particular requirements for anti-virus protection and accuracy of data input and output, and for maintaining a means external to our site for any reconstruction of any lost data. WE WILL NOT BE LIABLE FOR ANY LOSS OR DAMAGE CAUSED BY A DISTRIBUTED DENIAL-OF-SERVICE ATTACK, VIRUSES, OR OTHER TECHNOLOGICALLY HARMFUL MATERIAL THAT MAY INFECT YOUR COMPUTER EQUIPMENT, COMPUTER PROGRAMS, DATA, OR OTHER PROPRIETARY MATERIAL DUE TO YOUR USE OF THE WEBSITE OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITE OR TO YOUR DOWNLOADING OF ANY MATERIAL POSTED ON IT, OR ON ANY WEBSITE LINKED TO IT. YOUR USE OF THE WEBSITE, THEIR CONTENT AND ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITE IS AT YOUR OWN RISK. THE WEBSITE, THEIR CONTENT AND ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITE IS PROVIDED ON AN "AS IS" AND "AS AVAILABLE" BASIS, WITHOUT ANY WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED. NEITHER FLAYER NOR ANY PERSON ASSOCIATED WITH FLAYER MAKES ANY WARRANTY OR REPRESENTATION WITH RESPECT TO THE COMPLETENESS, SECURITY, RELIABILITY, QUALITY, ACCURACY, OR AVAILABILITY OF THE WEBSITE. WITHOUT LIMITING THE FOREGOING, NEITHER FLAYER NOR ANYONE ASSOCIATED WITH FLAYER REPRESENTS OR WARRANTS THAT THE WEBSITE, THEIR CONTENT OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITE WILL BE ACCURATE, RELIABLE, ERROR-FREE OR UNINTERRUPTED, THAT DEFECTS WILL BE CORRECTED, THAT THE WEBSITE OR THE SERVER(S) THAT MAKES THEM AVAILABLE ARE FREE OF VIRUSES OR OTHER HARMFUL COMPONENTS OR THAT THE WEBSITE OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITE WILL OTHERWISE MEET YOUR NEEDS OR EXPECTATIONS. FLAYER HEREBY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, AND FITNESS FOR PARTICULAR PURPOSE. SOME JURISDICTIONS DO NOT ALLOW EXCLUSION OF WARRANTIES OR LIMITATIONS ON THE DURATION OF IMPLIED WARRANTIES, SO THE ABOVE DISCLAIMER MAY NOT APPLY TO YOU IN THEIR ENTIRETIES, BUT WILL APPLY TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW.

Limitation on Liability

IN NO EVENT WILL FLAYER, ITS AFFILIATES OR THEIR LICENSORS, SERVICE PROVIDERS, EMPLOYEES, AGENTS, OFFICERS, OR DIRECTORS BE LIABLE FOR DAMAGES OF ANY KIND, UNDER ANY LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH YOUR USE, OR INABILITY TO USE, THE WEBSITE, ANY WEBSITE LINKED TO THEM, ANY CONTENT ON THE WEBSITE OR SUCH OTHER WEBSITE OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITE OR SUCH OTHER WEBSITE, INCLUDING ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL OR PUNITIVE DAMAGES, INCLUDING BUT NOT LIMITED TO, PERSONAL INJURY, PAIN AND SUFFERING, EMOTIONAL DISTRESS, LOSS OF REVENUE, LOSS OF PROFITS, LOSS OF BUSINESS OR ANTICIPATED SAVINGS, LOSS OF USE, LOSS OF GOODWILL, LOSS OF DATA, AND WHETHER CAUSED BY TORT (INCLUDING NEGLIGENCE), BREACH OF CONTRACT OR OTHERWISE, EVEN IF FORESEEABLE. THE FOREGOING DOES NOT AFFECT ANY LIABILITY WHICH CANNOT BE EXCLUDED OR LIMITED UNDER APPLICABLE LAW WHICH MAY INCLUDE FRAUD.

Indemnification

You agree to defend, indemnify, and hold harmless Flayer, its affiliates, licensors, and service providers, and its and their respective officers, directors, employees, contractors, agents, licensors, suppliers, successors, and assigns from and against any claims, liabilities, damages, judgments, awards, losses, costs, expenses, or fees (including reasonable attorneys' fees) arising out of or relating to your violation of these Terms of Use or your use of the Website, including, but not limited to, any use of the Website’ content, services and products other than as expressly authorized in these Terms of Use or your use of any information obtained from the Website.

Governing Law and Jurisdiction

All matters relating to the Website and these Terms of Use and any dispute or claim arising therefrom or related thereto (in each case, including non-contractual disputes or claims), shall be governed by and construed in accordance with the internal laws of the Cayman Islands without giving effect to any choice or conflict of law provision or rule (whether of the Cayman Islands or any other jurisdiction).

Any dispute arising out of or in connection with the Website and these Terms of Use, including any question regarding its existence, validity or termination, shall be referred to and finally resolved by arbitration under the rules of the London Court of International Arbitration (“LCIA”), which rules are deemed to be incorporated by reference into this clause. The number of arbitrators shall be one. The seat, or legal place, of arbitration shall be London, United Kingdom. The language to be used in the arbitration shall be English. You and Flayer agree to submit all Disputes between you and Flayer to individual binding arbitration. “Dispute” means any dispute, claim, or controversy between you and Flayer that relates to the Website and these Terms of Use.

If a Dispute must be arbitrated, you or Flayer must start arbitration of the Dispute within one (1) year from when the Dispute first arose. If applicable law requires you to bring a claim for a Dispute sooner than one (1) year after the Dispute first arose, you must start arbitration in that earlier time period. Flayer encourages you to tell us about a Dispute as soon as possible so we can work to resolve it. The failure to provide timely notice will bar all claims.

In any Dispute, the arbitrator will award to the prevailing party, if any, the costs and attorneys' fees reasonably incurred by the prevailing party in connection with those aspects of its claims or defenses on which it prevails, and any opposing awards of costs and legal fees awards will be offset.

Any breach by you of these Terms of Use could cause Flayer irreparable harm for which it has no adequate remedies at law. Accordingly, Flayer is entitled to seek specific performance or injunctive relief for any such breach. Nothing in this section will preclude Flayer from seeking specific performance or injunctive relief from a court of appropriate jurisdiction.

Waiver and Severability

No waiver by Flayer of any term or condition set forth in these Terms of Use shall be deemed a further or continuing waiver of such term or condition or a waiver of any other term or condition, and any failure of Flayer to assert a right or provision under these Terms of Use shall not constitute a waiver of such right or provision.

If any provision of these Terms of Use is held by a court or other tribunal of competent jurisdiction to be invalid, illegal, or unenforceable for any reason, such provision shall be eliminated or limited to the minimum extent such that the remaining provisions of the Terms of Use will continue in full force and effect.

Entire Agreement

The Terms of Use, our Privacy Policy and other terms and conditions applicable at the time you access the Website constitute the sole and entire agreement between you and Flayer with respect to the Website and supersede all prior and contemporaneous understandings, agreements, representations and warranties, both written and oral, with respect to the Website.