[draft] MIP-40: NB-FFS Decoupled #40

l-monninger · 2024-10-28T10:44:35Z

Summary

MIP-40

apenzk

The following main changes are suggested (does not cover all changes)

improve the figure.
also add a figure for AB-FFS Partially Decoupled
consider approaching the problem different. define AB-FFS partially decoupled first and showing the issues that arise. before defining AB-FFS Decoupled. otherwise it is not clear if the proposed solution solves the encountered issues well.
define the token types at the beginning
the motivation is to tackle the falibility of AB but i could not identify any place where the fallibility is clearly explained or why this would be a problem. there is an indirect mention by (a) and (b) in Motivation but should be more clear.

apenzk · 2024-10-28T12:52:38Z

MIP/mip-40/README.md

+
+## Abstract
+
+This MIP introduces the architectural guide for implementing ***AB-FFS Decoupled***, a means of using the Atomic Bridge and Fast-finality Settlement with a fixed supply of token. This decoupled approach relies on burning gas on the L2 into an L2 pool and issuing rewards in an LP token on the L1. Details of the L2 pool recirculation and the L1 LP token issuance are largely left to follow-on MIPs, however we do specify general constraints and guidelines. 


Suggested change

This MIP introduces the architectural guide for implementing ***AB-FFS Decoupled***, a means of using the Atomic Bridge and Fast-finality Settlement with a fixed supply of token. This decoupled approach relies on burning gas on the L2 into an L2 pool and issuing rewards in an LP token on the L1. Details of the L2 pool recirculation and the L1 LP token issuance are largely left to follow-on MIPs, however we do specify general constraints and guidelines.

This MIP introduces the architectural guide for implementing ***AB-FFS Decoupled***, a means of using the Atomic Bridge (AB) and Fast-finality Settlement (FFS) Postconfirmation. In this design Layer 1 (L1) is decoupled from Layer 2 (L2), in the sense that each layer has a respective token with a a constant supply each. This decoupled approach proposes to pay gas on the L2 into an L2 pool and distributing rewards through an LP token on the L1.

Details of the L2 pool recirculation and the L1 LP token issuance are largely left to follow-on MIPs, however we do specify general constraints and guidelines.

in brackets, say what the abbreviation LP stands for. you have not defined it.

fixed supply of token where? on L1, on L2 or on the combined L1+L2 token supply?

it seems weird to call this burned. are you sure this is the correct expression? burn is afaik related to an address that is not accessible anymore (hence burn). possibly "paying gas fees into L2 pool" is the more correct term?

burning gas = which token?

"Paying gas into L2 pool" is fine by me.

fixed supply of token where? on L1, on L2 or on the combined L1+L2 token supply?

Requirement is both.

i have implemented this in the suggestion above. please click accept if its ok

apenzk · 2024-10-28T13:09:47Z

MIP/mip-40/README.md

+1. The L1 staking token MUST be a unique token issued in a fixed supply.
+2. The L2 gas token MUST be a unique token issued in a fixed supply.
+3. Rewards issued via FFS MUST NOT be issued in the L1 staking token, but instead in an LP token on the L1.
+4. The LP Token MAY elect to maintain a supply or value correlated with the L1 staking token or the L2 gas token. But, this supply or value correlation MUST NOT rely on special capabilities of the LP token or trusted third parties.


the L1 staking token is fixed. hence there cannot be a correlation on supply (only that LP token supply it is constant which is not a correlation)

MUST NOT rely on special capabilities of the LP token or trusted third parties.

without an explanation of why you require this it should not be mentioned. or otherwise it should be explained why this requirement is needed.

the L1 staking token is fixed. hence there cannot be a correlation on supply (only that LP token supply it is constant which is not a correlation)

By correlating here, I mean that it in some way takes a parameter of the L1 or L2 token to parameterize itself. For example, if you take the AB-FFS Decoupled Grant approach and lock 1 billion L1 staking token in the voucher contract, you can decided to mint 1 billion LP token which can be redeemed for it.

apenzk · 2024-10-28T13:11:47Z

MIP/mip-40/README.md

