Protocol Fee Switch

How the Fee Switch works

When disabled, the protocol fee share will just be distributed amongst the other fee beneficiaries (token creator, etc). When enabled, the fees will instead first be portioned off to capture an allocation for the protocol.

The fees will then be stored in the traditional FeeEscrow contract, ready to be claimed and utilised by governance.

The fee calculation works like a waterfall, with each recipient capturing an amount before being passed to the next recipient.

Once captured, the swap fee (1%) is distributed across 3 different recipients. One of these, the protocol fee, is optional.

Recipient	Notes
Protocol	Optional fee set by proposal
Creator	Defined when the token is flaunched.
Bidwall	Defined when the token is flaunched. If the BidWall is not enabled for the token, then it will be directly sent to the MemecoinTreasury. If the Memestream NFT has been burned, then this will be allocated to the protocol.

If we assume that a swap takes place for 100 eth and that the protocol fee switch was enabled and set to 5%, then this would result in the following fee distribution:

Recipient	Amount	Calculation
Swap Fee	1 eth	100 / 100 * 1
Protocol	0.0475 eth	(1 - 0.05) / 100 * 5
Creator	0.722 eth	(1 - 0.05 - 0.0475) / 100 * 80
Bidwall	0.1805 eth	1 - 0.05 - 0.0475 - 0.722

How is the fee switch enabled?

Each Flaunch PositionManager contract has it's own FeeDistributor inheritance. This allows the protocol fee to be set explicitly on each PositionManager. The fee switch will be enabled when this value is not 0.

The protocol fee must range from between 0% and 10%.

The value is represented with 2 decimal places, so a value of 550 would represent a protocol fee of 5.5%, taken from the overall swap fee.

To enable the fees, the governance would need to create a structured proposal that calls each PositionManager and makes the above call to set a protocol fee value.

Where are these fees stored?

Fees allocated to the protocol will be stored in the same FeeEscrow contract in the same way that fees are allocated to creators. These can be claimed by, and only by, the ProtocolFeeRecipient at any time. This claim call will be callable by governance to fund any proposals made.

Contract	Address
FeeEscrow	0x72e6f7948b1B1A343B477F39aAbd2E35E6D27dde
ProtocolFeeRecipient	0x1150c53eB4cE3aDE47808D1D1Ac9636b774eE079

There is a singular exception to this. The first PositionManager contract deployed for Flaunch set the protocol fee recipient as the Flayer Foundation multisig. More information regarding this can be found below.

Claiming Fees for proposal use

To claim protocol fees, the L2Owner can call claim against the ProtocolFeeRecipient contract. This provides a simplified flow to call all fees. All fees, like any other fee allocation on Flaunch, are provided exclusively in native ETH.

A caveat in fee claiming

Due to a contract upgrade during the start of the Flaunch project, if the first PositionManager (PositionManager1) enables protocol fees then they will be allocated immutably to the Flayer Foundation multisig.

At time of writing there are 4755 flaunched tokens on this PositionManager1.

For legal purposes, the foundation has no obligation to use these protocol fees for buybacks (but with obligations to be positive-sum for everything the Foundation builds). As the PositionManager1 protocol fee recipient cannot be changed, any fees generated from them will therefore be true to this statement.

All future PositionManagers (post PositionManager1) will be utilized at the discretion of $FLAY token holders to action on through onchain governance.

Position Manager Addresses (Chain ID: 8453)

Contract	Address
PositionManager1	0x6A53F8b799bE11a2A3264eF0bfF183dCB12d9571
PositionManager2	0xB4512bf57d50fbcb64a3adF8b17a79b2A204C18C

Are the fees safe?

The ETH allocated to the protocol are securely stored onchain in our battle-tested FeeEscrow contracts.

This process has been extensively audited and shows no concerns.