Cross-chain liquid staking

The purpose of LP token staking in the form of liquidity mining, is to provide cheap convertibility and easy trading of the token (unlike traditional staking which incentivises holding). A downside of the traditional Uniswap v2 LP-token liquidity mining is that it is constrained to a single network.

Goals

• Incentivise reduced slippage, spread and trading through liquidity mining.
• Incentivise liquidity mining on multiple blockchain networks.
• Unify rewards calculations across multiple blockchain networks.

What would it look like if the incentives were cross-chain?

The Coinweb protocol can observe trading across multiple L1 blockchains, with multiple tokens.

A potential problem statement (cross-chain liquidity mining):

1. A project starts or exists on Ethereum using protocol token A
2. Because of reasons (fees, speed, ...), token A is bridged to other chains, and exists as token aA, bA, cA in various forms on chains A, B, and C.
3. These other chains (chain A, B, C) have various AMMs where aA, bA, cA is traded. These trading positions issue LP tokens aAlp, bAlp, cAlp.
4. The project wants to incentivize liquidity in AMMs on other chains, and thus LP staking of aAlp, bAlp, cAlp is required.
5. Bridging aAlp, bAlp etc back to Ethereum and then allowing staking is getting really complex and not attractive, so it does not happen.

Solution: Cross-chain LP staking / cross-chain liquidity mining

1. LP token holders (aAlp, bAlp, cAlp) signal non-custodial staking across the various chains (i.e. a contract/wallet holding these tokens, sending a signal to the Coinweb layer to monitor that they are not be moved). As long as the L1 LP tokens are not moved, the monitoring Coinweb contract generates cwAdays tokens. One cwAdays token is issued per day that either aAlp, bAlp, cAlp is held.
2. cwAdays is a Coinweb native L2 token.
3. The protocol creates a market value for the cwAdays token:
   • a. Manually: By attaching a bonding curve to the cwAdays token, they are convertible to CWEB which can be further converted.
   • b. Automatically:
     • i. A reward L1 contract issues new A tokens as rewards
     • ii. These tokens are converted into wCWEB using Uniswap v2/v3
     • iii. wCWEB is converted to native CWEB using whatever mechanism we land on (i.e. by transferring to a collateral contract, by burning or similar)
     • iv.CWEB is used to buy cwAdays from the cwAdays bonding curve
     • v. cwAdays are burned

Potential problem statement (traditional staking ):

1. A project starts or exists on Ethereum using protocol token A
2. Because of reasons (fees, speed, ...), token A is bridged to other chains, and exists as token aA, bA, cA in various forms on chains A, B, and C.
3. The project wants to support staking of tokens aA, bA, cA on their respective chains to incentivise holding in a more cross-chain manner.
4. Bridging aA, bA etc back to Ethereum and then allowing staking is getting really complex and not attractive, so it does not happen.

Solution: Cross-chain staking / Non custodial staking

1. Bridged token holders (aA, bA, cA) signal non-custodial staking across the various chains (i.e. a contract/wallet holding these tokens, sending a signal to the Coinweb layer to monitor that they are not be moved) As long as the L1 tokens are not moved, the monitoring Coiinweb contract generates cwAdays tokens. 1 cwAdays token is issued per day that either aA, bA, cA is held.
2. The rest is the same as the previous solution

Potential problem statement (generalized):

1. A project starts or exists on Ethereum using protocol token A
2. Because of reasons (fees, speed, ...), token A is bridged to other chains, and exists as token aA, bA, cA in various forms on chains A, B, and C.
3. The project wants to support something that can be encoded as a "restriction contract" which given a bridged token, emits a representative token. The protocol wants to incentivize this behavior.
4. Bridging aA, bA etc back to Ethereum and then allowing staking is getting really complex and not attractive, so it does not happen.
5. Solution: Generalized incentive system
6. Similar to previous, but reactive smart contracts is incentivizing non-custodial holding of any given set of representative L1 tokens with flexible reward tokens issued in the common Coinweb L2 system.

Summary:

1. Some project has a token X. this is bridged to chains A, B, C, ...
2. Project X needs to incentivize staking, AMMs etc across all the chains, not only the anchor chain
3. Bridging stuff back and forth to implement rewards is complex
4. Separating the mechanism (staking, AMM, ++) from the reward system fixes this
5. Keeping the restriction/mechanism in L1, but ignore any rewards
6. Let Coinweb handle the rewards by observing behavior across AMMs, staking contracts etc on multiple L1s
7. Project X now has a one-stop-shop only needing to incentivize holding of the reward token which exists at Coinweb L2
8. This only requires converting their token X, on the anchor chain, into CWEB, and buying the Coinweb native reward token.
9. Non-custodial staking and other behavior not supported by L1 contracts can be supported.

Additional variations of the concept:

1. Incentivize bridging Give reward tokens to the address that receives the bridged token, this reward can be < the cost of bridging to avoid misuse.

2. Incentivize transfer Give rewards to simply transferring tokens, this is like subsidizing transfers.

Both of these mechanisms, especially #2 is difficult to achieve without reactive smart contracts. Subsidizing transfers must normally be built into the contract, while doing it at the Coinweb layer can be orthogonal to the original contract. Various conditionals are popular, like if you stake X, then you get the opportunity to get reward Y if you also do Z.