Implementation

JBP-208: Allow Juicebox DAO v2 treasury to set a new terminal for V1 token exchanges

Author

Anon

Cycle

25

loading

Title: Allow Juicebox DAO v2 treasury to set a new terminal for V1 token exchanges
Author: jango.eth
Date: 2022-06-17

Thesis:

We’re looking to start v1 JBX ⇒ v2 JBX exchanges.

In order to do so, we need to give ourselves to ability to attach a new payment terminal to our v2 treasury. This is a allowSetTerminals flag in funding cycle metadata that needs to be set to true. Once this reconfiguration takes effect, we need to send a tx to set the terminal, and send a tx in the terminal to specify that we are willing to accept v1 JBX in exchange for v2 JBX.

We’ve also yet to issue a v2 JBX. We can do so at any time once this proposal passes. In the time being, our v2 tokens will continue being tracked in the JBTokenStore.

As the v1 v2 token parity is granted, the snapshot strategy would then be adapted, allowing v2 token holder to have the same voting power as v1 holders (total voting power would be cumulative).

Abstract:

We have a payment terminal in place that projects can attach if they wish to receive their v1 tokens in exchange for their v2 tokens. In order to attach the terminal, projects must explicitly allow setting new terminals to their project.

This proposal is for JuiceboxDAO to explicitly set this flag to true, to attach the terminal, and to begin accepting v1 JBX in exchange for v2 JBX.

Motivation:

We’ve finished writing, reviewing, testing, and documenting a payment terminal to accept v1 tokens in exchange for v2 tokens. Any project that is on both v1 and v2 can use this. Time to attach it and get the tokens flowing through.

Risks:

Whenever we’re deploying new contracts and prompting people to interact with them, we are opening up smart contract risk vectors assumed by token holders. Tests, documentation, and a simple to use user interface should mitigate these risks.

Specification:

Reconfiguration for FC#25:

  • set the allowSetTerminals metadata property to true.

During FC#25:

  • Send the setV1ProjectId on the JBV1TokenPaymentTerminal.
  • Call JBDirectory.setTerminalsOf(...) to include the current ETH payment terminal and the V1 token terminal.

Anytime once the proposal passes:

  • Issue v2 JBX ERC20 token.
  • Add the v2 JBX balance to the current snapshot strategy (add a second contract-call to JBTokenStore.balanceOf(voter, 1) in the current Snapshot delegate strategy)

Rationale:

All steps are standard operating procedure for attaching a new terminal.

The only opinionated step is to issue V2 JBX ERC-20s, which we do not have to do. The reason for doing so would be to allow for similar functionality as we had with v1 JBX, but we could postpone this decision.

Timeline:

See specs.

Votes

loading