Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion .github/CODEOWNERS
Original file line number Diff line number Diff line change
Expand Up @@ -12,5 +12,7 @@

/MD/md-3/ @l-monninger

/MIP/mip15/ @l-monninger @apenzk
/MIP/mip-15/ @l-monninger @apenzk
/MD/md-15/ @l-monninger @apenzk

/MIP/mip-40/ @l-monninger @apenzk
83 changes: 83 additions & 0 deletions MIP/mip-40/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
# MIP-40: *NB-FFS Decoupled*
- **Description**: Introduces architectural guide for ***NB-FFS Decoupled***.
- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz)
- **Reviewer**: [Andreas Penzkofer](mailto:andreas.penzkofer@movementlabs.xyz)
- **Desiderata**: [MD-38](https://github.com/movementlabsxyz/MIP/pull/38)

## Abstract

This MIP introduces the architectural guide for implementing ***NB-FFS Decoupled***, a means of using the Native 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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. We can't do whatever we want with ERC-20 MOVE. For example, we can't mint more of it.
  2. We also can't mint more of the L2 token.


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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the number of involved tokens confuses the reading. A section "## Definitions" that lists the different token types should be added before the #Motovation section.

@apenzk apenzk Oct 29, 2024

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

## Motivation

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

Fundamentally, *NB-FFS Decoupled* contends with the fallibility of the Native 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.

*NB-FFS Partially Decoupled* still removes the need for the Native Bridge to return funds to the L1, but does not protect the total supply from all bridge failures. Hence *NB-FFS Partially Decoupled* is not a sound solution for [MD-38](https://github.com/movementlabsxyz/MIP/pull/38).

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See MIP-41 for one proposal

![*NB-FFS Decoupled*](./ab-ffs-decoupled.png)

An *NB-FFS Decoupled* system is defined by the following requirements:

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

5. The L2 staking token MUST be burned on the L2 to deposit gas into an L2 pool.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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" ?


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

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

### L1 LP Token
1. The L1 LP Token MUST NOT enshrine any special capabilities to mint or otherwise unlock the L1 staking token. That is, the L1 LP token must be independent of the L1 staking token and only effectively be used to purchase the L1 staking token.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

special capabilities is too vague. an MIP should not support ambiguousness. do you mean "MUST NOT enshrine the option to mint or unlock ..."

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is to preclude any kind of capabilities which would allow minting or unlocking token, at all, as any form of side-effect.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
1. The L1 LP Token MUST NOT enshrine any special capabilities to mint or otherwise unlock the L1 staking token. That is, the L1 LP token must be independent of the L1 staking token and only effectively be used to purchase the L1 staking token.
1. The L1 LP Token MUST be designed such that it cannot be directly used to mint or otherwise unlock the L1 staking token. That is, the L1 LP token must be independent of the L1 staking token and only effectively be used to purchase the L1 staking token.

how about this?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
1. The L1 LP Token MUST NOT enshrine any special capabilities to mint or otherwise unlock the L1 staking token. That is, the L1 LP token must be independent of the L1 staking token and only effectively be used to purchase the L1 staking token.
1. The L1 LP Token MUST NOT enshrine any special capabilities to mint or otherwise unlock the L1 staking token. The L1 LP token MUST be independent of the L1 staking token and only effectively be used to purchase the L1 staking token.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and only effectively be used to purchase the L1 staking token

not clear. do you mean

  • L1 LP token can only be used to exchange for L1 staking token? this is not gonna work. if it has value a market will evolve.
  • L1 LP should not have any enshrined dependency?

need to clarify what "independent" means

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is outdated.

2. The governing system MAY provide vouchers or other means of redeeming the L1 LP token for the L1 staking token from a dedicate allocation. The object of these vouchers SHOULD be to peg the value of the L1 LP token to the L1 staking token.

A more complete proposal for the usage L1 LP tokens with FFS is provided in [MIP-n](todo).

### L2 Token Pool (Gas Pool)
1. Burning gas an amount of gas $\alpha$ on the L2 MUST result in depositing that same amount of gas $\alpha$ into an L2 pool.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sentence errors

@apenzk apenzk Oct 28, 2024

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the gas token, is it L2MOVE?

2. The L2 pool MUST be recirculated to the L2 users in a manner that is not specified in this MIP. Generally, this means the L2 pool must either be used to issue rewards or otherwise be a reliable means of purchasing gas token on the L2.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
2. The L2 pool MUST be recirculated to the L2 users in a manner that is not specified in this MIP. Generally, this means the L2 pool must either be used to issue rewards or otherwise be a reliable means of purchasing gas token on the L2.
2. The content of the L2 pool MUST be recirculated to the L2 users (but the specification of the recirculation is not specified in this MIP). For example, the L2 pool could be used to issue rewards or provide a reliable means of purchasing gas tokens (on L2).


A system adhering to these requirements is referred to as a Gas Pool. A more complete proposal for the usage of Gas Pools is provided in [MIP-n](todo).

### Intermediary Tokens
1. A complete implementation of *NB-FFS Decoupled* SHOULD use intermediary tokens to bridge the L1 and L2 systems. An implementation not using intermediary tokens is referred to as *NB-FFS Partially Decoupled*.
2. The intermediary tokens MAY manage their own exchange rates, markets, and fees between each other, the L1 staking token, the L2 staking token, and the L1 LP token.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

## Reference Implementation

## Verification



## Errata


## Appendix
Binary file added MIP/mip-40/ab-ffs-decoupled.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.