Production Readiness & Evidence
AmpliDex distinguishes between architectural design, implemented functionality, validated functionality, and production-ready functionality. A component is not considered production-ready solely because it appears in the technical architecture or has been implemented. Production readiness requires appropriate testing, deployment evidence, security review, operational ownership, monitoring, and documented verification. This page defines the readiness criteria applied to AmpliDex and provides a public evidence register linking technical claims to verifiable implementation artifacts.Readiness classification
AmpliDex documentation uses the following classifications where implementation status needs to be distinguished:
These classifications allow the technical architecture to describe the intended production system without implying that every component has already completed the same stage of development.
Production launch gates
AmpliDex will not classify the protocol as production-ready until the applicable launch gates have been satisfied.Economic and protocol safety
- Formal economic specification and parameter rationale reviewed.
- Critical protocol and accounting invariants defined and tested.
- Supply, borrow, collateral, interest, repayment, and liquidation accounting validated.
- Mixed-decimal assets, rounding boundaries, dust, time jumps, bad debt, and loss scenarios tested.
- Protocol limits and initial market parameters defined conservatively.
Smart contract verification
- Unit and integration test suites passing.
- Property-based and stateful fuzz testing performed against critical invariants.
- Storage migrations tested against production-shaped state.
- Contract upgrade and rollback procedures verified where applicable.
- Reproducible Soroban WASM artifacts generated and independently identifiable.
- Deployed contract configuration verified against the approved deployment manifest.
Pricing and execution
- Approved oracle/reference pricing sources independently verified.
- Aquarius, Soroswap, and other enabled execution adapters tested against expected production behavior.
- Route limits, slippage controls, and execution bounds validated.
- Stale, unavailable, manipulated, or divergent price-source scenarios tested.
- Degraded execution and oracle behavior tested.
- Emergency exits and restricted operating modes verified.
Liquidation and automation
- Position-health and liquidation calculations tested across boundary conditions.
- Permissionless liquidation behavior verified.
- Keeper automation tested independently from the underlying liquidation mechanism.
- Multiple-keeper and liquidation-race scenarios tested.
- Keeper failure does not prevent eligible third parties from performing permissionless protocol actions.
- Recovery procedures for automation outages documented and tested.
Data and reconciliation
- Protocol events can be deterministically replayed from chain history.
- Indexed state is reconciled against authoritative on-chain state.
- Indexer interruption and recovery tested.
- Database backup and restore procedures tested.
- Operational metrics and reconciliation alerts implemented.
Governance and operational security
- Administrative permissions minimized and documented.
- Multisig configuration and signer responsibilities verified.
- Timelocks applied to applicable privileged operations.
- Guardian and emergency permissions explicitly bounded.
- Key rotation and recovery procedures tested.
- Deployment and configuration changes auditable.
Security and operations
- Independent security review completed where required.
- Critical and high-severity findings resolved before unrestricted deployment.
- Accepted residual findings documented with rationale.
- Production monitoring and alerting operational.
- Incident-response procedures documented.
- Public vulnerability disclosure process available.
- Funded bug bounty operational before unrestricted mainnet deployment.
Mainnet deployment
- Source commit and release tag published.
- Contract IDs published.
- Reproducible WASM hashes published.
- Deployment and configuration manifest published.
- Initial protocol caps and risk parameters approved.
- Mainnet deployment begins under conservative operating limits.
- Criteria for increasing caps or enabling additional markets defined in advance.
Evidence register
The evidence register provides a verifiable link between AmpliDex’s technical claims and deployed implementation. The register will be updated as components progress through implementation, validation, security review, and deployment.Evidence status
Evidence entries use four primary states:- Pending — required evidence has not yet been published.
- In progress — implementation or verification is actively underway.
- Verified — evidence has been completed and linked to a reproducible or independently inspectable artifact.
- Not applicable — the requirement does not apply to the relevant release or component.
Milestone evidence
For each significant implementation or deployment milestone, AmpliDex will publish an evidence package containing, where applicable:- an immutable source commit and release tag;
- deployed testnet or mainnet contract IDs;
- reproducible contract artifact and WASM hashes;
- automated test, property-test, fuzz-test, and benchmark results;
- relevant security review and remediation evidence;
- deployment and configuration information;
- example on-chain transactions or a reproducible demonstration; and
- a concise mapping between the milestone’s technical claims and supporting evidence.