Rewind X — Architecture Overview
Deterministic, non-custodial infrastructure for reversible ERC-20 transfers.
Deterministic means: all state transitions follow fixed on-chain rules — no human discretion and no off-chain decisioning.
Contents
System Flow
User Wallet
Initiates protected transfer
Transfer Layer
Protected transfer creation, claims, rewind intents
State Ledger
Single source of truth for transfer lifecycle
Risk & Safety
Deterministic gates: limits, cooldowns, integrity checks
Rewind
Sender reclaims funds
Early Release
Sender releases → Recipient claims
Finalize
Expiry → Recipient claims
Proof Layer
On-chain rewind attestation
All user-initiated state changes pass through a single canonical entry layer. Internal modules cannot be invoked directly.
Module Groups
| Layer | Function |
|---|---|
| Transfer Interface | Protected transfer creation, claiming, rewind execution. Supports any ERC-20. |
| State Ledger | Canonical transfer states and lifecycle transitions. |
| Risk & Enforcement | Deterministic limits, cooldowns, rule-based integrity checks. No discretionary overrides. |
| Fees & Accounting | Bounded fee computation and revenue distribution. |
| Proof & Utility | On-chain rewind attestation. Tier-based parameter constraints. |
| Final Rail | DEX-compatible wrapper. Transfers are irreversible to preserve DeFi composability. |
| Delegation Layer | Enables AI agents to execute rewinds on behalf of users (explicit activation required). |
Delegation Layer
The protocol supports two permission models for rewind execution:
Manual Mode
Default for all users- •User signs every rewind manually
- •No delegation required
- •Full control at all times
- •Best for occasional users
Delegated Mode
User-activated delegated protection- •User activates via setDelegate()
- •1-hour cooldown before active
- •Delegate executes rewinds under on-chain constraints
- •Instant disable anytime
IntentBasedRewind
Same on-chain enforcement for both modes
Authorization Flow (Delegated Mode)
- 1.User calls setDelegate(agent) to enable delegated protection
- 2.1-hour security cooldown begins (anti-phishing / social-engineering protection)
- 3.After cooldown, the delegate may execute rewind() only for sender-created transfers, subject to on-chain limits
- 4.User can disable instantly via removeDelegate() (no cooldown)
- 5.Daily limits enforced per NFT tier
- 6.Delegate can only call rewind() — never transfer, redirect, or withdraw funds
Security Guarantees
Non-Custodial
Funds held by protocol contract; move only via on-chain rules
Explicit Activation
Delegation is opt-in (setDelegate()), never default
Instant Revoke
removeDelegate() takes effect immediately
Cooldown Protection
1-hour delay prevents rushed/forced delegation changes
Daily Limits
Enforced per tier
Official Agents
AgentPass: delegation restricted to protocol allowlist (on-chain enforced)
Execution Rails Overview
Rewind X introduces a protected execution window for operational transfers, while preserving strict finality for market and DeFi-critical flows.
User Wallet
ERC-20 Transfer Flow
Protected Rail
Rewind X Layer- Time-bounded window (2min–48h)
- Sender can rewind
- Mistake mitigation
- Proof on rewind
Final Rail
DEX / Trading- Immediate finality
- No rewind possible
- Full composability
- Liquidity & trading
Users choose the appropriate rail based on use case. The Final Rail preserves DeFi composability and market finality.
System Invariants
- •A transfer resolves to finalized OR rewound — never both, never neither
- •Only the original sender can trigger a rewind
- •After window expiry, finalization is irreversible
- •No privileged actor can redirect or seize user balances
- •Safety mechanisms restrict actions — they do not move funds
- •Proof tokens are minted only after successful rewind execution
Control Surface
Trust-minimized administrative controls:
| Control | Scope | Capability |
|---|---|---|
| Emergency pause | State transitions | Halts new operations; cannot move balances |
| Fee parameters | Accounting | Bounded ranges; cannot exceed protocol caps |
| Module upgrades | Non-core paths | Timelock-governed; core ledger is non-upgradeable |
Security Guarantee
No admin path exists to transfer, redirect, or freeze user funds. Paused state preserves all balances in-place; resolution resumes from the same state once unpaused.
Verification Status
- •~20 coordinated contracts
- •Tested against production-equivalent EVM state
- •Not deployed on mainnet yet; controlled validation is the next step
A deeper walkthrough (design + threat model) is available on request for qualified reviewers.
Audit process and deployment roadmap available upon request.
Request AccessThis document describes architecture intent and invariants. It does not represent a production deployment.