This document explains which parts of Elastic Restaking Networks are being translated directly into the on-chain prototype, which parts are approximated, and which parts are intentionally deferred.
The paper contains two different layers:
Concepts that can be expressed directly in an on-chain engine:
- stake,
- allocations,
- degree,
- slashing,
- post-loss support.
Concepts that require broader computation, optimization, or figure-generation:
- attack search,
- robustness thresholds,
- minimum-stake / minimum-loss searches,
- broader parameter sweeps,
- figure reproduction.
V1 implements the mechanism layer and documents the analysis layer as deferred.
The prototype models the difference between:
- actual validator stake,
- service-facing nominal commitments.
The engine allows aggregate nominal allocation above current stake.
The engine computes a stretch ratio using total nominal allocation divided by real stake.
Slash events change actual remaining collateral.
The engine exposes post-slash effective backing through an explicit formula.
Instead of a full reward economy or full incentive design, V1 exposes protocol-level and service-level degree signals.
V1 approximates service differences through policy fields:
- minimum allocation,
- per-event slash cap,
- risk weight,
- optional service degree cap.
V1 treats service slashing policy as configurable rather than fully fixed by the paper. In particular, the engine supports multiple service slash profiles. If maxSlashBpsPerEvent > 0, the slash amount is capped as a percentage of the validator’s current effective backing for that service. If maxSlashBpsPerEvent == 0, the service is treated as having no service-local per-event slash cap, so slash is bounded only by the requested amount and the validator’s remaining stake. This is an intentional prototype policy choice, not a claim that all future versions should use the same rule. It allows V1 to model both stricter services that want explicit per-event limits and more discretionary services that may want broader slash authority.
This does not move the prototype outside elastic restaking scope. The core elastic mechanism remains the same: validators hold real stake, allocate nominal backing across services, slash events reduce real stake, and effective backing is recomputed from the remaining stake. What is simplified in V1 is the service-local slash policy layer, not the elastic restaking mechanism itself.
Future versions could tighten or specialize this policy in several ways. For example, maxSlashBpsPerEvent == 0 could be reinterpreted to mean a slash cap of 100% of effective backing, the engine could introduce explicit slash modes such as UNCAPPED, EFFECTIVE_BACKING_CAPPED, or NOMINAL_CAPPED, or the protocol could require all services to remain backing-linked while using maxSlashBpsPerEvent only to tune the percentage. These are future policy refinements, not prerequisites for V1 to count as a valid elastic restaking prototype.
The paper's latest discussion raises open questions around cap choice and allocation choice. V1 addresses these through simple documented heuristics rather than solving the full optimization problem.
The prototype does not attempt to solve the validator allocation optimization problem described in the paper.
Instead, the engine exposes preview helpers and policy signals that allow validators or external tooling to evaluate allocation choices under degree constraints.
This approach keeps the mechanism simple while enabling future off-chain optimization or strategy layers.
The author's Python repo focuses on network construction, parameter sweeps, and figure generation. That analysis layer is not being ported on-chain.
The prototype does not compute formal robustness thresholds or search for optimal attacks.
No graph-generation or figure-reproduction pipeline is part of V1.
V1 does not include governance, tokenomics, or a production reward engine.
The goal of the prototype is to create a usable mechanism foundation:
- legible state,
- executable transitions,
- visible post-slash behavior,
- clear policy surface,
- integration-ready read APIs.
The analysis side can later be added as a companion layer rather than forced into the first on-chain build.
The public Python repo contributes:
- analysis,
- figure generation,
- search over parameter spaces.
This prototype contributes a complementary artifact:
- an on-chain execution engine,
- a product-oriented interface,
- policy surfaces,
- preview views,
- scenario-driven demonstrations.
Rather than reproducing the full analysis environment, this project focuses on translating the mechanism itself into executable infrastructure.
This project does not claim that the paper is fully implemented.
It claims something more practical:
- the core mechanism has been translated into an on-chain engine,
- the tradeoffs are visible through product-like interfaces,
- and the result can serve as the basis for a broader shared-security project.