Repository navigation
Coxy Product Roadmap
Document type: Strategic product, engineering, security, compliance, partnership, and delivery roadmap
Version: 1.0.0
Date: 9 August 2026
Company: Coxygen Global
Developer: Bernard Sibanda
Project: Coxy Wallet / Coxy Financial Platform
Source specification: Coxy Product Specification
Licence: MIT License for Coxy application code, subject to third-party component licences
Roadmap horizon: August 2026 through 2030 and continuous expansion thereafter
Delivery model: Capability-gated, security-gated, evidence-driven, modular, and partner-aware
Primary implementation stack: Vanilla JavaScript, semantic HTML, CSS, PHP, MySQL, and isolated chain-native on-chain tooling where required
Roadmap rule: Coxy is one platform with four capability modes. Silver, Gold, Diamond, and Platinum are not independent products or codebases. Every higher mode reuses the same shared Coxy Core and enables additional atomic modules through capability profiles, feature flags, policy gates, and provider adapters.
Schedule rule: Dates in this roadmap are target windows, not unconditional launch promises. Security, interoperability, regulatory readiness, partner readiness, audit closure, reconciliation, and operational evidence override calendar dates. A milestone may move later without forcing dependent functionality into production prematurely.
Customer-protection rule: AI assistance, identity technology, KYC/AML integrations, privacy technology, programmable assets, and banking integrations never replace explicit user authorization, cryptographic controls, regulatory responsibility, or independent security review.
- 🎯 Roadmap Purpose
- 🌍 Strategic Destination
- 🧭 Roadmap Principles
- 🏅 Four-Mode Product Progression
- 🗓️ Executive Timeline 2026–2030
- 🧱 Critical Path and Dependency Order
- 🚦 Release Channels and Readiness States
- 🥈 Milestone R0 — Silver Protection and Foundation
- 🥇 Milestone R1 — Gold Core Interoperability
- 🥇 Milestone R2 — Gold Production Release
- 💎 Milestone R3 — Diamond Policy and Identity Foundation
- 💎 Milestone R4 — Diamond Identity and Compliance Beta
- 💎 Milestone R5 — Programmable Assets, RWA, and Privacy Pilot
- 💎 Milestone R6 — Diamond Controlled Production
- 🏆 Milestone R7 — Platinum Multi-Chain Foundation
- 🏆 Milestone R8 — Banking, FX, Stablecoin, and Remittance Pilot
- 🏆 Milestone R9 — Platinum Controlled Production
- 🌐 Milestone R10 — Global Expansion
- 🤖 AI Assistant and AI Guardian Roadmap
- 🔐 Security, Audit, and Assurance Roadmap
- 🧪 Quality Engineering and Test Roadmap
- 📜 Logging, Observability, and Audit Evidence
- 👥 People and Resource Roadmap
- 🤝 Partnership and Institutional Roadmap
- 📊 Success Metrics and KPIs
⚠️ Strategic Risk Register- 🧩 Module Delivery Matrix
- ✅ Definition of Done
- 🗂️ GitHub Planning and Contribution Model
- 🔄 Roadmap Governance and Change Control
- 📌 Immediate Next 90 Days
- 📚 Source Specification and References
This roadmap converts the Coxy Product Specification into an ordered delivery programme that can be executed by multiple developers and specialist teams without turning the application into a monolith. The roadmap defines what must be built first, what can be developed in parallel, which modules are allowed to depend on which foundations, how each Coxy mode reaches production, and which security, testing, compliance, and partner conditions must be satisfied before a feature becomes available to customers.
The roadmap preserves Coxy's original mission. Silver remains a simplified training and beginner wallet that helps students and first-time users understand Cardano without exposing unnecessary complexity. Growth does not mean replacing Silver with an advanced financial interface. Growth means building stable abstractions underneath Silver and enabling new capability layers above the same tested core.
Gold makes Coxy interoperable with the wider Cardano ecosystem. It allows Coxy to operate both as a CIP-30 wallet provider for dApps and as a consumer of external CIP-30 wallets, while hardware-signing integrations remain isolated behind a signer abstraction. Gold is the architectural bridge between Coxy's original self-managed wallet and the broader Cardano wallet ecosystem.
Diamond introduces a different class of capability: verifiable identity, KERI/KEL/ACDC, CIP-0170 attestations, KYC/AML provider orchestration, programmable assets, RWA controls, issuer administration, and privacy-selective disclosure through Midnight-related adapters. These capabilities must share the same deterministic Policy Engine and must remain independently switchable.
Platinum adds global-finance functionality, including multi-chain assets, stablecoins, fiat-provider balances, banking connections, foreign exchange, cross-border remittances, settlement routing, Travel Rule orchestration, reconciliation, RealFi, treasury, and institutional integrations. Platinum is therefore the most partner-dependent and regulation-dependent stage of the roadmap. It cannot be accelerated solely through additional software developers because licensed providers, financial institutions, corridor approvals, liquidity, operational controls, and legal responsibilities must also be ready.
The roadmap is intentionally capability-gated. A later feature may be prototyped while an earlier release is being stabilized, but it may not bypass its architectural prerequisites or production security gates.
The long-term Coxy destination is a modular financial operating layer rather than a single-purpose cryptocurrency wallet. The user sees one coherent product while the implementation treats wallets, signers, identity systems, blockchains, programmable assets, privacy systems, stablecoins, banks, remittance providers, FX providers, risk services, and AI providers as replaceable capabilities connected through stable contracts.
The strategic destination can be summarized as follows:
COXY
│
├── 🥈 SILVER
│ └── Beginner Cardano + education + safe self-custody
│
├── 🥇 GOLD
│ └── Full Cardano + CIP-30 + external wallets + hardware signers
│
├── 💎 DIAMOND
│ └── Identity + policy + compliance + programmable assets + RWA + privacy
│
└── 🏆 PLATINUM
└── Multi-chain + stablecoins + fiat + banking + remittance + RealFi
Cross-cutting across every mode:
🤖 AI Assistant
🛡️ AI Guardian
🔐 Secure authorization
🧪 Automated testing
📜 Audit evidence
📈 Provider health and observability
The competitive objective is not to make Coxy depend on one particular Cardano Improvement Proposal, one AI provider, one hardware wallet, one identity network, one bank, or one remittance provider. The competitive objective is to make those capabilities interchangeable without destabilizing the customer's wallet.
The current Coxy wallet is already valuable because it is understandable. Before major architectural work begins, the team must capture its present wallet-creation, restore, send, receive, mint, staking, provider, and extension behavior in regression tests. New modules are not considered progress if they make the original wallet less reliable.
Silver, Gold, Diamond, and Platinum are mode profiles. A mode controls capability exposure; it does not create a separate codebase. Shared core interfaces such as WalletSession, SignerProvider, TransactionPlan, ChainAdapter, PolicyDecision, AuditWriter, EventBus, ProviderHealth, and FeatureFlags are reused across modes.
Every substantial feature is implemented as an atomic module that owns its frontend, off-chain logic, on-chain artifacts where applicable, PHP backend, SQL, server jobs, provider integrations, tests, documentation, logging, threat model, health endpoint, and rollback strategy. Developers should be able to work on one module without editing the internals of unrelated modules.
Silver must not require KERI, Midnight, programmable-token infrastructure, a KYC provider, a remittance provider, or an AI provider to send ADA. Gold must not require Platinum banking availability to connect an external wallet. This dependency direction is enforced through module manifests and boundary checks.
A roadmap quarter is a planning target. It is never permission to launch an unresolved critical vulnerability, unaudited high-value contract, unsafe migration, unverified recovery implementation, unreconciled financial route, or unapproved regulated workflow.
CIP-0170 and CIP-113 are treated as versioned adapters rather than assumptions embedded throughout the application. This permits Coxy to track evolving standards without forcing repeated application-wide rewrites.
Cardano providers, KERI infrastructure, KYC/AML vendors, banks, FX providers, remittance providers, AI models, and price feeds must be wrapped in Coxy-owned interfaces. Provider switching and failover should be possible without redesigning the user workflow.
AI can teach, explain, summarize, compare, detect suspicious patterns, and produce warnings. It may not independently sign transactions, authorize issuer actions, approve payments, override policy, or gain access to seeds, private keys, full KYC records, raw biometric information, or banking credentials.
KYC/AML technology does not automatically create legal permission to provide remittance, banking, FX, or other regulated services. Platinum production scope is enabled only for countries, corridors, partners, asset types, and payment methods that have been reviewed and approved.
flowchart LR
S["🥈 Silver<br/>Safe Beginner Wallet"] --> G["🥇 Gold<br/>Cardano Interoperability"]
G --> D["💎 Diamond<br/>Identity + Policy + Programmable Assets + Privacy"]
D --> P["🏆 Platinum<br/>Global Finance + Multi-Chain + Banking + Remittance"]
AI["🤖 AI Assistant + AI Guardian"] -.-> S
AI -.-> G
AI -.-> D
AI -.-> P
SEC["🔐 Security + Testing + Audit"] -.-> S
SEC -.-> G
SEC -.-> D
SEC -.-> P
| Mode | Delivery objective | Production meaning |
|---|---|---|
| 🥈 Silver | Preserve Coxy's student/new-user experience while hardening architecture, recovery, vault security, transaction preview, tests, logs, and provider reliability. | A dependable educational Cardano wallet that remains simple even while sharing production-quality infrastructure with higher modes. |
| 🥇 Gold | Add professional Cardano interoperability, external CIP-30 wallet sessions, Coxy-as-CIP-30-provider, hardware signer abstractions, capability negotiation, and advanced transaction inspection. | Experienced Cardano users can use Coxy without surrendering keys from Lace, Eternl, or another supported wallet, and Coxy users can use the wider dApp ecosystem. |
| 💎 Diamond | Add verifiable identity, policy, compliance evidence, programmable assets, RWA, issuer controls, and selective privacy. | Businesses and qualified users can create and verify identity-backed attestations, interact with controlled assets, and use privacy-preserving eligibility/disclosure workflows. |
| 🏆 Platinum | Add multi-chain, stablecoin/fiat, banking, FX, remittance, settlement, Travel Rule, reconciliation, RealFi, treasury, and institutional capabilities. | Coxy becomes a global money and finance interface while retaining explicit provider, regulatory, custody, and settlement boundaries. |
The following timeline is deliberately conservative enough to protect customer funds while still allowing parallel research and prototypes. It assumes that Silver exists today and that the major architectural refactor begins in the third quarter of 2026.
| Target window | Roadmap release | Primary outcome | Production status |
|---|---|---|---|
| 2026 Q3–Q4 | R0 — Silver Protection and Foundation | Baseline tests, atomic-module framework, WalletSession, SignerProvider, TransactionPlan, feature flags, logging, CI, recovery/security hardening. | Silver hardened; advanced modes disabled. |
| 2026 Q4–2027 Q1 | R1 — Gold Core Interoperability | CIP-30 provider, external wallet consumer, compatibility layer, capability detection, early Trezor/hardware signer integration. | Testnet/closed beta. |
| 2027 Q2–Q3 | R2 — Gold Production Release | Gold interoperability, hardware signing, advanced Cardano transaction review, provider failover, compatibility matrix, security review. | Gold controlled mainnet → GA. |
| 2027 Q3–Q4 | R3 — Diamond Policy and Identity Foundation | Shared Policy Engine, generic Cardano metadata, CIP-0170 versioned codec, KERI/KEL/ACDC integration foundation. | Internal/Preprod only. |
| 2028 Q1–Q2 | R4 — Diamond Identity and Compliance Beta | Full identity lifecycle, credential verification, wallet-to-identity binding, KYC/AML/sanctions provider adapters, business identity workflows. | Invite-only beta. |
| 2028 Q2–Q4 | R5 — Programmable Assets, RWA, Privacy Pilot | CIP-113 testnet adapter, programmable-token capabilities, RWA pilot, issuer administration, Midnight selective-disclosure use cases. | Testnet and organization pilot. |
| 2028 Q4–2029 Q1 | R6 — Diamond Controlled Production | Independent audits, controlled identity/RWA/programmable-asset activation where mature, privacy review, operational runbooks. | Controlled mainnet release. |
| 2029 Q1–Q2 | R7 — Platinum Multi-Chain Foundation | ChainRouter, normalized assets/accounts, Bitcoin and Ethereum adapters, multi-chain portfolio, stablecoin risk metadata. | Internal/beta. |
| 2029 Q2–Q4 | R8 — Banking, FX, Stablecoin, and Remittance Pilot | Fiat provider interfaces, bank linking, FX, beneficiary model, settlement router, Travel Rule, reconciliation, first approved corridor. | Partner sandbox → live pilot. |
| 2029 Q4–2030 H1 | R9 — Platinum Controlled Production | Selected chains, corridors, banks, stablecoins, RealFi, treasury, fraud controls, financial operations, support processes. | Controlled production. |
| 2030 onward | R10 — Global Expansion | Additional countries, corridors, chains, providers, hardware signers, stablecoins, identity ecosystems, RealFi protocols, and institutional services. | Continuous expansion. |
Research may begin before a target release. For example, the Diamond team may evaluate KERI or Midnight during Gold development, and the Platinum partnership team may begin bank and remittance discussions well before the Platinum code is complete. However, production dependencies must remain in order. The fact that a bank sandbox is available does not justify bypassing the Policy Engine, audit infrastructure, authentication, reconciliation, or identity/privacy controls.
Each roadmap item should be marked in GitHub and internal planning using one of the following states:
- Committed: approved for the current delivery horizon, staffed, and technically unblocked.
- Target: expected during the stated window but still dependent on normal implementation progress.
- Research: architecture, feasibility, security, or standards work only; no production commitment.
- Partner-dependent: cannot complete without an institution, regulator, vendor, or external network milestone.
- Experimental: testnet/lab capability that must not be represented as production-ready.
- Blocked: a prerequisite, audit, legal requirement, provider, or unresolved risk prevents progression.
Coxy's critical path is intentionally narrow. Teams may work in parallel, but these dependencies must not be inverted.
flowchart LR
A["Current Coxy"] --> B["R0<br/>Regression + Modularization"]
B --> C["WalletSession + SignerProvider<br/>TransactionPlan"]
C --> D["R1/R2<br/>Gold CIP-30 + Hardware"]
D --> E["Shared Policy + Evidence"]
E --> F["CIP-0170 + KERI/KEL/ACDC"]
F --> G["Diamond Identity Beta"]
E --> H["CIP-113 Testnet Adapter"]
F --> I["RWA + Issuer Identity"]
G --> J["Diamond Controlled Release"]
H --> J
I --> J
J --> K["ChainRouter + Multi-Chain"]
K --> L["Banking + FX + Fiat + Reconciliation"]
L --> M["Remittance + Settlement Router"]
M --> N["Platinum Controlled Release"]
Cross-cutting capabilities run alongside the critical path:
Every milestone
├── AI Assistant / Guardian improvements
├── Security review and threat-model updates
├── Unit + integration + property + E2E tests
├── Structured logs and audit evidence
├── Documentation and runbooks
├── Provider-health monitoring
├── Accessibility and UX review
└── Dependency / supply-chain review
Identity, RWA, programmable assets, and finance modules must request wallet information and signatures without assuming where the keys are held. If these modules are written directly against Coxy's existing wallet internals, external wallets and hardware signers will require large rewrites later. WalletSession and SignerProvider are therefore architectural prerequisites, not Gold-only features.
KYC evidence, identity credentials, sanctions decisions, token restrictions, RWA eligibility, and remittance corridor rules should not be implemented as separate incompatible decision systems. The shared policy layer must exist first so advanced modules consume the same ALLOW, DENY, and REVIEW decision model.
The ability to submit a bank or stablecoin payment is not sufficient for financial production. Coxy must be able to prove what was instructed, what was accepted by the provider, what settled, what fees and FX were applied, whether the beneficiary was credited, and whether the internal state matches provider and chain records. Unreconciled customer-money discrepancies must stop affected routes rather than being hidden by a successful-looking user interface.
Every major capability moves through the same release ladder unless a stricter module-specific process is required.
| Stage | Purpose | Who can use it | Required evidence |
|---|---|---|---|
| Local | Developer implementation and isolated tests. | Module developers. | Unit tests, lint/boundary checks, local documentation. |
| CI | Automated reproducibility and cross-module validation. | Automated systems. | Unit, property, schema, security, and regression tests. |
| Dev environment | Shared integration of current branch/release train. | Internal developers and QA. | API compatibility, MySQL migrations, provider mocks, health checks. |
| Preview / test network | Blockchain and identity integration against non-production networks. | Internal QA and selected testers. | Transaction vectors, failure tests, provider integration. |
| Preprod / institutional sandbox | Production-like environment using sandbox financial and identity providers. | Internal teams and partners. | Operational runbooks, reconciliation, audit records, monitoring. |
| Canary | Small real-world production cohort and restricted value/limits. | Named pilot users/organizations. | External security review, incident-response readiness, limits. |
| Controlled production | Wider availability with conservative limits and kill switches. | Approved users/markets. | Proven monitoring, support, security, partner readiness. |
| General availability | Broad release within approved countries/capabilities. | Eligible customers. | Sustained reliability, closed critical/high findings, completed release gate. |
A feature that cannot be safely disabled independently is not ready to leave the Dev stage.
Target window: 2026 Q3–Q4
Primary mode: Silver
Roadmap status: Committed foundation
R0 protects the existing Coxy wallet and creates the interfaces that all later work depends on. This milestone must minimize unnecessary rewrites. Working wallet logic is wrapped behind explicit interfaces, tested, and progressively moved into atomic module boundaries.
Silver must continue to provide a simple create/restore/send/receive/token/staking/learning experience. The visible product should become more reliable and better explained, not more complicated. Transaction approval should move toward semantic previews that show what the transaction will do instead of exposing raw structures.
The milestone includes:
- A permanent Silver regression suite covering wallet creation, supported mnemonic restoration, lock/unlock, ADA transfer, native assets, token minting where currently supported, staking/delegation basics, network switching, transaction history, extension upgrade, and provider-failure recovery.
- Atomic module layout,
module.jsonmanifests, module health checks, feature flags, dependency validation, and module boundary checks. -
WalletSessionabstraction with aCoxyNativeWalletSessionimplementation. -
SignerProviderinterface separating wallet/session logic from signer/key custody. -
TransactionPlansemantic representation and transaction-preview workflow. - Structured logging with secret redaction and correlation IDs.
- Audit-log foundation for sensitive events.
- Provider-health model for Cardano infrastructure.
- Core event-outbox pattern in MySQL for reliable module events.
- CI release checks, dependency scanning, security scanning, and reproducible build procedures where practical.
The Coxy vault, recovery process, browser-extension boundary, key derivation, storage migration, and transaction-approval path receive focused review. Seeds and private keys must never enter logs, analytics, AI context, or general module events.
Every core module gains unit tests, integration tests, property-based tests where serialization/arithmetic/parsing is involved, regression fixtures, documented test commands, and an owned threat model. A developer should be able to disable every not-yet-needed advanced module without changing Silver behavior.
R0 is complete only when:
- Current wallet behavior is covered by repeatable regression tests.
- The Silver wallet uses the new session/transaction abstractions without user-visible regression.
- Vault migrations and wallet restore have repeatable test evidence.
- Advanced modules can be disabled through configuration.
- The CI pipeline blocks obvious module-boundary and test failures.
- Application logs are structured and secret-redacted.
- A failed AI or experimental provider does not prevent ordinary Silver wallet operation.
Target window: 2026 Q4–2027 Q1
Primary mode: Gold
Roadmap status: Target
R1 makes Coxy interoperable with the wider Cardano wallet ecosystem while retaining Coxy's existing native wallet. Coxy must become both a provider to Cardano dApps and a consumer of external CIP-30 wallet providers.
The browser extension exposes Coxy under the expected Cardano wallet provider boundary. Origin permissions, enable() approval, connection revocation, signTx, signData, transaction submission where supported, network handling, and capability reporting are implemented behind a strict extension message boundary.
The Coxy web experience discovers compatible providers exposed by the user's browser, allows the user to choose the provider, creates a normalized Cip30WalletSession, and leaves private-key custody inside the external wallet. Lace, Eternl, and other representative implementations are treated as compatibility test targets rather than hard-coded business logic.
R1 introduces the hardware-signing module and begins with a Trezor adapter where device and Cardano support permit. Hardware signing is not modeled as ordinary CIP-30. The signer module is responsible for discovery, device capability, prompts, signing, disconnect/rejection, and error normalization.
Gold requires a maintained compatibility matrix that records:
- Wallet provider name and version.
- Network behavior.
- UTxO behavior.
- Address encoding behavior.
- Partial-signing support.
-
signDatasupport. - Accepted CIP-30 extensions.
- Governance capability where applicable.
- Error behavior.
- Account switching behavior.
- Known interoperability workarounds.
R1 is ready for closed beta when:
- Representative Cardano dApps can connect to Coxy on test networks.
- Coxy can connect to representative external wallets without importing their seeds.
- Account and network changes are detected.
- Capability negotiation is explicit.
- External wallet signatures are always approved in the external wallet.
- Hardware signer signing/rejection paths work in supported test setups.
- Malicious-origin, replay, malformed CBOR, wrong-network, and permission tests pass.
Target window: 2027 Q2–Q3
Primary mode: Gold
Roadmap status: Target
R2 converts Gold from interoperability beta into a dependable professional Cardano wallet mode. This release is the proof that Coxy can add substantial capability without damaging Silver.
Gold adds provider failover, compatibility telemetry that respects privacy, clearer transaction inspection, dApp connection management, multiple session/account handling, hardware signer error recovery, advanced staking/governance exposure, and stablecoin-aware Cardano asset presentation.
Before broad release, the team commissions an external review of the browser-extension security boundary, CIP-30 origin permissions, wallet approval flow, hardware signer integration, transaction-plan-to-serialization integrity, and secure storage behavior.
Gold moves through:
Internal test
↓
Named Cardano community testers
↓
Canary mainnet cohort
↓
Controlled release
↓
General availability
Silver remains available throughout the Gold rollout. A user does not need to enable external-wallet or hardware features merely because Gold exists.
Gold reaches GA when:
- No unresolved critical or high-severity wallet/extension findings remain without formal acceptance and mitigation.
- Silver regression tests remain green.
- The external-wallet compatibility matrix covers the supported launch wallets.
- Provider failover and degraded behavior have been exercised.
- Hardware signing does not expose device secrets to Coxy.
- Stablecoin and native-token transfers are correctly represented.
- dApp permissions can be reviewed and revoked.
- Support/runbooks exist for connection failures, wrong accounts, network mismatches, and provider outages.
Target window: 2027 Q3–Q4
Primary mode: Diamond foundation
Roadmap status: Target / research for evolving standards
R3 creates the shared decision and identity foundations before any production programmable-asset or regulated-business workflows are added.
The Policy Engine implements versioned policies, evidence objects, and deterministic ALLOW, DENY, and REVIEW decisions. It receives normalized evidence from identity, credential, compliance, sanctions, jurisdiction, asset, and provider modules without becoming a vendor-specific KYC engine.
A generic metadata service is completed before CIP-0170-specific logic. This isolates metadata serialization, validation, size limits, canonicalization, and transaction-plan integration from higher identity semantics.
CIP-0170 is implemented as a versioned codec/adapter. Initial development uses controlled fixtures and test vectors. Authority windows, AUTH_BEGIN, ATTEST, and AUTH_END are represented as explicit domain types rather than loosely parsed arbitrary JSON.
The team integrates a standards-compatible KERI path, including AID lifecycle, KEL discovery, interaction events, key rotation, OOBI/watcher behavior where appropriate, ACDC credential handling, revocation state, and trust-root configuration. Cardano wallet keys and KERI identity keys remain separate security domains.
R3 exits when:
- The Policy Engine is deterministic and property-tested.
- Generic metadata round trips are validated against known vectors.
- CIP-0170 records can be encoded, decoded, and strictly validated in a controlled environment.
- A KERI identity can be created/resolved/rotated in the selected test infrastructure.
- ACDC credentials can be received and verification evidence can be produced.
- Identity failure does not affect Silver/Gold operation.
Target window: 2028 Q1–Q2
Primary mode: Diamond
Roadmap status: Target
R4 turns the identity foundation into real user and business workflows. The user should interact with concepts such as "verified organization", "authorized signer", "credential", and "attestation" without being forced to understand low-level KERI terminology.
The beta supports:
- Identity/AID creation or connection.
- KEL verification and key rotation.
- Credential receipt/import.
- Credential-chain verification.
- Credential revocation/status checks.
- CIP-0170 authority establishment.
- Document/data digest attestation.
- Evidence-based verification.
- Authority termination/revocation.
- External-wallet-to-identity binding through a signed domain-separated challenge.
KYC, AML risk, sanctions, jurisdiction, and enhanced-review providers are introduced behind provider-neutral contracts. Coxy stores minimum required evidence and explicitly separates public verification state from confidential customer data.
vLEI is introduced as an optional trust-framework adapter, not as a dependency of generic Coxy identity. Coxy should initially focus on holder, presenter, verifier, and qualified-provider integration rather than representing itself as a credential issuer without the required governance position.
The first beta should use selected organizations, educational partners, developers, or controlled business users. The purpose is to test identity recovery, account changes, credential revocation, authority windows, user comprehension, and verifier evidence—not to maximize user count.
R4 exits when:
- A complete identity lifecycle works end-to-end.
- Verifiers explain the evidence path rather than returning only
trueorfalse. - Revoked credentials and expired authority are correctly rejected.
- External-wallet binding includes replay protection and account-change handling.
- Identity secrets remain separate from Cardano keys.
- KYC/compliance evidence is encrypted and minimized.
- Security review covers verifier, KERI key handling, metadata, and identity UI.
Target window: 2028 Q2–Q4
Primary mode: Diamond
Roadmap status: Experimental → pilot
R5 combines identity and policy with controlled assets and selective privacy. This is the point where Coxy begins demonstrating a differentiated business platform rather than simply adding more wallet screens.
Because programmable-token work is still evolving, Coxy implements it behind a versioned adapter and testnet/mainnet feature flags. The initial scope focuses on discovery, capability disclosure, balance presentation, transfer planning, policy preflight, and supported candidate functions such as mint, burn, transfer, freeze/unfreeze, and issuer action only where the implementation in use is sufficiently mature and audited.
A controlled RWA pilot connects:
Verified issuer identity
↓
Asset/legal-document references
↓
Holder eligibility policy
↓
Programmable asset rules
↓
Subscription / transfer / redemption workflow
↓
Issuer administration with approval evidence
↓
Audit trail
The pilot must make issuer powers visible to holders. Freeze, seizure, forced transfer, additional minting, redemption restrictions, and transfer restrictions may never be hidden.
The first privacy use case should be narrow and auditable. Examples include proving that a credential is valid, that a user satisfies an eligibility condition, or that a jurisdiction/age requirement is met without publishing the full identity record. Coxy must not market Midnight as a switch that makes ordinary Cardano transactions private.
Issuer powers require stronger controls than consumer transfers. The roadmap requires multi-approval or threshold workflows, hardware/HSM-grade signing where appropriate, role credentials, reason/reference fields, append-oriented audit evidence, and explicit approval screens.
R5 exits when:
- Programmable assets can be safely exercised in supported test environments.
- Policy preflight and on-chain enforcement are clearly separated.
- A controlled RWA can complete issue/hold/transfer/redeem or equivalent pilot workflows.
- Issuer actions have documented authority and audit evidence.
- Privacy flows have data-flow and leakage reviews.
- No private identity documents are published to public Cardano metadata.
- Ordinary Cardano assets remain unaffected when programmable assets are disabled.
Target window: 2028 Q4–2029 Q1
Primary mode: Diamond
Roadmap status: Target, with standards/audit dependency
R6 is the transition from impressive prototypes to defensible production capability. Every Diamond component is evaluated independently; Coxy does not need to activate every possible identity, programmable-token, RWA, or privacy feature at the same time.
Diamond uses capability-specific flags such as:
identity.enabled
identity.mainnetAttestation
compliance.enabled
programmableAssets.enabled
programmableAssets.mainnetTransfer
programmableAssets.issuerActions
rwa.enabled
midnightPrivacy.enabled
vlei.enabled
A vulnerability in programmable issuer actions must not force identity verification or Gold wallet functions offline.
Before production activation, relevant components receive independent audits, penetration testing, contract review, privacy data-flow review, dependency review, migration testing, and incident-response exercises. A controlled organization pilot precedes broad customer availability.
Diamond controlled production requires:
- Closed critical findings and managed high findings.
- Evidence-based identity verification and revocation.
- Audited production on-chain contracts for any customer-value controls.
- Documented issuer powers and customer disclosures.
- Privacy disclosure statements reviewed by security/privacy specialists.
- Jurisdiction-specific KYC/AML policies where such workflows are marketed.
- Operator runbooks, feature kill switches, audit export, backup/recovery, and monitoring.
Target window: 2029 Q1–Q2
Primary mode: Platinum foundation
Roadmap status: Target
R7 adds multi-chain capability without turning Coxy into a collection of if chain === ... branches. A chain-neutral identifier and ChainAdapter contract must exist before Bitcoin and Ethereum functionality expands into the portfolio, remittance, AI, or finance layers.
The Chain Router resolves normalized account/asset/action requests to a chain-specific adapter. Cardano remains one adapter. Bitcoin and Ethereum gain independent modules that own network configuration, address validation, fee estimation, serialization, provider selection, confirmation rules, and chain-specific security tests.
The portfolio module aggregates normalized positions while preserving chain identity. Symbols alone are never treated as unique asset identifiers. Stablecoin variants, bridges, wrapped assets, native assets, and token contracts must remain distinguishable.
Gold already handles Cardano stablecoins as Cardano assets. Platinum adds multi-chain stablecoin risk metadata, provider redemption information, conversion paths, treasury views, and settlement eligibility.
R7 exits when:
- Bitcoin and Ethereum adapters pass chain-specific unit/integration/property tests.
- Chain failures remain isolated.
- Portfolio totals cannot confuse same-symbol assets across networks.
- Fees and confirmation semantics are chain-aware.
- AI explanations receive normalized, non-secret chain context.
- No multi-chain feature weakens existing Cardano wallet security.
Target window: 2029 Q2–Q4
Primary mode: Platinum
Roadmap status: Partner-dependent target
R8 adds regulated financial rails through licensed and authorized partners. The first objective is not worldwide coverage. The first objective is one legally and operationally well-defined corridor that proves the entire lifecycle from quote to beneficiary credit and reconciliation.
Coxy adds provider-neutral FiatAccountProvider and BankingProvider interfaces. Provider tokens/consents are encrypted and scope-limited. Coxy never stores online-banking passwords. The user interface clearly distinguishes self-custodied blockchain assets from provider-held or bank-held fiat balances.
The FX module normalizes source/destination currencies, quote expiry, precision, spread, fees, provider identity, and settlement conditions. Users see the amount sent, amount received, rate, fees, and estimated arrival before authorization.
The first live corridor is configuration-driven and contains:
- Source and destination countries.
- Source and destination currencies.
- Approved provider set.
- KYC level and customer eligibility.
- Sanctions/AML controls.
- Transfer limits.
- Beneficiary methods.
- Reporting requirements.
- Travel Rule requirements where applicable.
- Refund and failure behavior.
- Settlement routes.
- Reconciliation rules.
- Support/escalation contacts.
The Settlement Router considers only legally and operationally permitted routes. It may compare bank, stablecoin, crypto, or other rails by price, speed, liquidity, availability, provider health, risk, finality, and refundability. AI may explain the routes but may not bypass a policy denial.
Every remittance has independent lifecycle evidence for intent, quote, authorization, provider submission, provider status, source settlement, destination payout, fee/FX result, reconciliation, and audit. Duplicate callbacks and timeouts must be idempotently handled.
R8 exits when:
- At least one approved institutional/provider arrangement is contractually and technically ready.
- Sandbox-to-production credential handling is secure.
- Beneficiary verification and payment authorization are explicit.
- Travel Rule/reporting mapping is documented for the corridor where required.
- Provider callbacks are authenticated and idempotent.
- Reconciliation can detect discrepancies.
- Fraud and unusual-payment controls are active.
- Customer support and incident escalation are tested.
- Pilot limits are conservative and configurable.
Target window: 2029 Q4–2030 H1
Primary mode: Platinum
Roadmap status: Partner- and regulation-dependent
R9 expands the successful financial pilot into a controlled global-finance product across selected countries, chains, stablecoins, banks, FX providers, remittance corridors, and RealFi protocols.
Platinum should launch as an explicit supported set rather than an ambiguous claim of universal coverage. The production configuration identifies:
- Supported countries and residency rules.
- Supported fiat currencies.
- Supported chains/networks.
- Supported stablecoins and risk classifications.
- Supported financial institutions/providers.
- Supported remittance corridors.
- Supported RealFi protocols.
- Customer eligibility and limits.
- Support hours and escalation paths.
RealFi and other financial protocols are connected through FinancialProtocolAdapter. Coxy exposes market/position data, fees, collateral requirements, liquidation conditions where applicable, contract addresses, protocol risks, and semantic transaction effects. Protocol actions remain independently feature-flagged.
Treasury tools may be introduced for business users only after reconciliation and provider controls are stable. Route liquidity, stablecoin inventory, FX exposure, provider concentration, and settlement cut-off risk must be measurable before Coxy attempts high-volume cross-border routing.
Platinum controlled production requires:
- Production partner SLAs and escalation routes.
- Proven reconciliation over sustained pilot activity.
- No unresolved customer-money discrepancies.
- Fraud/risk monitoring and manual-review procedures.
- Security review of bank/remittance integrations.
- Data-retention/privacy rules mapped by jurisdiction.
- Disaster recovery and provider failover tests.
- RealFi risks clearly disclosed.
- Financial operations staffed for the supported hours/markets.
Target window: 2030 onward
Primary mode: Platinum and platform-wide
Roadmap status: Continuous
R10 is not a single release. It is the operating model for continuous addition of technologies and markets without destabilizing the core platform.
Future expansion may include:
- Additional Cardano CIPs and governance capabilities.
- Additional CIP-30 wallets.
- Additional hardware signers.
- Additional KERI/credential ecosystems.
- Additional privacy proofs and Midnight use cases.
- Additional programmable-asset standards and RWA templates.
- Additional Bitcoin/EVM or future-chain adapters.
- Additional stablecoins and issuer integrations.
- Additional bank/open-banking/PSP providers.
- Additional African and global remittance corridors.
- Additional FX/liquidity providers.
- Additional RealFi/lending/credit protocols.
- Institutional custody or HSM integrations where business requirements justify them.
- Additional AI providers or local/private AI deployments.
Every expansion follows the same atomic-module and provider-adapter rules. A new provider must not be allowed to bypass Coxy's policy, logging, audit, health, authorization, test, and incident-response layers simply because it offers a convenient SDK.
AI is a continuous workstream and is never postponed until Platinum.
Silver AI focuses on education and safe explanations: seed phrases, addresses, fees, staking, tokens, scams, and transaction meaning. The Guardian uses deterministic signals such as new recipient, unusual amount, unknown dApp origin, or token minting to provide understandable warnings.
Gold AI explains external-wallet permissions, CIP-30 connections, hardware prompts, governance actions, collateral, dApp interactions, and transaction effects. It can compare detected wallet capabilities but cannot manipulate external wallet approval.
Diamond AI explains identity verification, credentials, revocation, RWA restrictions, programmable-asset issuer powers, KYC review status, and selective-disclosure requests. It may summarize evidence but must distinguish cryptographic/policy facts from model-generated interpretation.
Platinum AI explains FX quotes, remittance routes, fees, stablecoin exposure, chain risk, RealFi positions, settlement status, and unusual beneficiary/payment patterns. High-risk payment warnings must include deterministic evidence and give users a safe cancellation/verification path.
Across all releases:
- No raw seed/private key access.
- No raw biometric storage.
- No online-banking password access.
- No direct signer permission.
- No compliance override permission.
- No issuer-admin approval permission.
- No automatic beneficiary substitution.
- No hidden amount modification.
- Model/provider failure must degrade to deterministic wallet behavior.
- Prompt/response telemetry must be minimized and governed.
Security is a delivery stream with its own milestones rather than a final pre-launch task.
| Stage | Mandatory security focus |
|---|---|
| R0 | Vault, mnemonic/recovery, transaction intent, browser extension, logging redaction, migrations, CI supply chain. |
| R1–R2 | CIP-30 origins/permissions, malicious dApps, external wallet sessions, hardware signers, serialized transaction integrity. |
| R3–R4 | KERI secret handling, KEL verification, credential-chain/revocation, trust roots, identity binding, compliance data. |
| R5–R6 | Programmable-asset contracts, issuer administration, RWA authority, privacy disclosure, testnet/mainnet feature gates. |
| R7 | Multi-chain signing, chain-specific fee/address/serialization security, cross-chain asset confusion. |
| R8–R9 | Bank/API authentication, provider tokens, callbacks/webhooks, Travel Rule data, remittance fraud, reconciliation, customer-money controls. |
| R10 | Continuous audits, dependency upgrades, new provider/chain threat models, incident exercises. |
- Threat model when a module is created.
- Threat model update when trust boundaries change.
- Security review before testnet feature becomes canary production.
- External audit for contracts or systems that can materially affect customer funds.
- Penetration testing before major Gold/Diamond/Platinum releases.
- Dependency and supply-chain scan on every CI release.
- Incident-response tabletop exercises at least before each mode's controlled production release.
A feature is blocked from production if any of the following remains true:
- Known private-key exposure path.
- Broken or unverified wallet restore/migration.
- Unresolved critical vulnerability.
- Unreviewed production smart contract controlling customer assets.
- Unauthenticated high-risk provider callback.
- Identity verifier accepts revoked/invalid authority.
- Privacy workflow leaks protected information beyond documented disclosure.
- Remittance/banking flow cannot reconcile customer money.
- Required legal/compliance owner is unknown.
Coxy's test programme expands with product risk.
Every module tests deterministic domain behavior, validators, parsers, policy rules, data transformations, amount arithmetic, and safe error paths. Node's built-in node:test and assert are preferred where practical. PHP modules use lightweight test scripts or a small approved test tool where needed.
Integration tests exercise real interfaces such as MySQL migrations, Cardano provider calls, CIP-30 wallet stubs or representative providers, hardware signer test environments, KERI/KERIA services, compliance sandboxes, bank/FX/remittance sandboxes, and Midnight development environments.
Property tests are mandatory where large input spaces or adversarial serialization are important, including:
- Cardano addresses and network IDs.
- CBOR and metadata encode/decode.
- CIP-0170 records.
- Multi-asset arithmetic and value conservation.
- Policy determinism.
- KERI/identifier parsing.
- Programmable-asset capability parsing.
- FX rounding/precision.
- Quote/fee calculations.
- Idempotent callbacks.
- Normalization of provider responses.
Committed vectors are maintained for wallet derivation, addresses, transactions, metadata, identity events, credentials, programmable-asset artifacts, and structured financial message mapping. Changes to a golden vector require explicit review.
The release suite includes at least:
Silver: create → receive → send → lock → restore → resend.
Gold: connect dApp → approve → sign → external wallet connect → sign through external wallet → hardware signer path.
Diamond identity: create identity → verify credential → establish authority → attest → verify → rotate → revoke → verify denial.
Diamond programmable asset: register → mint → compliant transfer → non-compliant rejection → issuer action → disable module → ordinary asset still works.
Platinum remittance: create beneficiary → quote → compliance → route → authorize → submit → provider status → payout → reconcile → receipt → duplicate callback test.
Application logs are structured JSON with timestamp, module, event, severity, correlation ID, sanitized context, provider request identifier where safe, latency, and result. Secret values are forbidden.
Audit records are separate from debug logs. They cover sensitive actions such as vault migration, identity creation, credential changes, authority establishment/revocation, issuer freeze/seize, policy changes, compliance overrides, bank beneficiary changes, remittance authorization, provider configuration, administrator actions, and security-setting changes.
Roadmap dashboards should include:
- API error and latency rates.
- Provider availability and circuit-breaker state.
- Cardano transaction submission and confirmation latency.
- CIP-30 connection/signing failures by provider/version.
- KERI/KEL resolution latency.
- Credential verification failures/revocations.
- Policy decisions by category.
- Programmable-asset script failures.
- Bank/FX/remittance quote success.
- Payment state age.
- Callback failures/retries.
- Reconciliation exceptions.
- Outbox backlog.
- Database connection/query latency.
- AI-provider latency/failure with privacy-safe metrics.
Coxy does not need every specialist full-time from the first day. It does need the right skills before the relevant stage enters production.
Recommended core ownership:
- Product lead.
- Architecture lead.
- Two or more Cardano/JavaScript wallet engineers.
- Browser-extension engineer.
- Vanilla web/UI engineer.
- PHP/MySQL engineer.
- QA/test engineer.
- Security reviewer or retained security specialist.
- DevOps/CI owner.
- Technical writer/developer-documentation owner.
Add or formalize:
- CIP-30 compatibility/test owner.
- Hardware-wallet integration engineer.
- Additional QA automation capacity.
- External security audit relationship.
- UX specialist focused on advanced transaction approvals.
Before Diamond beta, add named owners for:
- KERI/KEL/ACDC identity engineering.
- On-chain programmable-asset engineering.
- Privacy/Midnight integration.
- Compliance/provider integration.
- Legal/compliance policy mapping.
- RWA product/legal-structure coordination.
- Security engineering for identity and contracts.
Before financial pilots, add:
- Financial-integration engineers.
- Bank/open-banking/PSP integration owner.
- FX/liquidity engineer or specialist.
- Remittance/corridor product owner.
- Reconciliation/data engineer.
- Financial operations lead.
- Fraud/risk operations specialist.
- Compliance/legal specialists for launch markets.
- Partnership/business-development lead.
- SRE/on-call capacity appropriate to money movement.
Teams should be organized around atomic modules and stable contracts rather than frontend/backend silos alone. A module team may include a web developer, PHP developer, test engineer, and specialist domain reviewer while sharing common security, architecture, and DevOps standards.
Some of Coxy's highest-value capabilities cannot be completed purely through code. Partnership activity therefore starts early and runs in parallel with engineering.
Gold requires community interoperability relationships with wallet providers, dApp developers, hardware-wallet vendors, and Cardano infrastructure providers. These relationships improve compatibility testing and give Coxy early visibility into API changes.
Diamond may require:
- KERI infrastructure providers or operators.
- Credential issuers/verifiers.
- KYC/AML/sanctions providers.
- vLEI/QVI ecosystem participants where applicable.
- RWA issuers, legal advisors, custodians, registries, and auditors.
- Midnight/privacy ecosystem partners.
- Independent smart-contract and identity security auditors.
Platinum partnership work should begin well before production coding is complete because onboarding can be lengthy. Required categories may include:
- Banks.
- Authorised Dealers / relevant regulated FX entities in target markets.
- Money-transfer/remittance providers.
- Payment service providers.
- Crypto-asset service providers where applicable.
- Stablecoin issuers/redemption providers.
- FX/liquidity providers.
- Banking/open-banking API providers.
- Travel Rule providers.
- Fraud/risk providers.
- RealFi/financial protocol teams.
- Legal, regulatory, and tax specialists.
Coxy should prioritize one or a small number of corridors where customer need, partner quality, regulatory clarity, payout coverage, pricing, and operational support are strongest. The roadmap should not treat "global" as an initial launch requirement.
Metrics should measure customer safety and product quality, not only wallet installs or transaction volume.
- Wallet creation success rate.
- Restore success rate against known wallets/vectors.
- First receive/send completion rate.
- Failed transaction rate attributable to Coxy.
- Support requests per active beginner.
- Learning-content completion and comprehension indicators.
- Security-warning user understanding.
- Zero seed/private-key telemetry incidents.
- CIP-30 connection success by supported wallet/version.
- dApp signing success rate.
- Account/network-change detection rate.
- Hardware signer success/rejection handling.
- Provider failover success.
- Permission-revocation reliability.
- Silver regression pass rate.
- External-wallet support incident rate.
- Credential verification success/latency.
- Revoked credential rejection rate.
- CIP-0170 verification correctness against test vectors.
- Identity recovery/key-rotation success.
- Programmable-asset transaction preflight accuracy.
- On-chain policy rejection/error rate.
- RWA issuer-action audit completeness.
- Privacy disclosure policy compliance.
- Zero leakage of protected KYC/identity documents to public chain, AI, or logs.
- Quote success rate.
- Quote-to-transfer conversion.
- Settlement success and median completion time.
- Full-fee/FX disclosure accuracy.
- Beneficiary error rate.
- Reconciliation exception rate.
- Time to resolve reconciliation exceptions.
- Fraud loss rate and prevented suspicious-payment events.
- Provider availability/failover success.
- Travel Rule/reporting completeness where required.
- Customer support resolution time.
- Liquidity/route availability by corridor.
- Critical-path regression pass rate.
- Mean time to detect and restore provider failures.
- Percentage of modules with threat model/runbook/owner.
- Dependency vulnerability aging.
- Change failure rate.
- Rollback time.
- Test flake rate.
- Security finding closure time.
- Documentation freshness.
| Risk | Impact | Mitigation |
|---|---|---|
| Silver becomes too complex | Loss of beginner value and educational mission. | Progressive disclosure, mode profiles, Silver UX ownership, mandatory Silver regression/UX tests. |
| Draft standards change | Rework in CIP-0170/CIP-113 modules. | Versioned adapters, test vectors, feature flags, standards watch, no assumptions spread through core. |
| CIP-30 wallet differences | Failed connections/signatures and poor Gold UX. | Compatibility layer, capability negotiation, version matrix, representative provider tests. |
| Hardware signer incompatibility | Transaction failures or dangerous signing assumptions. | Dedicated SignerProvider, device capability checks, hardware-specific test vectors, vendor coordination. |
| Identity verifier error | False verification or invalid authority acceptance. | Evidence-based verification, revocation checks, independent review, trust-policy configuration, property/vector tests. |
| Programmable-asset contract flaw | Locked/seized/lost customer assets. | Testnet-first, independent smart-contract audits, conservative mainnet flags, issuer-action controls. |
| Privacy leakage | Exposure of KYC or sensitive identity data. | Data-flow reviews, minimal disclosure, no raw identity documents in public metadata, AI/log redaction. |
| AI hallucination or overreach | Misleading customer guidance or security decisions. | Deterministic controls first, advisory-only permission model, explainable signals, offline-safe behavior. |
| Multi-chain attack surface expands | More wallet/signing vulnerabilities. | Isolated ChainAdapters, chain-specific audits/tests, normalized TransactionPlan, provider separation. |
| Financial provider dependency | Outages, changed APIs, pricing or partner failure. | Provider interfaces, health checks, failover where possible, multiple partners, corridor limits. |
| Regulatory/licensing mismatch | Product cannot legally operate in a market. | Corridor-specific legal mapping, licensed partners, explicit responsibility matrix, feature gating. |
| Remittance reconciliation failure | Customer-money loss or unresolved payouts. | Independent reconciliation module, idempotency, suspense/exception process, automatic route halt. |
| Fraud/social engineering | Customer losses and reputational damage. | AI Guardian + deterministic checks, beneficiary verification, step-up authorization, limits, manual review. |
| Contributor complexity | Slow development and accidental coupling. | Atomic module standard, CODEOWNERS, ADRs, documentation templates, boundary checks, stable contracts. |
| Dependency supply-chain compromise | Malicious or vulnerable package enters wallet. | Minimal dependencies, pinning, SBOM/notices, scanning, reproducible builds, manual review of crypto dependencies. |
The matrix below shows the first release in which each principal module becomes a critical delivery item. A module may exist earlier as research or a stub.
| Module | First critical release | Mode | Depends on |
|---|---|---|---|
wallet-core |
R0 | Silver | Existing Coxy functionality |
wallet-session |
R0 | Silver+ | wallet-core |
transaction-engine |
R0 | Silver+ | wallet-session, cardano-chain |
audit-log |
R0 | All | MySQL/core contracts |
provider-health |
R0 | All | shared provider contracts |
ai-assistant |
R0 onward | All | sanitized context only |
ai-guardian |
R0 onward | All | TransactionPlan, deterministic signals |
cip30-provider |
R1 | Gold+ | extension, wallet-session |
cip30-consumer |
R1 | Gold+ | wallet-session |
hardware-signers |
R1/R2 | Gold+ | SignerProvider |
stablecoins |
R2 | Gold+ | cardano-chain, portfolio |
policy-engine |
R3 | Diamond+ | audit/evidence contracts |
metadata |
R3 | Silver+/Diamond use | transaction-engine |
identity-cip170 |
R3/R4 | Diamond+ | metadata, keri, credentials |
keri |
R3/R4 | Diamond+ | identity vault/provider adapters |
credentials-acdc |
R3/R4 | Diamond+ | keri/trust providers |
compliance |
R4 | Diamond+ | policy-engine, provider adapters |
vlei |
R4 optional | Diamond+ | credentials-acdc |
programmable-assets |
R5 | Diamond+ | policy-engine, identity, cardano-chain |
rwa |
R5 | Diamond+ | identity, policy, programmable-assets |
midnight-privacy |
R5 | Diamond+ | policy, identity, privacy provider |
chain-router |
R7 | Platinum | TransactionPlan/ChainAdapter |
bitcoin-chain |
R7 | Platinum | chain-router |
ethereum-chain |
R7 | Platinum | chain-router |
fiat |
R8 | Platinum | provider/auth core |
banking |
R8 | Platinum | fiat, compliance, audit |
fx |
R8 | Platinum | fiat, providers |
travel-rule |
R8 | Platinum | identity/compliance, regulated providers |
remittance |
R8 | Platinum | banking/fx/compliance |
settlement-router |
R8 | Platinum | remittance, provider-health, policy |
reconciliation |
R8 | Platinum | banking/remittance/providers |
realfi |
R9 | Platinum | chain-router, TransactionPlan, policy |
A module is not "done" because its main screen works. Every production module must satisfy the following minimum definition.
- Atomic directory exists.
-
module.jsondeclares versions, mode availability, dependencies, permissions, events, and health endpoint. - No hidden cross-module imports.
- Provider integrations are behind adapters.
- Public contracts are versioned.
- Feature flag supports safe disablement.
- SQL schema/migrations/indexes are reviewed.
- Rollback procedure is documented.
- Secrets are excluded or encrypted according to the module threat model.
- Retention policy is documented.
- Backup/restore impact is known.
- Unit tests pass.
- Integration tests pass.
- Property tests cover parsing/arithmetic/serialization where applicable.
- Security tests cover known abuse cases.
- End-to-end scenario exists for the module's critical workflow.
- Silver/Gold regression suite passes if the module can affect shared code.
- Threat model exists and is current.
- Required audit/security review is complete.
- Logs are secret-redacted.
- Authorization rules are server-side or signer-side where required.
- High-risk actions create audit evidence.
- Kill switch and incident behavior are documented.
- Health endpoint exists.
- Metrics/alerts exist.
- Runbook exists.
- Provider timeout/retry behavior is defined.
- Failure mode is understandable to users.
- Rollback has been tested for material releases.
- README explains purpose and setup.
- API/contracts are documented.
- External dependencies are listed.
- Secrets/permissions are documented.
- Test commands are documented.
- Changelog entry exists.
- Architecture decision record exists for new shared dependencies or boundaries.
The roadmap is designed for many developers. GitHub milestones, issues, labels, CODEOWNERS, and architecture decision records should reflect module boundaries.
R0-SILVER-FOUNDATION
R1-GOLD-INTEROPERABILITY-BETA
R2-GOLD-GA
R3-DIAMOND-FOUNDATION
R4-DIAMOND-IDENTITY-BETA
R5-DIAMOND-ASSET-PRIVACY-PILOT
R6-DIAMOND-CONTROLLED-PRODUCTION
R7-PLATINUM-MULTICHAIN
R8-PLATINUM-REMITTANCE-PILOT
R9-PLATINUM-CONTROLLED-PRODUCTION
R10-GLOBAL-EXPANSION
mode:silver
mode:gold
mode:diamond
mode:platinum
area:wallet-core
area:cip30
area:hardware
area:identity
area:policy
area:programmable-assets
area:rwa
area:privacy
area:multichain
area:banking
area:fx
area:remittance
area:realfi
area:ai
area:security
area:testing
area:docs
risk:critical
risk:high
risk:medium
risk:low
status:research
status:blocked
status:partner-dependent
status:experimental
status:ready-for-review
Every significant issue should identify:
- Problem statement.
- Module owner.
- Roadmap milestone.
- Mode(s) affected.
- Public contract changed, if any.
- Security/privacy impact.
- SQL/data impact.
- Test plan.
- Documentation impact.
- Feature flag.
- Rollback/failure behavior.
- Acceptance criteria.
High-risk modules require both a domain reviewer and security reviewer. SQL migrations require data review. On-chain changes require on-chain/security review. Financial-provider integrations require domain, security, and compliance/operations review. Shared-core changes require architecture review and must run the full Silver/Gold regression suite.
The roadmap should be reviewed at least quarterly by product, architecture, security, QA, operations, and relevant domain leads. Platinum milestones additionally require partnership and legal/compliance participation.
A standards owner tracks changes affecting CIP-30, CIP-0170, CIP-113, Cardano governance, hardware-wallet interoperability, KERI/ACDC/vLEI, Midnight, payment standards, and relevant provider APIs. A standards change results in an ADR or module-version change rather than informal code changes scattered through the repository.
An ADR is required for:
- New shared dependency.
- New cross-module contract.
- New secret class.
- New blockchain.
- New financial provider category.
- New trust root.
- Change in key custody.
- Change in regulated-role responsibility.
- Change in public on-chain data model.
- Change in privacy disclosure model.
A target date is reforecast when a prerequisite is not ready. The team must not hide the delay by shrinking security or testing scope. Public roadmap communication should distinguish "research", "beta", "controlled production", and "general availability" so customers do not interpret experimental capabilities as finished financial products.
The next 90 days should focus almost entirely on R0 and the first Gold foundations. This period is the highest-leverage part of the entire roadmap because every future module depends on decisions made here.
- Freeze a known-good current Coxy build.
- Document current wallet storage and key flows.
- Capture transaction and recovery fixtures.
- Create regression tests for create/restore/send/receive/token/staking.
- Inventory third-party dependencies and licences.
- Create root
SECURITY.md,CONTRIBUTING.md,CODEOWNERS, and ADR template. - Define release channels and feature-flag strategy.
- Introduce module directory template.
- Introduce
module.jsonmanifest. - Add module registry and dependency checks.
- Add health endpoint convention.
- Add structured logging and correlation IDs.
- Add module-owned SQL migration convention.
- Add event-outbox table/worker.
- Wrap current wallet in
CoxyNativeWalletSession. - Create
SignerProvidercontract. - Create semantic
TransactionPlan. - Add transaction preview validation.
- Ensure signer receives the exact reviewed intent/serialization path.
- Add property tests for transaction normalization and value arithmetic.
- Review vault encryption/versioning.
- Verify restore paths.
- Review extension content-script/injected/service-worker boundaries.
- Add origin/request schema validation.
- Add secret-redaction tests.
- Add dependency/security scans to CI.
- Implement
window.cardano.coxytest provider. - Add permission/connection lifecycle.
- Add test dApp.
- Add external provider discovery for Coxy Connect.
- Build
Cip30WalletSessionprototype. - Begin Lace/Eternl compatibility fixtures.
- Run representative dApp flows on Cardano test networks.
- Run external-wallet sign/submit flows.
- Define hardware signer adapter contract and Trezor spike.
- Document compatibility matrix.
- Review R0 exit criteria.
- Create the R1 issue backlog and owners.
At the end of the 90-day period, Coxy should not yet contain unfinished Diamond and Platinum complexity in its core. Instead, it should have a demonstrably safer Silver wallet, strong regression protection, atomic module boundaries, a normalized wallet/signing architecture, better transaction review, and a working Gold interoperability prototype. That foundation creates the fastest safe path to every advanced feature in the product specification.
This roadmap is derived from the Coxy Product Specification, including its product principles, atomic-module standard, shared-core abstractions, four-mode definition, module catalogue, security boundaries, test strategy, resource requirements, release gates, and beginning-to-end delivery plan.
Primary source:
The product specification itself maintains the authoritative list of standards and reference sources for Cardano CIP-30, CIP-0170, CIP-113, KERI/KERIA, vLEI, Midnight, Trezor/hardware interoperability, Chrome extension security, Cardano stablecoins, South African cross-border finance, Travel Rule requirements, FATF payment transparency, and ISO 20022/API interoperability.
The roadmap must be updated when the product specification changes materially. The specification defines what Coxy is intended to become; this roadmap defines the order, gates, people, evidence, and staged releases required to get there safely.
Coxy's path to becoming a world-class wallet is not achieved by adding the largest number of features as quickly as possible. It is achieved by protecting the original Silver experience, establishing an unusually disciplined modular core, proving Cardano interoperability through Gold, proving trustworthy identity and controlled assets through Diamond, and only then connecting regulated financial rails and multiple chains through Platinum.
The roadmap therefore treats architecture, security, testing, auditability, provider independence, and explicit user authorization as delivery outcomes in their own right. A feature that cannot be isolated, tested, monitored, audited, disabled, and explained to the user is not complete.
If this discipline is maintained, Coxy can grow from a student wallet into a global financial platform without abandoning the simplicity that made the original product valuable and without forcing future technologies to become another rewrite of the wallet.
Bernard Sibanda is a global Technology Entrepreneur, Web3 and Software Consultant with a deep focus on Cardano Blockchain, Midnight and Community building.
Key Positions:
- Founder, CTO, Developer Advocate cohort #1, Fullstake Developer, Cardano Ambassador, Catalyst Project Manager, DREP-WIMS:
- Co-founder of ABL Tech and Cardano Africa Live
- EBU-certified Plutus Pioneer (Plutus/Haskell)
- Cohort #1 Plutus Pioneer Developer
- Catalyst Community Reviewer & Funded Projects Manager
-
DRep for WIMS-Cardano (ID:
drep1yguj8zu48n99pv70yl6ckzt9hdgjy8yjnlqs2uyzcpafnjgu4vkul) - Intersect Developer Advocate
- Intersect Committe Member 2025-2026
- Cardano Marketer,Promoter and blogger
- Cardano Open Source Contributor
- Cardano communities and events organizer and builder
- Cardano Ambassador for South Africa
Official links:
- Stablecoins Dex
- Coxygen Global Universities
- WIMS Cardano Global
- Cardano Africa Live
- WIMS Cardano Videos
- Cardano Smart Contract Videos
- Fullstack IT Consulting
Social links: