RFC Formalizing Multichain Deployment Process

General Proposal RFC
1

2023-02-01T16:57:00Z→2023-02-07T16:58:00Z

Title: RFC Multichain Deployment Process

Author(s): @Bobbay_StableLab, @Matt_StableNode

Related Discussions:

Submission Date: 2/1/2023

Simple Summary:

This proposal introduces the “Multichain Deployment Process” to provide a framework and process to deploy Euler on other chains.

Abstract:

This proposal introduces a “Multichain Deployment Process” as a method to formalize proposals regarding Euler deploying to new chains. This will provide a clear and organized pathway for new chains to be reviewed for deployment.

Motivation:

With recent forum posts, there is a motivation to deploy Euler on other chains, and we need to introduce a framework to standardize this process. In the current state, there will be a lot of discrepancies between the applications, with some providing too little or unnecessary information. As a community, we can refine this template to request the relevant information for the community to make an informed decision.

Specification/Body Text:

Multichain deployment Outline

  1. Preamble

  2. Specification

  3. Non-technical evaluation

  4. Rationale

  5. Expected Impact

  6. Security Considerations

  7. Bridging

  8. Process

Multi-chain deployment Template

Preamble:

Title:

Type: Multichain Deployment

Description:

Author:

Specification

Point of contact(POC):

This will be the POC through which Euler Community will request further information.

Proposal Summary:

One-sentence summary.

Overview of Proposal:

Description of the proposal, including timeline, team, and benefits to Euler

Motivation:

How does this proposal benefit the Euler ecosystem? Why is the proposed chain ideal for Euler? What solutions does it provide to users?

Grant Application:

Did you apply for an Euler Grant? (Approved/ Rejected/ Did not apply)

