E l y s i u m
Non-consensus companion

ECIP-1112-ELY-COMP Companion: logtrees + logN: Intended Productive Settlement Path

Elysium introductory visual
Elysium introductory visual.
Draft status: companion guidance only; this page is non-consensus and intentionally exploratory. Circulate it as draft context alongside the ECIP drafts, not as finalized protocol commitment.

Companion material describing the first intended Elysium utility path: evidence-backed events, conservative estimation, bounded rewards, and a public auditable Treemap.

Primary references

What is a logtreed blockchain?

A logtreed blockchain pairs base-layer settlement with logtrees so verifiable positive externalities become auditable utility over time.

In this draft, ETC remains the base layer and logtrees/logN are the first intended productive engine.

logtrees rose visual
The logtrees rose visual anchors the companion narrative for the first intended productive path.

Intended flow

  1. Supported action is performed.
  2. Metadata/evidence is submitted and verified.
  3. Scoring and estimation produce conservative expected reduction values.
  4. Bounded reward logic maps accepted values into capped settlement.
  5. Append-only event record anchors to ETC.
  6. Treemap updates as auditable derived state.
Aggregation and settlement visual
From proof collection to bounded, auditable value updates.
logN path visual
logN is presented as an auditable aggregation mechanism, not consensus-level subjective scoring.

Implementation Note: Development Funding

One governance-discussion option is a practical routed split: 10% for logtrees R&D, 10% for ETC R&D, and 80% for Rainbow Compute, unless ETC governance selects different values, recipients, duration, or oversight (including increasing ETC's share).

Why the 10% / 10% substrate lanes exist

The logtrees R&D lane and ETC R&D lane are treated as substrate-level impetus engines that feed further R&D across the stack. This is why both are framed as inherent 10% lanes in the draft policy, while retaining governance authority to tune allocations.

The design intent is not centralization. It is stewardship of living substrate systems that should be self-healing, self-growing, and self-funding over time, which in practice requires long-context teams, nurtured operator capacity, and committed resource continuity.

We encourage both LLM-backed and expert-backed scrutiny and have already performed such scrutiny internally as part of iterative design review.

Rainbow Compute and ETC base-layer virtualization (draft comment)

The primary goal is making Rainbow Compute available to logN users/miners as a practical utility layer. A secondary goal is ETC base-layer scaling assistance via virtualization, anchored to ETC settlement and verification boundaries if implemented correctly. This is an implementation objective, not a guaranteed outcome.

Any notional examples such as “1,000,000 ETC total” should be read as scenario inputs over a chosen accounting window (commonly annual), not as fixed forecasts.

Decentralization and PoW direction

This companion framing favors Ethereum Classic decentralization: ETC R&D plus Rainbow Compute R&D are intended to reinforce ETC as a premier, mineable Proof-of-Work chain with expanding utility.

Status and Future Work

The current implementation is illustrative prototype work for event logging and materialized aggregation. It is not yet production security proof, incentive compatibility proof, or full decentralization proof.