Decentralization Scorecard
Self-assessment of ETH Strategy's decentralization status — what's strong, what's in progress, and what's honestly centralized today.
ETH Strategy is team-controlled today. This page is an honest self-assessment of where the protocol stands on decentralization — not where we want to be, but where we actually are. It is modeled after Lido's scorecard and will be updated as the protocol evolves.
Each attribute is rated against a three-tier system:
On Track
Meets or exceeds the target for the protocol's current stage
In Progress
Meaningful work underway, but gaps remain
Needs Work
Significant improvement required
Last updated: March 2026.
1. Smart Contract Security
Audited contracts — On Track
ESPN contracts have been audited by Nethermind. Core protocol contracts (esETH, CDT, EthStrategyConvertibleNote, StakedStrat) have completed 2 full audits; reports will be published alongside code before permissionless launch. Treasury Lending will be audited before its Q2 2026 deployment.
No contract is deployed permissionlessly without a completed audit.
Verified source code — On Track
All deployed contracts are verified on Etherscan with exact source match:
StratToken (ERC-20)
Solidity v0.8.20
Exact match
StratOption (ERC-721)
Solidity v0.8.20
Exact match
ESPN Token (ERC-4626)
Solidity v0.8.20
Exact match
Staked ESPN LP (ERC-4626)
Solidity v0.8.20
Exact match
Anyone can independently verify that the deployed bytecode matches the published source.
No proxy-upgrade pattern — On Track
Deployed ETH Strategy contracts are immutable — there is no admin function to swap contract logic after deployment. The one proxy in the system is the Arrakis ESPN/USDS LP vault, which uses EIP-1967 Beacon Proxy controlled by Arrakis governance, not ETH Strategy.
This is a deliberate trade-off: immutability prevents governance from silently changing contract behavior, but it also means bugs can only be fixed by deploying new contracts and migrating.
Battle-tested security patterns — On Track
All contracts use:
Ownable2Step— ownership transfers require explicit acceptance by the new ownerReentrancyGuard— on all state-changing functionsERC-2612 permit support — reduces attack surface from separate
approve()transactionsStandard OpenZeppelin implementations for ERC-20, ERC-721, and ERC-4626
2. Governance Structure
Root multisig threshold — In Progress
The ETH Strategy Multisig (root authority) is a 3-of-5 Safe (v1.4.1). Five distinct EOA signers must produce 3 signatures to execute any governance action.
A 3-of-5 threshold is reasonable for an early-stage protocol but below the standard for mature DeFi (e.g., Lido uses 4-of-8 for routine operations). Increasing the threshold or signer count is planned as the protocol grows.
Sub-multisig independence — Needs Work
The nested Safe hierarchy provides functional separation but limited signer independence:
ETH Strategy (root)
3-of-5
5 distinct EOAs
Baseline
Liquidity
1-of-1
Root multisig only
None — effectively controlled by root
Staking
1-of-1
Root multisig only
None — effectively controlled by root
Puttable Warrant
2-of-3
2 EOAs + root multisig
Partial — root is one signer
Perpetual Note
2-of-4
3 EOAs + root multisig
Partial — 3 of 4 signers overlap with root
The Liquidity and Staking multisigs are functionally pass-through — any action the root multisig approves executes immediately with no additional approval required. This means the 5 root signers effectively control all protocol operations.
Target state: Sub-multisigs should have independent signers who are not root multisig members, creating genuine separation of concerns.
Timelock on governance actions — Needs Work
There are no timelocks on any governance action today. Parameter changes (PCF, GCF, borrow rate, deposit cap, token whitelist) take effect immediately upon multisig execution.
For context: position terms are immutable once created (conversion entitlements, loan rates, redemption queue values), so timelocks primarily affect new positions. However, immediate parameter changes still create risk — e.g., the team could set extreme PCF/GCF values for new bonds or disable ESPN withdrawals without advance notice.
Target state: Introduce a timelock (24–72 hours) on critical parameter changes, giving the community time to react before changes take effect.
On-chain transparency — On Track
All parameter changes emit on-chain events:
OwnerChangedPCF,OwnerChangedGCF— convertible note pricingBorrowRateUpdated,LoanDurationUpdated,DelinquentFeeUpdated— lending parametersDepositCapUpdated,WithdrawalsDisabledUpdated,ManagerUpdated— ESPN vaultTokenConfigUpdated,YieldReceiverUpdated,TreasuryManagerUpdated— esETH configuration
Anyone can monitor governance actions in real-time using standard Ethereum indexing tools (Etherscan, Dune, custom event watchers).
Delegated roles for rate-sensitive parameters — On Track
Treasury Lending uses delegated roles (rateSetter, feeSetter) — the owner can authorize specific addresses to change borrow rates and delinquent fees without granting full ownership. This enables operational flexibility (e.g., adjusting rates to market conditions) while bounding the scope of delegated authority.
3. Position Protection
Existing positions are immutable — On Track
This is ETH Strategy's strongest decentralization property. Once a position is created, no governance action can alter its terms:
Convertible notes
STRAT entitlement, esETH entitlement, USD settlement value, timelock, expiry — all stored in the NFT
Treasury loans
Borrow rate, duration, delinquent fee — snapshotted at origination
ESPN redemption queue
Dollar value owed — fixed at queue entry
Parameter changes only affect new positions. There is no admin function to modify an existing note's terms, call a loan early, or reduce a queued redemption amount.
No admin mint for debt tokens — On Track
CDT (the protocol's debt token) can only be created through authorized minter contracts (ConvertibleNote, TreasuryLend). There is no governance function to directly mint CDT, preventing inflationary governance attacks on debt accounting.
No forced early liquidation — On Track
Treasury loans cannot be called before expiry regardless of market conditions. There are no price-based liquidation triggers, no health factors, and no margin calls. This is a structural guarantee — the contract simply does not have a function to liquidate before expiry.
4. Code Transparency
Open-source contracts — In Progress
The protocol has a public GitHub repository (dangerousfood/ethstrategy) under Apache 2.0 license. However, this repository contains an earlier version of the protocol (using the $ETHXR token name) and may not reflect the current deployed contracts.
Current deployed contracts (STRAT, ESPN) are verified on Etherscan with exact source match, making the source code publicly readable. Core protocol contracts (esETH, CDT, EthStrategyConvertibleNote, StakedStrat) will have source published alongside deployment.
Target state: Maintain a current, canonical open-source repository that matches deployed contracts, with commit history, tests, and deployment scripts.
Protocol is forkable — On Track
All contract source code is available (via Etherscan verification and GitHub). Documentation is public. The protocol uses standard Solidity patterns (OpenZeppelin) with no proprietary dependencies. Anyone can fork and deploy their own instance without permission from the team.
Public documentation — On Track
Comprehensive documentation covering:
All governance-tunable parameters and who controls them
Per-contract failure modes and gotchas
Risk assessment with severity, likelihood, and mitigations
Defense-in-depth analysis of safety layers
Machine-readable protocol data (llms.txt) for AI consumption
Contract reference with function signatures, access control, and revert conditions
5. Operational Security
Multisig guard contracts — Needs Work
No guard contracts are set on any Safe multisig. Guards can enforce invariants on multisig transactions (e.g., preventing certain function calls, enforcing spending limits, or requiring additional conditions).
Target state: Add guard contracts to critical multisigs that enforce parameter bounds — e.g., preventing PCF/GCF from being set to extreme values in a single transaction.
Safe version consistency — In Progress
Four of five multisigs run Safe v1.4.1. The Puttable Warrant Multisig runs the older Safe v1.3.0.
Target state: Upgrade all multisigs to the same Safe version.
Module exposure — In Progress
The Liquidity Multisig has 2 enabled Safe modules. Modules can execute transactions without meeting the multisig threshold, which expands the trust surface. The purpose and permissions of these modules should be publicly documented.
Target state: Document all enabled modules and their permissions. Remove any modules that are no longer needed.
6. Decentralization Progress
Community governance — Needs Work
The protocol is fully team-controlled. There is no token voting, no delegate system, no community governance of any kind today. This is intentional for the launch phase — the team believes governance design should be informed by real usage patterns rather than predetermined before the protocol has live users.
The governance roadmap outlines four phases:
Current — Team-controlled via Safe multisigs. All parameter changes transparent (on-chain events).
Near-term — Publish governance parameter change logs. Establish norms around change cadence and communication.
Medium-term — Transition to community governance. Structure (BORG, token voting, or other) to be shaped by public discourse.
Long-term — Full decentralization of parameter control with guardrails against governance attacks.
No specific timeline is committed for any milestone.
Front-end decentralization — Needs Work
The protocol's web interface is hosted on centralized infrastructure. There is no IPFS deployment, no ENS content hash, and no alternative front-end.
Target state: Deploy the staking/bonding interface to IPFS with an ENS content hash as a censorship-resistant fallback.
Oracle independence — On Track
ETH Strategy has minimal oracle dependencies by design:
Conversion entitlements are fixed at bonding time — oracle exposure is limited to the bonding transaction itself
esETH uses per-token exchange rate functions from underlying LST protocols (e.g.,
stEthPerToken()), not external price oraclesTreasury lending liquidation is time-based, not price-based — no oracle required
No Chainlink or other external oracle dependency for core protocol operations
Summary
Smart Contract Security
Audited contracts
On Track
Verified source code
On Track
No proxy-upgrade pattern
On Track
Battle-tested security patterns
On Track
Governance Structure
Root multisig threshold (3-of-5)
In Progress
Sub-multisig independence
Needs Work
Timelock on governance actions
Needs Work
On-chain transparency
On Track
Delegated roles
On Track
Position Protection
Existing positions immutable
On Track
No admin mint for CDT
On Track
No forced early liquidation
On Track
Code Transparency
Open-source contracts
In Progress
Protocol is forkable
On Track
Public documentation
On Track
Operational Security
Multisig guard contracts
Needs Work
Safe version consistency
In Progress
Module exposure
In Progress
Decentralization Progress
Community governance
Needs Work
Front-end decentralization
Needs Work
Oracle independence
On Track
Overall: 11 On Track · 4 In Progress · 5 Needs Work
What This Scorecard Doesn't Cover
This scorecard assesses decentralization and governance. For other risk dimensions, see:
Risks — market, smart contract, governance, protocol-specific, and systemic risks
Defense in Depth — how eight safety layers stack to protect participants
ESPN Risks — risks specific to the ESPN vault
Audits — audit reports and security status
Governance & Alignment — full parameter list and decentralization roadmap
Last updated