Non-Technical Evaluation

  1. TVL on the Chain
  2. Amount of protocols on the chain
  3. (#) of unique addresses on the chain
  4. (#)of new users joining in the past 90 days
  5. (#) of unique addresses executing a transaction in the past 30,60 and 90 days.
  6. Average gas fee in the past 30 days

Rationale

Why did you choose this specific chain? What benefits does it provide over other chains? Do you have support (foundation or grant)? Will any incentives be provided to attract users?

Expected impact

Explain the potential benefits you expect by deploying Euler on your chain of choice. What TVL do you anticipate?

Bridging

Will you be using a native bridge or a third party for cross-chain messaging? Provide a rationale for your choice.

Security Considerations

What technicalities are required to deploy on the chain? Are they available? E.g. Price feed, oracles, etc.

Security Considerations

Discuss the security implications/considerations relevant to deploying on your chain of choice.

Other considerations

Who will be responsible for the initial deployment of Euler?

Process

  1. Post a forum post using the multichain deployment template
  2. TBD will complete a technical evaluation.
  • Once an evaluation has been completed, the proposal can go to vote two days later.
  • This should take a maximum of 7 days.
  1. Move to a Snapshot vote

Rationale

Expanding to other Alt L1s and L2s has been a reoccurring discussion in Euler for the past couple of months. Euler Governance has the power to deploy Euler on another chain; therefore, token holders must have sufficient information to distribute this license.

In creating a multi-chain deployment guide, the Euler community should request a level of information that enables token holders to make an informed decision when choosing to deploy Euler on other chains. The non-technical evaluation provides enough information to gain a superficial understanding of the chain. A technical assessment, supplemented by TBD, will provide enough information to make an informed decision.

Expected Impact

Pros

  • This introduces an official process for authors to follow to deploy Euler on other Chains.
  • The community agrees on a standard evaluation template
  • Reduces discrepancies between applications

Cons

  • This makes the deployment process longer.
  • The amount of information requested might deter applicants.

Overall, the pros outweigh the cons as this introduces a sustainable process to deploy Euler on other chains.

Next steps

Gather community feedback to refine this process. Then push it to a Snapshot vote.

If this proposal passes, this will be recognized as the official process to deploy Euler on another chain. An author has to use the relevant template. Otherwise, the application will be considered void.

We recommend pinning the process up within the governance forums.

Relevant Links:

Poll:

  • Yes, in favor of the proposal
  • No, against the proposal
  • Modify the proposal

0 voters

2 Likes
2

I agree with this proposal. Euler seems to be discussing chain deployments in a haphazard manner. :grimacing:

2 Likes
3

Nicely written proposal. I think this would be a big improvement on the existing process, which feels a little rushed.

For something as big as a new deployment, I think the DAO should strive to make slow and steady decisions based on really clear criteria. This is definitely a big step in the right direction. Would love to hear more feedback on this.

Should anything else be added or removed? What would the assessment look like for success or failure for deployment on new networks? Would UI support for a deployment ever be deprecated?

There’s a lot more to these deployments than meets the eye. So robust analysis and debate over these issues should be strongly encouraged.

2 Likes
4

Nice one! Feels like its making processes longer but useful for standardization, will prove useful in time on saved resources etc. Very much “FOR” this kind of intentional slow processes that promotes discussion.

Some feedback that would be great addition(s) to this proposal (or pinned next to it):

This framework, frames “what needs to be discussed” but doesnt provide a north star in terms of where to aim, how to evaluate. That northstar definition doesnt need to be in this document itself but i’m sure people would like to refer to it when filling “rationale, expected impact” etc. Rationale should be from the perspective of Euler, and having a checklist to refer to would make things easier. What are the minimum viable user/network activity criterias Euler seeks before jumping on the road? I feel that kind of a reference point would also allow “proposers” to come with more aligned proposals with Euler’s mission too.

Also, overall its focused on engineering viability (rightfully so) but doesnt ask questions about market viability. Only place that market viability (from euler’s perspective) can come thru in the “Rationale” section. Should we define its own place & ask specific questions from our perspective? (eg: security consideration sub questions. but for money&liquidity) Given Euler is a money market i feel we can request some attention there too.

I think we can also add “targeted quarter” or similar? people keep commenting as if everything is first come first serve. Can be a moving date that is re-aligned/reposted as resources to deploy become clearer in the process.

Overall great proposal, all for it. But think it needs some feedback from other perspectives. Hence voted “Modify”. Hope it gets nice feedback and comes to life. It would be extra beneficial to guiding the convo on going multichain for Euler. Thanks for preparing it & opening for discussion.

3 Likes
5

Thanks Bobbay and Matt. Definitely need some structure in on this aspect.

Agree with my man @AliG :

This is super important. What’s the strategy for deploying on X? I don’t think Euler should be a copy pasta on each chain. As I mentioned before there should be something more specific, targeting specific assets on each. Oracles and liquidity will play a role.

Something akin to what @seraphim was saying here would work well. I would also be a fan of having some form of localised governance for each chain including the POC mentioned above. The POC should be a local rep from the chain/layer 2 in question. But this is a little outside the scope of this proposal.

In sum, it would be good to have an additional section on Deployment Strategy potentially after the Rationale section. It will then encourage discussions on this topic in the RFC.

3 Likes
6

This is all great feedback and especially in regard to the deployment strategy; it is better that it is discussed before the launch.

Some teams who wanted to deploy Aave on other chains like Celo, promised launch a rewards program for Aave on Celo to attract liquidity. I’m sure Euler could attract similar programs.

Screenshot 2023-02-02 at 15.36.12
Screenshot 2023-02-02 at 15.36.121502×320 47 KB

As a side note, we prefer to continue to receive community feedback and will make amendments before moving forward, regardless of whether it matches the temp check.

3 Likes
7

Building on your point, taking it a step back from an assessment perspective. It might be worth introducing an accountability committee that can help ensure the deployments of Euler on other chains are handled correctly.

I.e. Reward incentives for deploying on another chain, Reporting to Euler DAO, In-depth evaluation of the proposals to deploy euler on another chain etc.

8

Thanks for this proposal @Bobbay_StableLab ! It should have been discussed first before proceeding to concrete proposals on chains/l2, but anyway.

One minor comment on Specification

Point of contact(POC):

This will be the POC through which Euler Community will request further information.

Proposal Summary:

One-sentence summary.

Overview of Proposal:

That seems to be too much of a summary, Imo it will make the righting and reading exercise quite difficult. One summary seems to be enough. But that’s again not very substantial.

What is more important with Deploying on BSC chain is almost approved is that the DAO thoroughly examines the results of the process before moving to another chain. Probably, a certain period is needed to proceed to another discussion.

As for the governance, a local gov for each chain seems reasonable, however taking into account the current level of activity and involvement (including this proposal) I have doubts that we could afford even 2-3 local govs atm.

Finally, it could look slightly centralised, but I do believe that EulerLabs team should have a say here, more than in other situations. Since they will be responsible for deployment and all other stuff, success largely depends on them. And if they see no value in deploying on a particular chain, then the counter decision of the DAO is not enough. What I mean is that DAO’s decision does not guarantee passion and enthusiasm from devs

9

nice…

i’m looking forward to practising this soon, if possible!

10

Thank you stablenode for the suggestion.

This is a good point. The DAO would benefit from a body which can coordinate this as well as other deployments from grant seekers.

I would recommend adding some sort of decentralisation analysis/metric to this template. Here are some suggestions:
a. Measuring Blockchain Decentralization | Consensys Research | Consensys
b. Quantifying Decentralization. We must be able to measure blockchain… | by Balaji S. Srinivasan | news.earn.com
c. https://www.sciencedirect.com/science/article/pii/S2405959521000977

  1. While I agree that standardising this process is generally beneficial for the DAO, in the past when we were discussing creating different categories/templates for forum posts it was pointed out that this will make the process more complicated.

  2. The DAO should periodically review the cost of maintaining the app on each chain vs the returns it brings. Maybe the template itself could include some analytics on this.

11

@Raslambek Appreciate that. We will condense the 3 summaries into a single proposal.

Local governance requires a lot more bandwidth, and this might require the need for individual councils/working groups to handle each chain to make this more efficient. Even that this brings up the question of who should be in these working groups and how they should be compensated if we go down that rabbit hole.

We value everyone’s feedback and the EulerLabs team feedback / insight would be helpful here. I agree with your idea here and I don’t think it presents as centralized along as it all remains public on the forum.

1 Like
12

2- Feel free to present a decentralization metric that we can add to this forum post.
3 - Deploying Euler is a massive task. A process is necessary for the community to make an informed decision. Yes it makes the process longer and more complicated, but it brings an additional layer of information and security.
4- This would be separate to this, as this is purely a deployment process. You are describing an evaluation of this, which is definitely helpful, but would warrant its own, independent of this.

1 Like
13
  1. I would like to suggest something easy to start with and we can iterate from there. My suggestion is to have Nakamoto coefficient as the metric
  1. Yes and no. While I agree with your approach on evaluation post implementation, I also suggest some analysis pre implementation based on the existing stats in any chain.
    eg:

a. Cost of deployment
b. Expected time [in days] to recover initial investment (based on current chain volumes)

14
  1. I didn’t say that there should be an evaluation post implementation. We can add a section to this template to evaluate the cost of deployment, but for ongoing costs, that should be a separate template.

Cost of deployment is a fair one, but your 2nd point, would be tricky and a not a reliable source, since the space is volatile and always changing. We already have a non-technical evaluation of the chain, so we can add cost of deployment to that section.

Screenshot 2023-02-12 at 14.26.20
Screenshot 2023-02-12 at 14.26.201498×404 25.7 KB

Ideally, we can get other chains to fund a majority of the cost of deployment anyway but a template would be good!

1 Like
15

We have been tracking a majority of the feedback and will present the next iteration of this template sometime next week

1 Like
16

Title: Multichain Deployment Process

Author(s): @Bobbay_StableLab, @Matt_StableLab

Related Discussions:

Submission Date: 2/1/2023

Simple Summary:

This proposal introduces the “Multichain Deployment Process” to provide a framework and process to deploy Euler on other chains.

Abstract:

This proposal introduces a “Multichain Deployment Process” as a method to formalize proposals regarding Euler deploying to new chains. This will provide a clear and organized pathway for new chains to be reviewed for deployment.

Motivation:

With recent forum posts, there is a motivation to deploy Euler on other chains, and we need to introduce a framework to standardize this process. In the current state, there will be a lot of discrepancies between the applications, with some providing too little or unnecessary information. As a community, we can refine this template to request the relevant information for the community to make an informed decision.

Specification/Body Text:

This proposal will include a new template for multichain deployment, a new process for proposing new deployment, and a list of minimum requirements chains must meet to be considered.

Multi-chain deployment Template

Preamble:

Title:

Description:

Author/relation to the proposed chain:

Specification

Point of contact(POC):

This will be the POC at the proposed chain through which the Euler Community will request further information.

Overview of Proposal:

Description of the proposal, including timeline, team, and benefits to Euler

Motivation:

How does this proposal benefit the Euler ecosystem? Why is the proposed chain ideal for Euler? What solutions does it provide to users?

Grant Application:

Did you apply for an Euler Grant? (Approved/ Rejected/ Did not apply)

Non-Technical Evaluation

  1. TVL on the Chain
  2. Amount of protocols on the chain
  3. (#) of unique addresses on the chain
  4. (#)of new users joining in the past 90 days
  5. (#) of unique addresses executing a transaction in the past 30,60 and 90 days.
  6. Average gas fee in the past 30 days

Rationale

Why did you choose this specific chain? What benefits does it provide over other chains? Do you have support (foundation or grant)? Will any incentives be provided to attract users?

Market Fit

What other borrowing/lending markets already exist? What is their TVL? Why would Euler be a good addition? What TVL do you anticipate Euler to have?

Bridging

Will you use a native bridge or a third party for cross-chain messaging? Provide a rationale for your choice.

Deployment Details

What will be the expected deployment cost?

What is the expected timeline for deployment?

How will Euler need to change to deploy to the proposed chain?

can it use a permissionless oracle? Will permissionless listing be possible? Etc…

Will there need to be a chain-specific governance committee

How many people? What would they be responsible for? What are the requirements to be part of the committee?

Who will maintain the protocol after deployment?

Does the Euler Labs team need to dedicate more people to working on the new chain full-time?

How will the deployment be marketed?

Will the new chain help with promoting Euler’s deployment?

Technical Considerations

What technicalities are required to deploy on the chain? Are they available? E.g. Price feed, oracles etc.

Security Considerations

Discuss the security implications/considerations relevant to deploying on your chain of choice.

Decentralization Metrics

How many node operators are there? How distributed are node operators? How many addresses own 50% of the chain’s token? How many of these are foundation addresses?

Process

  1. Post a forum post using the multichain deployment template

  2. TBD will complete a technical evaluation.

  3. Once an evaluation has been completed, the proposal can go to vote two days later.

  4. This should take a maximum of 7 days.

  5. Meanwhile the community can ask questions and make comments on the proposal

  6. After technical evaluation and community comments, the proposal will be moved to the formal submission stage. It will be reposted as a new comment under the same thread with the appropriate changes. This will last for 2 days

  7. Move to a Snapshot vote

Minimum Standards

These are the minimum requirements a chain must meet to be considered for deployment.

TBD by Community

  1. At least $100M in TLV
  2. At least $5M in daily volume
  3. At least 5,000 daily active users
  4. A strong oracle or new governance system in place to manage asset tiers/listings

(These standards can’t be applied to deployments on testnet.)

These standards are up for discussion and can be amended.

Rationale

Expanding to other Alt L1s and L2s has been a reoccurring discussion in Euler for the past couple of months. Euler Governance has the power to deploy Euler on another chain; therefore, token holders must have sufficient information to distribute this license.

In creating a multi-chain deployment guide, the Euler community should request a level of information that enables token holders to make an informed decision when choosing to deploy Euler on other chains. The non-technical evaluation provides enough information to gain a superficial understanding of the chain. A technical assessment, supplemented by TBD, will provide enough information to make an informed decision.

Expected Impact

Pros

  • This introduces an official process for authors to follow to deploy Euler on other Chains.
  • The community agrees on a standard evaluation template
  • Reduces discrepancies between applications

Cons

  • This makes the deployment process longer.
  • The amount of information requested might deter applicants.

Overall, the pros outweigh the cons as this introduces a sustainable process to deploy Euler on other chains.

Next steps

Gather community feedback to refine this process, discuss minimum standards chains must meet, and discuss the possibility of a working group to help manage this process. Then push this proposal to a Snapshot vote.

If this proposal passes, this will be recognized as the official process to deploy Euler on another chain. An author has to use the relevant template. Otherwise, the application will be considered void.

We recommend pinning the process up within the governance forums.

Relevant Links:

1 Like
17

This is our latest version of the “Multichain Deployment Process” however we would still appreciate community feedback on certain aspects such as:

  1. Who can complete a technical evaluation of the chain?
  2. If we want governance committees for specific chains, how do we want to elect them and how many ? Are they compensated?
  3. Opinions on the standards when deploying to a new chain?
  4. Does Euler want to deploy on testnets like zkconsensys evm and how should that be evaluated compared to mainnet?

This won’t be moving for a vote soon, we still want to hear from the community before moving forward, specifically how they want to tackle cross-chain governance with these cross-chain working groups.

18

Great proposal @Bobbay_StableLab. The framework reads well.

Incentives/Support provided by the chain to be deployed on can be moved to its own sub-section in the template.

Considering that there is considerable cost in terms of time and resource, and multiple chains which would benefit from Euler to be deployed on them, think as a dao, we should look to extract maximum support for each chain deployment.

19

Not a fan of 2. Governance committees in general and don’t see a need for them in the context of each chain.

We prefer open and accessible standardised incentive framework for governance participation and hope to see such an implementation in the future.

20

I agree; we have a rough idea from conversations, but one or two chains would be able to provide reward incentives when Euler is deployed on their chain, and this can become the deciding factor between similar chains.

Governance committees do lay themselves to centralization, which is a key issue.

I would like to see Euler deployed on one chain for at least a few months to enable governance to become accustomed to a new chain before deploying on further chains. This enables the community to handle cross-chain governance in a more sustainable manner.