Elysium ECIP Drafts discussion

[GravityLabLLC]

Hello,

We would like to invite some early review of Elysium, which ties an Olympia-type of BASEFEE flow redirection to a productive settlement layer through logN/logtrees, rather than just a treasury like Olympia. This benefits ETC-native by providing utility early on even as a prototype and increasing from there through parallel feature deployment.

web: https://logtrees.com/elysium/elysium.html

Elysium ECIP drafts:

ECIP-1110-ELY-FEE: #568
ECIP-1111-ELY-REV: #569
ECIP-1112-ELY-COM: #570

[realcodywburns]

Thanks for putting these drafts out publicly and engaging on community calls — the Elysium proposals raise some questions worth working through carefully, and I want to engage with them in good faith.

The dual-rail redundancy argument in the blog post is reasonable at the application layer — ETC/ETH EVM parity is real and deploying the same contract to both chains for availability redundancy is a legitimate pattern, though the state reconciliation question (which chain is canonical on divergence?) needs a defined answer before it becomes a production guarantee rather than a marketing claim.

More substantively: the Elysium proposal correctly identifies that if ETC activates EIP-1559, the community needs to make an explicit choice about where BASEFEE goes. Burn (ETH's approach) is one option. Productive redirection is another. The argument that passive accumulation alone isn't useful is worth engaging with.

Where the current drafts need work

The core structural problem is that ECIP-1110-ELY-FEE bundles two distinct decisions into one proposal: (1) activating EIP-1559+EIP-3198 on ETC, and (2) routing the resulting BASEFEE to a specific project. These have different stakeholders, different risk profiles, and different community consensus requirements. Keeping them coupled makes it harder to evaluate either cleanly.

Ethereum Classic already has a set of draft ECIPs (1111–1115) that handle the EIP-1559 activation question with a neutral treasury destination and a full governance layer (DAO, proposal process, hash-bound execution, miner smoothing). The Elysium design replicates the consensus-layer portion of that work but replaces the neutral governance layer with a fixed allocation: 10% logtrees R&D, 10% ETC R&D, 80% Rainbow Compute. A few questions follow directly from that:

1. What is Rainbow Compute? It receives 80% of redirected protocol revenue under the current Elysium framing, but I can't find a specification anywhere — not in the ECIPs, not on the Elysium page, not in the whitepaper. This is the majority destination of protocol funds and it needs a precise definition before the proposal can be evaluated.

2. Who controls the revenue contract? ECIP-1111-ELY-REV specifies an immutable custody contract with address TBD and deployment mechanism TBD. The 10/10/80 allocation described on the Elysium page doesn't appear in the ECIP text at all. What is the actual on-chain mechanism that enforces the split, and who can change it?

3. What is the conflict resolution mechanism when ETC and ETH state diverge? The dual-rail blog post introduces "Truthsaying" as a hard requirement but doesn't define how the application layer decides which chain's state is canonical in a divergence event. This is the central engineering challenge of the architecture and it's currently unspecified.

4. Why bypass governance? If logtrees demonstrates measurable utility - recorded externalities, auditable Treemap state, a working logN aggregation layer - it should be a strong candidate for treasury funding through a permissionless proposal process. The existing Olympia framework (ECIP-1114) defines exactly that process: anyone can submit an ECFP, governance votes, execution is hash-bound and immutable. Hardcoding logtrees as the BASEFEE destination at the consensus layer removes the community's ability to evaluate competing uses of protocol revenue. What is the argument for skipping that step?

If the goal is EIP-1559 activation on ETC, that proposal stands on its own merits and deserves a clean draft.
If the goal is protocol funding for logtrees and Rainbow Compute, that's a legitimate funding request that should go through whatever governance process ETC adopts - and the Elysium team would have a strong case to make given the work that's clearly been done on the product side.

Happy to discuss further on community calls or in this thread.

[GravityLabLLC]

Thank you for your questions Cody, I am excited to discuss!

The dual-rail redundancy argument in the blog post is reasonable at the application layer — ETC/ETH EVM parity is real and deploying the same contract to both chains for availability redundancy is a legitimate pattern, though the state reconciliation question (which chain is canonical on divergence?) needs a defined answer before it becomes a production guarantee rather than a marketing claim.

The dual-rail redundancy discussed here is part of something affectionately called Supersolid Superstorage which is a tool being released as part of the Elysium releases. It is a tool for people who want to easily deploy their Solidity contracts with dual-rail redundancy or greater. This is because Elysium is bringing utility to Ethereum Classic and not just. Right out of the box we're doing that by providing:

• LogtreesTreemap smart contract deployment
• Adding tokens that we deployed the Treemap to as supported tokens in Supersolid Superstorage

We already have the LogtreesTreemap deployed to Ethereum (both ETC and ETH) and we use Supersolid Superstorage internally as we begin Elysium rollout. Deploying the Treemap and making Supersolid Superstorage available to people does not require ECIPs. Meaning, I am bringing these two as offerings to users of Ethereum Classic without any changes required to ETC.

Why? Because Elysium is about bringing utility to blockchains and especially Ethereum. This might raise a question about what is the point behind Elysium ECIPs then, if Elysium is building two sources of utility that don't require a change to ETC? To put it simply, in noticing Olympia's interest in an ETC BASEFEE we determined that such a mechanism could, ironically, be used to route that ETC compute/energy into an engine like logtrees instead. This is because logtrees is powered by my algorithm logN, which on existing tokenomic and economic and planetary rules is designed to aggregate untapped surplus value into an auditable ledger component which can receive "externality imputation." The result of this mechanism is strongly provable value generation in a new economics substrate layer which emerges at colossal scale.

While there is much to unpack in this, the main idea is that logN / logtrees function are a digital friction brake for the economy, capturing excess value (heat) from economic activity. We are able to identify and harvest this now because in the past we didn't have the tools to harvest it with this kind of extreme precision. Ethereum will benefit from this by virtue of having received the LogtreesTreemap, as logtrees eventually grows in adoption. However, to take this to the next level would mean providing the ETC BASEFEE as fuel to power logN. If Olympia would consume BASEFEE for treasury, then routing BASEFEE into ETC, ETC Grants, and logtrees achieves the maintenance goals while also obtaining considerable utility even as a massive protocol-layer upgrade.

More substantively: the Elysium proposal correctly identifies that if ETC activates EIP-1559, the community needs to make an explicit choice about where BASEFEE goes. Burn (ETH's approach) is one option. Productive redirection is another. The argument that passive accumulation alone isn't useful is worth engaging with.

Yes, our view is that passive accumulation alone isn't useful. Though we are not against the concept of funding development efforts and ensuring that core teams are well resourced, we consider that this is more achievable with Elysium than Olympia. This is because we from Elysium are coming to the table with utility-generation too. We would love for Olympians to be part of Elysium.

The core structural problem is that ECIP-1110-ELY-FEE bundles two distinct decisions into one proposal: (1) activating EIP-1559+EIP-3198 on ETC, and (2) routing the resulting BASEFEE to a specific project. These have different stakeholders, different risk profiles, and different community consensus requirements. Keeping them coupled makes it harder to evaluate either cleanly.

Ethereum Classic already has a set of draft ECIPs (1111–1115) that handle the EIP-1559 activation question with a neutral treasury destination and a full governance layer (DAO, proposal process, hash-bound execution, miner smoothing).

We have found what looks like censorship on attempts to discuss those. We consider that the risk to ETC of routing to treasury is large enough that such a treasury would need to be very vetted. If BASEFEE would be redirected for treasury, then we find that fueling protocols including even their further development as they prove themselves is the better choice. This is because the latter does not take away from those same developers handling maintenance needs as well. The Elysium ECIPs are drafts that were deployed into the conversation sooner than we would've liked, since a response was needed on Olympia due to server/github drama. We are more than happy to consolidate or clarify or streamline our ECIPs for clarity and simplicity but in a nutshell, the main idea is to more neatly obtain the same BASEFEE rerouting concept but to have it fuel utility generation and maintenance through Elysium constructs.

The Elysium design replicates the consensus-layer portion of that work but replaces the neutral governance layer with a fixed allocation: 10% logtrees R&D, 10% ETC R&D, 80% Rainbow Compute. A few questions follow directly from that:

This has more recently been specified as 97% to miners, 1% to ETC core, 1% to ETC grants, and 1% to logtrees. We will update it everywhere.

What is Rainbow Compute? It receives 80% of redirected protocol revenue under the current Elysium framing, but I can't find a specification anywhere — not in the ECIPs, not on the Elysium page, not in the whitepaper. This is the majority destination of protocol funds and it needs a precise definition before the proposal can be evaluated.

Rainbow Compute is the computation platform that emerges from logN at scale. As hardware starts loggingN, it will be a network. Conceptually, this can be considered like a rollup. However, since Olympia updated their BASEFEE amounts, we updated ours to go with 97% to the miners, 1% to ETC core, 1% to ETC grants, and 1% to logtrees. We do not need to consider the difference between logtrees and Rainbow Compute except as a nuance that is briefly discussed in the logtrees whitepaper and will be more deeply discussed in the upcoming logtrees yellow paper.

Who controls the revenue contract? ECIP-1111-ELY-REV specifies an immutable custody contract with address TBD and deployment mechanism TBD. The 10/10/80 allocation described on the Elysium page doesn't appear in the ECIP text at all. What is the actual on-chain mechanism that enforces the split, and who can change it?

These are TBD mechanisms because as mentioned we deployed the draft ECIPs as a response to Olympia, but we do not have a strong preference on these details. The main thing for us is that routing BASEFEE into logN would generate utility and unlock massive new scaling potential for ETC. Since we found Olympia to be censorious we preferred that the ECIPs even be drafts that show the point about utility through logN / logtrees since we believe that ETC will respond favorably to Elysium.

The contracts could potentially involve a multi sig or they could depending on their resulting size be stewarded by a person or people building in public, but this would be a bigger discussion to have. We could have logN generate a report on a cadence and send it to a smart contract to distribute BASEFEE that way. The contract would accumulate some BASEFEE between distributions but if the cadence is reasonable it wouldn't be much stored BASEFEE. We will define these all the way through but consider that the drafts are worth sharing even before then for discussing the difference in BASEFEE rerouting on Olympia through treasury vs on Elysium through logN/logtrees on ETC. That is the pertinent core question.

What is the conflict resolution mechanism when ETC and ETH state diverge? The dual-rail blog post introduces "Truthsaying" as a hard requirement but doesn't define how the application layer decides which chain's state is canonical in a divergence event. This is the central engineering challenge of the architecture and it's currently unspecified.

I believe you are referring to the blog post shared in Discord for the upcoming Supersolid Superstorage tool and how logtrees is already deployed that way to Ethereum. More information about this will be aded to the specs but the main purpose of it so far is data redundancy. Currently, the user will configure which chain they want to be the tiebreaker in a divergence event. This will be related further to each chain's underlying philosophy - users might select that the faster of the two be the tie breaker. Or perhaps the slowest. This is user configurable because it will depend on what is their precise use case.

The way in which this tool pertains to Elysium is simply as an example of the kind of utility being built through Elysium. logtrees already exists as a prototype and Supersolid Superstorage is already in use for logtrees (as a tool which will continue to improve). These realities do not depend on the BASEFEE - logN and logtrees already exist and will keep improving. The implication of this is that the BASEFEE would drive utility for ETC when routed through logN/logtrees settlement layering.

Why bypass governance? If logtrees demonstrates measurable utility - recorded externalities, auditable Treemap state, a working logN aggregation layer - it should be a strong candidate for treasury funding through a permissionless proposal process. The existing Olympia framework (ECIP-1114) defines exactly that process: anyone can submit an ECFP, governance votes, execution is hash-bound and immutable. Hardcoding logtrees as the BASEFEE destination at the consensus layer removes the community's ability to evaluate competing uses of protocol revenue. What is the argument for skipping that step?

It is about the vision - as an Ethereal app, if logtrees demonstrates those then it always existing is a good thing. It could potentially be a strong candidate for treasury funding through a permissionless proposal process...but could and should aren't the same as would or is, so there is a trust element involved in this. If logtrees prove out to be a protocol-grade upgrade then this is not so much bypassing governance as just activating the switch for logtrees. It is a simple code change to go back if it is needed. This could also be in a multisig. But realistically, I am not convinced on a DAO being an implicitly good thing for ETC. I think that a DAO is mostly a philosophical thing whereas for me, I am approaching Elysium from the engineering and economic perspectives. I think that Discord, Github, Youtube, web, are part of governance and establishing consensus too.

I will look into ECIP-1114's ECFP process some more and see what it entails. My concern is if a DAO would hamstring innovative upgrades by relegating engineering or technical matters to committee.

If the goal is EIP-1559 activation on ETC, that proposal stands on its own merits and deserves a clean draft.
If the goal is protocol funding for logtrees and Rainbow Compute, that's a legitimate funding request that should go through whatever governance process ETC adopts - and the Elysium team would have a strong case to make given the work that's clearly been done on the product side.

My goal is that if anyone is activating EIP-1559 on ETC, that it be through Elysium because Elysium has logN / logtrees and not just. This is because the functional change to ETC to redirect BASEFEE would then generate utility at colossal scale, which is good for ETC-native and other blockchains. Olympia has a treasury and a DAO formation. I still consider that the best case outcome is one in which Olympians and Elysians are building ETC side by side for at least thousands of years into the future. But owing also to the Discord drama and discussion suppression on the Github, or at least the open question about these, the goal is to ensure that Elysium is at least able to defeat Olympia if this is required for ETC's sake. Meaning, in the same way that Olympia decreased its treasury share of BASEFEE recently, Elysium did too - Elysium is still more competitive in this regard and we still have logtrees too! We are Olympia-aligned from the start in that we are fans of the team and believe building together would be amazing, but regardless we favor ETC the most and therefore we chose to deploy Elysium.

Happy to discuss further on community calls or in this thread.

Likewise, there is a lot to discuss and happy to dive in! Thanks for your consideration! Excelsior!