RFC Formalizing Multichain Deployment Process

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.

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

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.

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

nice…

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

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.

@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

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
  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)

  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.

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

1 Like

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

1 Like

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

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.

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.

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.

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.

Hey @Bobbay_StableLab, thanks for updating your proposal. As for the topics u mentioned:

  1. I see two options here:
  • gently ask the EulerLabs (ultimately, it will be up to them to deploy)
  • contract tech teams to make evaluations, but that will be additional operation and financial burden on the DAO
  1. I would prefer not to set up specific governance committees. As I can predict, out of 3 categories of proposals we have now, only one eIP will be different, so it would be possible just to add a separate category for BCH chain to discuss risk parameters.

On the other hand, I wonder will it be possible to use EUL in BSC chain (i believe it is logical to be able to bridge it) to vote? And will the EUL incentives for the BSC users be in ETH or BSC chain?

  1. I would avoid deploying on testnets since it will take necessary human resources from more pertinent tasks. If it is not necessary for successful deployment on the mainnet ofc

Thanks for the comments.

  1. I agree that EulerLabs opinion would be helpful. Other opinions would also be helpful so for now I will leave it as “TBD”. We don’t want reliance on any team.
  2. Sounds good to me, we can close the door on specific gov committees and move forward.
  3. I agree, mainnet should be a priority for now such as deploying on Optimism & Polygon etc.

Title: RFC Multichain Deployment Process

Author(s): @Bobbay_StableLab, @Matt_StableLab

Related Discussions:

Submission Date: 2/20/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…

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

This will follow the current EulerDAO governance process.

  1. Post a forum post using the multichain deployment template

  2. Title the post “RFC Deploying Euler to XYZ Chain” with the tags “RFC” and “eIP”

  3. Add a temperature check poll at the bottom of the post.

  4. After the temperature check is passed and 7 days have gone by since the original posting, make the following changes:

  5. Repost the proposal as a new comment in the same thread with any changes suggested by the community.

  6. Change the title to “eIP ## Deploying Euler to XYZ Chain.

1. Where ## is the next sequential number of eIP
2. Where XYZ is the chain name
  1. Change thread tags to “Formal Submission” and “eIP”

  2. After two days in the formal submission stage anyone with at least 500 EUL can post the proposal to snapshot.

  3. The proposal thread tags should then be changed to “live vote” and “eIP”

  4. After the snapshot vote ends the tags should be changed to “eIP” and “voted proposal”

  5. After a successful snapchat vote, the Euler Labs team will start the deployment process

  6. After a failed snapshot vote no further action is needed. The proposal can be modified and submitted after a ten-day waiting period.

Guideline Minimum Standards

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

  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 are up for discussion and can be amended. If there is a first-mover advantage for Euler to launch on another chain, this should be considered a large contributing factor.

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:

2 Likes

Doing another temp check since the proposal has undergone some changes.

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

0 voters

Would be great if we could get more votes on the temp check above as this is a somewhat time-sensitive proposal.