+
+The *AB-FFS Decoupled* system is intended to address [MD-38](https://github.com/movementlabsxyz/MIP/pull/38). That is, *AB-FFS Decoupled* provides a means for using the Atomic Bridge and Fast-finality Settlement with a fixed supply of token. 
+
+Fundamentally, *AB-FFS Decoupled* contends with the fallibility of the Atomic Bridge by (a) removing any need for its involvement in returning funds to the L1 and (b) using intermediary tokens to avoid any locking, minting, burning, or other operations that would potentially modify the total supply of either the L1 staking token or the L2 staking token.


it should be explained why there is an L2 staking token.

This is a typo.

apenzk · 2024-10-28T13:12:25Z

MIP/mip-40/README.md

+4. The LP Token MAY elect to maintain a supply or value correlated with the L1 staking token or the L2 gas token. But, this supply or value correlation MUST NOT rely on special capabilities of the LP token or trusted third parties.
+5. The L2 staking token MUST be burned on the L2 to deposit gas into an L2 pool.
+
+If the LP Token supply is not fixed, the AB-FFS solution implemented is referred to as *AB-FFS Decoupled* Demurrage. [MIP-n](todo) provides a more complete specification for *AB-FFS Decoupled* Demurrage. 


Suggested change

If the LP Token supply is not fixed, the AB-FFS solution implemented is referred to as *AB-FFS Decoupled* Demurrage. [MIP-n](todo) provides a more complete specification for *AB-FFS Decoupled* Demurrage.

If the LP Token supply is not fixed, the AB-FFS solution implemented is referred to as ***AB-FFS Decoupled Demurrage***. [MIP-n](todo) provides a more complete specification for *AB-FFS Decoupled Demurrage*.

apenzk · 2024-10-28T13:13:14Z

MIP/mip-40/README.md

+
+If the LP Token supply is not fixed, the AB-FFS solution implemented is referred to as *AB-FFS Decoupled* Demurrage. [MIP-n](todo) provides a more complete specification for *AB-FFS Decoupled* Demurrage. 
+
+Otherwise, the AB-FFS solution implemented implemented is referred to as *AB-FFS Decoupled* Grant. [MIP-n](todo) provides a more complete specification for *AB-FFS Decoupled* Grant.


Suggested change

Otherwise, the AB-FFS solution implemented implemented is referred to as *AB-FFS Decoupled* Grant. [MIP-n](todo) provides a more complete specification for *AB-FFS Decoupled* Grant.

Otherwise, the AB-FFS solution implemented implemented is referred to as ***AB-FFS Decoupled Grant***. [MIP-n](todo) provides a more complete specification for *AB-FFS Decoupled Grant*.

apenzk · 2024-10-28T14:05:19Z

MIP/mip-40/README.md

+A more complete proposal for the usage of intermediary tokens is provided in [MIP-n](todo).
+
+### Genesis
+[MD-38](https://github.com/movementlabsxyz/MIP/pull/38) requests provisions for genesis for any system addressing its desiderata. The genesis for *AB-FFS Decoupled* is not fully specified in this MIP and such full specification is provided under [MIP-n](todo). However, generally, there are two strategies for genesis:


AB-FFS Decoupled is not fully specified

what is missing: either list it here, or point towards where does it say in this file what is missing.

MD-38 requests provisions for genesis for any system addressing its desiderata.

requires to be more specific. what does this mean in this context in one sentence?

requires to be more specific. what does this mean in this context in one sentence?

MD-38.D4 requests that the any document proposing against its desiderata also specify a means for initializing the system.

apenzk · 2024-10-28T14:13:22Z

MIP/mip-40/README.md

+2. **Genesis Bridge Transfer**: mint the L1 staking or L2 gas token in a fixed supply and transfer the other token from the L1 to the L2 s.t. a successful bridge transfer occurs before the system is operational.
+
+### On the Nature of the Tokens
+Fundamentally, the L1 staking and L2 gas token in an *AB-FFS Decoupled* system are independent, i.e., not constituting a representation of the same token redeemable on different chains. The comprise two closed token systems where assets cannot be lost or gained.


sentence not clear. do you mean that this results in two separate closed token systems, where the total token supply accross both systems remains fixed?

The total supply in each remains fixed, which implies the supply across both remains fixed.

ok i actually have a more fundamental issue here: the LP token has to have a value that is related to the cost of running postconfirmation (not FFS! since FFS-L2confirmation likely has to be rewarded by L2MOVE).

L1MOVE has value since it is directly linked (1-1 swap - bridge - 1-1 swap) to L2MOVE, which is used for gas

but why would LPStakingToken have value?

apenzk · 2024-10-28T14:15:24Z

MIP/mip-40/README.md

+### On the Nature of the Tokens
+Fundamentally, the L1 staking and L2 gas token in an *AB-FFS Decoupled* system are independent, i.e., not constituting a representation of the same token redeemable on different chains. The comprise two closed token systems where assets cannot be lost or gained.
+
+The usage of *AB-FFS Decoupled* is then suitable for systems wherein the governing body wishes to prioritize the security of the total supply of the staking tokens. To the extent the governing body wishes for the economics of the L1 staking token and L2 gas token to remain correlated, the governing body shall make efforts to peg the value of the L1 LP token to the L1 staking token.


i think what would be very helpful for the sake of reading this document is to use L1StakingToken and L2GasToken instead of mixing it into the text.

This change was made.

apenzk · 2024-10-28T14:17:08Z

MIP/mip-40/README.md

+
+The usage of *AB-FFS Decoupled* is then suitable for systems wherein the governing body wishes to prioritize the security of the total supply of the staking tokens. To the extent the governing body wishes for the economics of the L1 staking token and L2 gas token to remain correlated, the governing body shall make efforts to peg the value of the L1 LP token to the L1 staking token.
+
+In the case that *AB-FFS Decoupled* Grant is implemented, FFS shall require a new token generation event at some point determined by the size of the grant. Thus, FFS has a lifespan w.r.t. to the L1 staking token. This lifespan is further detailed in [MIP-n](todo).


Suggested change

In the case that *AB-FFS Decoupled* Grant is implemented, FFS shall require a new token generation event at some point determined by the size of the grant. Thus, FFS has a lifespan w.r.t. to the L1 staking token. This lifespan is further detailed in [MIP-n](todo).

In the case that *AB-FFS Decoupled Grant* is implemented, FFS shall require a new token generation event at some point determined by the size of the grant. Thus, FFS has a lifespan w.r.t. to the L1 staking token. This lifespan is further detailed in [MIP-n](todo).

apenzk · 2024-10-28T14:17:42Z

MIP/mip-40/README.md

+
+In the case that *AB-FFS Decoupled* Grant is implemented, FFS shall require a new token generation event at some point determined by the size of the grant. Thus, FFS has a lifespan w.r.t. to the L1 staking token. This lifespan is further detailed in [MIP-n](todo).
+
+In the case that *AB-FFS Decoupled* Demurrage is implemented, the value of L1 LP Token shall tend to zero over time. This may also be remedies by new token generation events. This phenomenon is further detailed in [MIP-n](todo).


Suggested change

In the case that *AB-FFS Decoupled* Demurrage is implemented, the value of L1 LP Token shall tend to zero over time. This may also be remedies by new token generation events. This phenomenon is further detailed in [MIP-n](todo).

In the case that *AB-FFS Decoupled Demurrage* is implemented, the value of L1 LP Token shall tend to zero over time. This may also be remedies by new token generation events. This phenomenon is further detailed in [MIP-n](todo).

There are several battle-tested bridge designs. None of them have this issue of supply tending to zero.
It is not because you "burn" tokens on the L2 that there is an issue.
On the L2 you have an infinite supply of L2 tokens, what matters is that users holding(L2MOVE) on L2 are equal to what is locked in the bridge contract on L1 (L1MOVE).
This is the lock-mint bridge design, the simplest to implement.

None of them have this issue of supply tending to zero. It is not because you "burn" tokens on the L2 that there is an issue. On the L2 you have an infinite supply of L2 tokens...

Burning tokens on the L2 as gas without minting certainly means your will tend towards zero. We don't have an infinite supply unless we are allowed to make something else our gas token.

On the L2 you have an infinite supply of L2 tokens, what matters is that users holding(L2MOVE) on L2 are equal to what is locked in the bridge contract on L1 (L1MOVE).

I've explained why we can't guarantee this.

This is the lock-mint bridge design, the simplest to implement.

Yes, but we don't have an architecture which supports doing this while having a fixed supply, secure settlement, and sybil resistant gas.

apenzk · 2024-10-28T17:29:28Z

MIP/mip-40/README.md

@@ -0,0 +1,83 @@
+# MIP-40: *AB-FFS Decoupled*


this is not FFS. It is Postconfirmation (MCR is an instantiation of postconfirmation)

FFS = Postconfirmation AND L2-confirmation, which are potentially two different protocols.

MIP/MIP/mip-34/README.md

Line 69 in 4ac00e0

**L2-finality certificate**. When enough validators have attested for a new block $B'$, the block is _L2-final_ (i.e. _L2-confirmed_). The accumulation of enough votes is aggregated in an L2-finality certificate. A naive implementation of the L2-finality certificate is a list of votes.

Above are you referring to the title? This is a shorthand for referring to a system that uses both the Atomic Bridge and Fast Finality Settlement.

Yeh imo this should be postconfirmation not FFS. The AB-FFS does not address L2-confirmations

apenzk · 2024-10-28T21:08:24Z

MIP/mip-40/README.md

+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+


there is a DEX in the figure. but there is no mention of DEX in this document. The DEX should be either removed from the figure or explained and linked.

if there is a DEX, what it is doing? What are the pairs that are traded on the DEX?
How do we get conversion rates? Do we use external oracles?

See MIP-41 for one proposal

franck44 · 2024-10-28T23:47:52Z

MIP/mip-40/README.md

+
+## Abstract
+
+This MIP introduces the architectural guide for implementing ***AB-FFS Decoupled***, a means of using the Atomic Bridge and Fast-finality Settlement with a fixed supply of token. This decoupled approach relies on burning gas on the L2 into an L2 pool and issuing rewards in an LP token on the L1. Details of the L2 pool recirculation and the L1 LP token issuance are largely left to follow-on MIPs, however we do specify general constraints and guidelines. 


The bridge and FFS should not be coupled.
There are two instances of MOVE tokens: L1MOVE and L2MOVE.
L1MOVE is the native token on L1, an ERC-20, and this is the currency in which validators are rewarded.
L2MOVE is the wrapped MOVE on L2. It is incidentally the token we use to charge gas, but it is not coupled to a Gas Token. I suggest looking at this PR #39 to get an idea how a bridge looks like.

The point of this, MD-38, and subsequent proposals is that we have a supply issue which needs to be resolved to maintain a fixed supply.

Where does the L2MOVE go when it is used as gas?: This MIP says it goes back into a pool on the L2.

From where does FFS source its rewards?: This MIP says it is issued as an LP token.

The reason it is called decoupled is because none of these systems are forced to rely on each other in this arrangement.

I don't need to relay burned gas to reward the operators in FFS. I don't need L1StakingToken in FFS to issue rewards.

franck44 · 2024-10-28T23:50:37Z

MIP/mip-40/README.md

+
+This MIP introduces the architectural guide for implementing ***AB-FFS Decoupled***, a means of using the Atomic Bridge and Fast-finality Settlement with a fixed supply of token. This decoupled approach relies on burning gas on the L2 into an L2 pool and issuing rewards in an LP token on the L1. Details of the L2 pool recirculation and the L1 LP token issuance are largely left to follow-on MIPs, however we do specify general constraints and guidelines. 
+
+We also propose the usage of intermediary tokens for bridging to fully decouple the L1 and L2 systems. This allows for the L2 pool to be recirculated without the need for a direct bridge to the L1 and exposure to fallibility of the bridge on either side. 


We do not need intermediary tokens.
The mechanics of charging fees on L2 and rewarding validators on L1 are independent from the bridge.
On L1, you can do whatever you want with the ERC-20 MOVE, it is not bound to rewarding validators.
On L2, it is the same, it is the wrapped token that users can exchange if they want, and one usage is to pay for transaction fees.

We can't do whatever we want with ERC-20 MOVE. For example, we can't mint more of it.

We also can't mint more of the L2 token.

franck44 · 2024-10-28T23:53:12Z

MIP/mip-40/README.md

+
+The *AB-FFS Decoupled* system is intended to address [MD-38](https://github.com/movementlabsxyz/MIP/pull/38). That is, *AB-FFS Decoupled* provides a means for using the Atomic Bridge and Fast-finality Settlement with a fixed supply of token. 
+
+Fundamentally, *AB-FFS Decoupled* contends with the fallibility of the Atomic Bridge by (a) removing any need for its involvement in returning funds to the L1 and (b) using intermediary tokens to avoid any locking, minting, burning, or other operations that would potentially modify the total supply of either the L1 staking token or the L2 staking token.


So how many different tokens do we have now?
What are the staking tokens? Validators stake L1MOVE and get L1MOVE rewards.
There should only be two tokens L1MOVE and L2MOVE.
Safeguards can be added to the MOVE ERC-20 and MOVE FA on L2.

Under this proposal, validators stake the L1 staking token (L1MOVE) and get an LP token (not named).

How are you going to ensure the fixed supply we are now required to maintain? If the bridge fails, the supply can increase or decrease.

How are you going to ensure the fixed supply we are now required to maintain? If the bridge fails, the supply can increase or decrease.

this solution does not solve this problem

on both L1 and L2 the max supply of L1MOVE and L2MOVE should be capped at MOVE_max ( this seems a natural restriction)

if the bridge works sum(L1MOVE supply, L2MOVE supply) = MOVE_max (L2MOVE = gas token)

if the bridge gets compromised an adversary can empty the DEX on both L1 and L2 and bring into circulation 2x MOVE_max

This is the same for a direct bridge L1MOVE <> L2MOVE, if we can implement a mint restriction that checks the total supply on L2 (similar for L1)

Hence this protocol does not seem to solve the problem it attempts to solve.

franck44 · 2024-10-28T23:56:31Z

MIP/mip-40/README.md

+### Genesis
+[MD-38](https://github.com/movementlabsxyz/MIP/pull/38) requests provisions for genesis for any system addressing its desiderata. The genesis for *AB-FFS Decoupled* is not fully specified in this MIP and such full specification is provided under [MIP-n](todo). However, generally, there are two strategies for genesis:
+
+1. **Separate Mints**: mint the L1 staking token and the L2 gas token simultaneously in fixed supplies amounting to the intended total supply.


We don't need one token per usage, for gas or staking.
There is a currency to pay transaction fees and staking, MOVE.
Introducing seperate minst and tokens is very confusing and unsafe. I don't know of any other bridges that does the same thing.

I need you to explain how this is unsafe precisely. It's the difference of bridging one token or the other. As I have argued before, I don't see how requiring a swap for the gas token can be more dangerous than having the token be generally tradable. There will be other swaps.

Some dangers w.r.t. attempting to peg L1 and L2 tokens are described in MIP-41.

apenzk · 2024-10-29T08:29:37Z

MIP/mip-40/README.md

+We also propose the usage of intermediary tokens for bridging to fully decouple the L1 and L2 systems. This allows for the L2 pool to be recirculated without the need for a direct bridge to the L1 and exposure to fallibility of the bridge on either side. 
+
+Without the usage of intermediary tokens, we refer to this system as ***AB-FFS Partially Decoupled***, for which we do not intend a separate MIP. 
+


Suggested change

## Definitions

- `MOVE` : ERC-20 token on L1

- `L2MOVE` : Gas token on L2, any standard???

- `LPtoken` : ???

- `L1BridgeToken` : ERC-20 token on L1

- `L2BridgeToken` ???

apenzk · 2024-10-29T08:42:49Z

MIP/mip-40/README.md

+2. The L2 gas token MUST be a unique token issued in a fixed supply.
+3. Rewards issued via FFS MUST NOT be issued in the L1 staking token, but instead in an LP token on the L1.
+4. The LP Token MAY elect to maintain a supply or value correlated with the L1 staking token or the L2 gas token. But, this supply or value correlation MUST NOT rely on special capabilities of the LP token or trusted third parties.
+5. The L2 staking token MUST be burned on the L2 to deposit gas into an L2 pool.


this seems to use incorrectly industry-terminology. if the L2 token is used as gas and moved into an L2 pool that can be recirculated this should not be called burning.

how about calling it "recycled", "recaptured", "retained" ?

l-monninger added 2 commits October 28, 2024 11:16

feat: ab-ffs-decoupled.

6e6e8ab

feat: demurrage.

e2585c8

l-monninger requested a review from apenzk as a code owner October 28, 2024 10:44

fix: clarify correlation requirements.

f86cdf9

apenzk changed the title ~~MIP-N: AB-FFS Decoupled~~ [draft] MIP-N: AB-FFS Decoupled Oct 28, 2024

apenzk added 4 commits October 28, 2024 13:25

Merge branch 'main' into l-monninger/ab-ffs-decoupled

63d953d

update codeowners

387073a

change folder name

84b0b6d

highlight the name of the system

8e0d8a4

apenzk requested changes Oct 28, 2024

View reviewed changes

apenzk changed the title ~~[draft] MIP-N: AB-FFS Decoupled~~ [draft] MIP-40: AB-FFS Decoupled Oct 28, 2024

apenzk reviewed Oct 28, 2024

View reviewed changes

franck44 reviewed Oct 28, 2024

View reviewed changes

apenzk reviewed Oct 29, 2024

View reviewed changes

native bridge renaming

28bad1a

apenzk changed the title ~~[draft] MIP-40: AB-FFS Decoupled~~ [draft] MIP-40: NB-FFS Decoupled Nov 22, 2024

apenzk added bridge and removed bridge labels Nov 25, 2024

franck44 added check_for_outdated Draft MD/MIP A new/draft MD/MIP labels Dec 17, 2024


		## Abstract

		This MIP introduces the architectural guide for implementing *AB-FFS Decoupled*, a means of using the Atomic Bridge and Fast-finality Settlement with a fixed supply of token. This decoupled approach relies on burning gas on the L2 into an L2 pool and issuing rewards in an LP token on the L1. Details of the L2 pool recirculation and the L1 LP token issuance are largely left to follow-on MIPs, however we do specify general constraints and guidelines.


		The AB-FFS Decoupled system is intended to address [MD-38](https://github.com/movementlabsxyz/MIP/pull/38). That is, AB-FFS Decoupled provides a means for using the Atomic Bridge and Fast-finality Settlement with a fixed supply of token.

		Fundamentally, AB-FFS Decoupled contends with the fallibility of the Atomic Bridge by (a) removing any need for its involvement in returning funds to the L1 and (b) using intermediary tokens to avoid any locking, minting, burning, or other operations that would potentially modify the total supply of either the L1 staking token or the L2 staking token.

	If the LP Token supply is not fixed, the AB-FFS solution implemented is referred to as AB-FFS Decoupled Demurrage. [MIP-n](todo) provides a more complete specification for AB-FFS Decoupled Demurrage.
	If the LP Token supply is not fixed, the AB-FFS solution implemented is referred to as *AB-FFS Decoupled Demurrage. [MIP-n](todo) provides a more complete specification for AB-FFS Decoupled Demurrage*.


		If the LP Token supply is not fixed, the AB-FFS solution implemented is referred to as AB-FFS Decoupled Demurrage. [MIP-n](todo) provides a more complete specification for AB-FFS Decoupled Demurrage.

		Otherwise, the AB-FFS solution implemented implemented is referred to as AB-FFS Decoupled Grant. [MIP-n](todo) provides a more complete specification for AB-FFS Decoupled Grant.


		The usage of AB-FFS Decoupled is then suitable for systems wherein the governing body wishes to prioritize the security of the total supply of the staking tokens. To the extent the governing body wishes for the economics of the L1 staking token and L2 gas token to remain correlated, the governing body shall make efforts to peg the value of the L1 LP token to the L1 staking token.

		In the case that AB-FFS Decoupled Grant is implemented, FFS shall require a new token generation event at some point determined by the size of the grant. Thus, FFS has a lifespan w.r.t. to the L1 staking token. This lifespan is further detailed in [MIP-n](todo).

	In the case that AB-FFS Decoupled Grant is implemented, FFS shall require a new token generation event at some point determined by the size of the grant. Thus, FFS has a lifespan w.r.t. to the L1 staking token. This lifespan is further detailed in [MIP-n](todo).
	In the case that AB-FFS Decoupled Grant is implemented, FFS shall require a new token generation event at some point determined by the size of the grant. Thus, FFS has a lifespan w.r.t. to the L1 staking token. This lifespan is further detailed in [MIP-n](todo).


		In the case that AB-FFS Decoupled Grant is implemented, FFS shall require a new token generation event at some point determined by the size of the grant. Thus, FFS has a lifespan w.r.t. to the L1 staking token. This lifespan is further detailed in [MIP-n](todo).

		In the case that AB-FFS Decoupled Demurrage is implemented, the value of L1 LP Token shall tend to zero over time. This may also be remedies by new token generation events. This phenomenon is further detailed in [MIP-n](todo).

	In the case that AB-FFS Decoupled Demurrage is implemented, the value of L1 LP Token shall tend to zero over time. This may also be remedies by new token generation events. This phenomenon is further detailed in [MIP-n](todo).
	In the case that AB-FFS Decoupled Demurrage is implemented, the value of L1 LP Token shall tend to zero over time. This may also be remedies by new token generation events. This phenomenon is further detailed in [MIP-n](todo).

		## Specification

		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.


		This MIP introduces the architectural guide for implementing *AB-FFS Decoupled*, a means of using the Atomic Bridge and Fast-finality Settlement with a fixed supply of token. This decoupled approach relies on burning gas on the L2 into an L2 pool and issuing rewards in an LP token on the L1. Details of the L2 pool recirculation and the L1 LP token issuance are largely left to follow-on MIPs, however we do specify general constraints and guidelines.

		We also propose the usage of intermediary tokens for bridging to fully decouple the L1 and L2 systems. This allows for the L2 pool to be recirculated without the need for a direct bridge to the L1 and exposure to fallibility of the bridge on either side.

		We also propose the usage of intermediary tokens for bridging to fully decouple the L1 and L2 systems. This allows for the L2 pool to be recirculated without the need for a direct bridge to the L1 and exposure to fallibility of the bridge on either side.

		Without the usage of intermediary tokens, we refer to this system as *AB-FFS Partially Decoupled*, for which we do not intend a separate MIP.

+## Definitions
+- `MOVE` : ERC-20 token on L1
+- `L2MOVE` : Gas token on L2, any standard???
+- `LPtoken` : ???
+- `L1BridgeToken` : ERC-20 token on L1
+- `L2BridgeToken` ???

[draft] MIP-40: NB-FFS Decoupled #40

Are you sure you want to change the base?

[draft] MIP-40: NB-FFS Decoupled #40

Conversation

l-monninger commented Oct 28, 2024 • edited by apenzk Loading

Summary

apenzk left a comment • edited Loading

Choose a reason for hiding this comment

apenzk Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

l-monninger Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apenzk Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

apenzk Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apenzk Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

l-monninger Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apenzk Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apenzk Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

l-monninger commented Oct 28, 2024 •

edited by apenzk

Loading

apenzk left a comment •

edited

Loading

apenzk Oct 28, 2024 •

edited

Loading

l-monninger Oct 29, 2024 •

edited

Loading

apenzk Oct 29, 2024 •

edited

Loading

apenzk Oct 28, 2024 •

edited

Loading

apenzk Oct 28, 2024 •

edited

Loading

l-monninger Oct 28, 2024 •

edited

Loading

apenzk Oct 29, 2024 •

edited

Loading

apenzk Oct 29, 2024 •

edited

Loading