PROTOCOL / DESIGN NOTES V0.1
Security begins
with explicit assumptions.
The proposed account model, its foundations, and the work required to move from a design to a reviewed Ethereum implementation.
01 / OVERVIEW
Ownership through change.
Aftercurve is an Ethereum-native account-security project exploring hash-based authorization and careful migration. Its intended users are individuals, project treasuries, and organizations that need to understand and strengthen the permissions controlling their assets.
The product combines a proposed protected smart account, recovery policy, exposure analysis, and migration workflow. This protocol remains a research track with a browser-local planning studio. The separate Aftercurve Vault release provides encrypted secret storage and offline device transfer without deploying contracts.
No Aftercurve account contracts or signature verifiers are deployed through this website. The studio does not connect a wallet, inspect live permissions, sign transactions, or move assets. Contract implementation, benchmarks, and independent review are planned.
02 / FOUNDATIONS
Established building blocks.
Smart-account verification
ERC-4337 supports contract accounts with custom verification logic. This is the proposed integration foundation for evaluating alternative account signatures without waiting for a new consensus rule. Practical compatibility still depends on the deployed EntryPoint, validation rules, and bundler limits.
Hash-based signatures
SLH-DSA, derived from SPHINCS+, is standardized in NIST FIPS 205. It provides a starting point for a conservative signature evaluation. A standardized algorithm does not automatically make a wallet implementation secure, economical, or suitable for every device.
The project must measure signer latency, signature size, onchain verification cost, and recovery behavior. Research schemes with modified hashes or parameters need their own evaluation; their standardization status must never be implied.
Dedicated contract accounts
The proposed protected account is a dedicated smart contract. EIP-7702 delegation does not, by itself, remove the underlying EOA key's ability to authorize a new delegation. That residual authority must be considered when comparing account designs.
03 / ACCOUNT MODEL
Every permission is part
of the security model.
| COMPONENT | INTENDED RESPONSIBILITY | STATUS |
|---|---|---|
| Account contract | Own supported assets and enforce explicit authorization policy. | Design |
| Signature verifier | Verify selected hash-based signatures against bound transaction intent. | Evaluation planned |
| Recovery authority | Permit reviewed recovery using separately protected credentials and a delay. | Design |
| Relaying | Deliver already-authorized actions and pay execution gas without custody authority. | Design |
| Migration studio | Prepare a local policy plan and a staged review checklist. | Planning preview |
| Exposure explorer | Read supported onchain account permissions and report unknown dependencies. | Planned |
Transaction authorization must bind the account, network, nonce, intended calls, value, and relevant policy version. A relayer must not be able to alter the approved action. Replay, reentrancy, initialization, and authorization-bypass tests are required.
If a hybrid policy is offered, its required signatures must be combined with an AND rule to retain the intended protection. An ordinary signature accepted as an alternative would create a bypass.
Recovery and upgrades need equivalent care. A conventional administrator key that can replace the verifier would undermine the protected account. A fixed implementation removes that upgrade path but makes future migration planning more important.
04 / SECURITY BOUNDARIES
A precise scope.
An honest claim.
The intended claim is post-quantum authorization at the account layer, under the assumptions of the selected signature scheme and the correctness of its implementation.
- Ethereum remains a dependency. Consensus signatures, network availability, data commitments, and protocol upgrades have separate security requirements.
- Asset contracts remain a dependency. Token issuers, upgrade administrators, bridge contracts, DeFi positions, and governance systems are not repaired by a new account signature.
- Devices and backups remain a dependency. Compromised signing software, stolen credentials, phishing, and failed restoration can still cause losses.
- Recovery is an authorization path. A delay helps operational review; it does not replace cryptographic protection.
- Migration requires compatible assets and roles. Sending a token is different from transferring a protocol role or unwinding a position.
Adopting a protected account would require an explicit, reviewed migration of supported assets or permissions. The website does not make an existing address quantum resistant.
05 / DELIVERY GATES
Evidence before custody.
- Specify: Publish the account threat model, algorithm and parameters, authorization rules, recovery flow, and unsupported cases.
- Implement on testnet: Verify signatures against known test vectors; implement replay protection, policy enforcement, and failure handling.
- Measure: Publish signer and verifier performance, calldata costs, bundler compatibility, and supported-device behavior.
- Rehearse: Test key loss, backup restoration, recovery cancellation, small transfers, and migration interruption.
- Review independently: Obtain cryptographic and smart-contract review, resolve findings, and publish the limits of that review.
- Release carefully: Decide mainnet scope only after the preceding gates are met. Publish exact contracts and deployment evidence.
06 / REFERENCES
Go to the source.
Primary specifications and research informing the proposed architecture. These organizations and authors do not endorse Aftercurve.