Repository navigation
Ntokazi Protocol CUSP
Zero-Fee User Experience, Cross-Chain and Cross-Border Universal Stablecoin Settlement with Programmable Compliance, Privacy, Decentralized Attestation, Selective Disclosure, AI-Assisted Cybersecurity and Decentralized Peer-to-Peer Bridging
Project Name: Ntokazi Protocol
Protocol Name: Coxygen Universal Settlement Protocol
Abbreviation: CUSP
Primary Settlement Architecture: Cardano eUTXO
Privacy and Selective Disclosure Layer: Midnight
Attestation Architecture: CIP-0170, KERI and ACDC
Programmable Asset Architecture: Cardano programmable-token standards including the work incorporated into candidate CIP-0113
Initial Networks: Cardano, Midnight, Ethereum, BNB Chain and Solana
Subsequent Networks: Bitcoin, XRP Ledger, Dogecoin and other approved networks
Primary Application Areas: Cross-border payments, regulated stablecoins, merchant settlement, remittances, treasury settlement, institutional payments, decentralized foreign exchange and privacy-preserving financial infrastructure
Ntokazi Protocol is a proposed universal digital settlement infrastructure designed to allow individuals, businesses, financial institutions, payment providers and governments to transfer regulated stable value across countries and blockchain networks without requiring every participant to understand blockchain technology.
The protocol is called the Coxygen Universal Settlement Protocol, abbreviated CUSP. The public-facing project and ecosystem will use the name Ntokazi Protocol.
Ntokazi Protocol is not intended to be another cryptocurrency exchange, ordinary blockchain bridge or speculative token project. It is intended to become an interoperable settlement network that connects stablecoins, blockchain networks, identity systems, regulated financial institutions, liquidity providers and privacy-preserving compliance infrastructure.
The system will use Cardano's extended unspent transaction output architecture as an important settlement and programmable-asset layer. Midnight will provide programmable privacy, zero-knowledge proofs and selective disclosure. Decentralized KERI identities and ACDC credentials will provide verifiable attestations. Independent bridge solvers and liquidity providers will facilitate cross-chain and cross-border transfers. A dedicated compliance policy engine will determine the rules that apply to a particular transaction without unnecessarily publishing personal information.
CIP-0170 currently defines a proposed mechanism for embedding KERI-backed identifiers into Cardano transaction metadata. It is intended to provide persistent and cryptographically verifiable identity binding for organizations and accountable entities. However CIP-0170 explicitly notes that credential validation currently has to take place off-chain through indexers or other verification infrastructure. Ntokazi Protocol will therefore provide a dedicated attestation verification service rather than assuming Cardano smart contracts can directly validate KERI credential chains.
Midnight will provide another critical component. Midnight's current architecture supports public state, private local state, zero-knowledge proofs and selective disclosure. This means that a user can prove a required fact without publishing all of the information underlying that proof. For example a user could prove that a valid compliance credential exists without publishing a passport number, residential address or complete transaction history.
The central design principle of Ntokazi Protocol is therefore:
Reveal what a transaction needs to prove, not everything that is known about the person making the transaction.
Ntokazi Protocol will simultaneously seek to provide compliance, privacy, interoperability, security and usability.
The long-term vision for Ntokazi Protocol is to establish a universal settlement protocol through which a person in one country can send value to a person or business in another country without having to understand correspondent banking, blockchain networks, gas tokens, bridges or foreign-exchange infrastructure.
A merchant should be able to request South African rand while a customer pays using a dollar stablecoin.
A worker living abroad should be able to send money home without first understanding what blockchain the receiving wallet uses.
A regulated financial institution should be able to determine whether a transaction meets its compliance policy without having to publish all customer identity information to a public blockchain.
A company should be able to settle invoices internationally while proving the identities and authority of the organizations involved.
A blockchain user should be able to move stable value between Cardano, Ethereum, Solana and other supported networks without depositing funds into a single centralized bridge wallet controlled by Ntokazi Protocol.
The protocol should ultimately make blockchain infrastructure behave more like an invisible settlement layer.
The mission of Ntokazi Protocol is to create a secure, privacy-preserving and interoperable settlement network that makes digital stable value usable across blockchain networks and national borders while respecting legitimate regulatory requirements and individual privacy.
The system will specifically attempt to solve five problems at the same time.
First, it will address blockchain fragmentation. Digital assets currently exist on networks that use different addresses, transaction formats, wallet systems and execution environments.
Second, it will address cross-border settlement complexity. International payments frequently involve multiple financial intermediaries, foreign-exchange providers and reconciliation processes.
Third, it will address the conflict between financial privacy and regulatory compliance. Traditional compliance systems often collect and disclose significantly more personal information than is required to establish whether a particular transaction is permissible.
Fourth, it will address bridge security. Many bridges concentrate custody or signing authority in a limited number of systems that become valuable attack targets.
Fifth, it will address poor blockchain usability. Users should not need to acquire a different native gas token simply to make an ordinary payment.
CUSP is the underlying settlement protocol of Ntokazi Protocol.
It will coordinate six principal functions:
-
It will represent and settle stable value.
-
It will determine whether a requested transaction satisfies the applicable policy.
-
It will verify cryptographic credentials and attestations.
-
It will produce or verify privacy-preserving proofs.
-
It will identify an appropriate cross-chain or cross-border liquidity route.
-
It will verify that the intended settlement actually occurred before completing the corresponding transaction.
The system will not depend upon one database claiming that a transaction happened on another blockchain.
Every supported blockchain will have an independent verification adapter capable of retrieving transactions, determining finality and validating relevant transaction properties.
Today's financial and blockchain infrastructure contains several disconnected systems.
Traditional cross-border payments are improving but they remain an enormous market. McKinsey estimated that approximately $190 trillion of payment value crossed international borders during 2025 and generated more than $290 billion in industry revenue.
Remittances are also substantial. The World Bank reports that global remittance flows reached approximately $856 billion in 2024, of which approximately $653 billion went to low-income and middle-income countries.
Stablecoins have simultaneously developed into a major settlement market. Visa reported that stablecoin supply grew from approximately $186 billion in December 2024 to approximately $274 billion in December 2025. Visa also reported that adjusted stablecoin transaction volume was on track to exceed $10 trillion during 2025 after excluding activity such as high-frequency trading wallets, bots and smart contract addresses.
Visa's own settlement infrastructure demonstrates increasing institutional interest in multi-chain settlement. In April 2026 Visa said its stablecoin settlement pilot had reached an approximately $7 billion annualized settlement run rate and had expanded support across additional blockchain networks.
These figures do not mean Ntokazi Protocol can automatically capture a particular percentage of these markets. They demonstrate that Ntokazi Protocol would be entering established markets in which very large amounts of value already move.
Individuals will benefit from a payment interface that hides blockchain complexity.
A person should be able to select the recipient, currency, amount and payment method. Ntokazi Protocol will determine the blockchain network, appropriate stablecoin representation, compliance requirements and settlement route.
This could be particularly useful to migrant workers, freelancers, international students, families receiving remittances and individuals purchasing goods internationally.
Merchants will be able to request settlement in the currency and network they prefer.
A merchant may request South African rand while a customer owns USDC on Ethereum. Another merchant may request a euro-denominated stablecoin on Cardano while a customer holds another supported stable asset on Solana.
Ntokazi Protocol will calculate whether an acceptable route exists and present the customer with the complete amount before execution.
Small businesses frequently encounter relatively high foreign-exchange costs, banking delays, reconciliation work and fragmented payment infrastructure when doing international business.
Ntokazi Protocol could provide these businesses with programmable invoices, blockchain settlement references, accounting integrations, stablecoin treasury management and transparent foreign-exchange execution.
Financial institutions could integrate CUSP through APIs instead of having to operate application interfaces intended for retail users.
Banks could use the network as a settlement rail while retaining their own customer relationships, regulatory obligations and banking infrastructure.
Institutional users could use privacy-preserving proofs to verify that counterparties satisfy particular requirements without automatically obtaining every underlying customer record.
Payment companies could use Ntokazi Protocol as an infrastructure layer.
Instead of constructing independent integrations for Cardano, Midnight, Ethereum, Solana and other networks they could integrate a single CUSP interface.
Stablecoin issuers could use CUSP for multi-chain distribution, programmable transfer policy, attestation and cross-border liquidity.
Ntokazi Protocol should not require every stablecoin to use exactly the same compliance rules. Each issuer should be able to define an appropriate policy profile.
Governments could use controlled deployments for grants, regulated disbursements, development programmes and other payment systems where auditability is important.
Such deployments should not automatically reveal citizens' personal information on public blockchains.
Aid organizations could distribute digital value using credentials that prove eligibility while reducing unnecessary disclosure of beneficiary information.
The organization could prove that an eligible beneficiary received an allocation without publishing all personal details in a globally searchable public ledger.
Ntokazi Protocol will be designed around the following principles.
Blockchain complexity belongs inside the protocol rather than inside the payment experience.
Privacy cannot be added later by encrypting a centralized database containing excessive personal information.
Different jurisdictions, issuers and transaction classes require different rules. Policy must therefore be configurable and versioned.
An emergency freeze temporarily preventing movement is fundamentally different from permanently transferring assets.
AI may identify anomalies and recommend actions but it must not independently seize assets.
Signing infrastructure must operate independently from websites and public APIs.
An API response claiming that a deposit occurred cannot by itself authorize issuance or release of assets.
Minting, emergency recovery, bridge treasury withdrawals and regulated seizure actions must use threshold authorization.
Minting, burning, freezing, unfreezing, seizures, policy changes and emergency actions require immutable audit records.
The system will consist of the following logical layers.
USER APPLICATIONS
Wallets, merchant applications, mobile applications,
bank interfaces, checkout systems and institutional APIs
│
▼
CUSP API GATEWAY
│
▼
TRANSACTION INTENT ENGINE
│
┌──────────┼──────────┐
▼ ▼ ▼
POLICY ENGINE RISK ENGINE ROUTE ENGINE
│ │ │
└──────────┼──────────┘
▼
IDENTITY AND ATTESTATION LAYER
KERI, ACDC, CIP-0170, GLEIF and approved credentials
│
▼
MIDNIGHT PRIVACY LAYER
Private state, zero-knowledge proofs and selective disclosure
│
▼
CROSS-CHAIN SETTLEMENT ENGINE
┌──────────────┼───────────────┐
▼ ▼ ▼
Cardano Ethereum Solana
│ │ │
Midnight BNB Chain Additional
Networks
│
▼
FINALITY AND RECONCILIATION ENGINE
│
▼
AUDIT, RESERVE AND ACCOUNTING LAYER
Ntokazi Protocol should initially support existing approved stablecoins rather than immediately attempting to become an unlicensed stablecoin issuer.
A later stage may introduce native Ntokazi Protocol settlement assets such as:
iUSD
iEUR
iZAR
iGBP
Each asset would require a clearly identified regulated issuer or legally compliant issuance structure.
A fiat-backed stablecoin must not be represented as fully backed merely because a smart contract controls minting. Its reserve arrangement, custodian relationships, redemption rights, accounting procedures and applicable legal framework must independently support the claim.
A canonical asset may have representations on several networks.
For example:
iUSD.Cardano
iUSD.Midnight
iUSD.Ethereum
iUSD.Solana
iUSD.BNB
The settlement system must enforce the invariant that destination-chain issuance cannot exceed the valid locked or burned amount represented by the corresponding source-chain transaction.
Conceptually:
Destination Mint
≤
Verified Source Lock or Burn
Bridge accounting must maintain this invariant continuously rather than only during periodic audits.
Cardano will be an important settlement and policy layer because its eUTXO architecture allows transaction validity to be expressed using explicit transaction inputs and outputs.
The smart-contract implementation language will be Plutus Haskell.
Plutus Haskell is specifically designed for Cardano validators and compiles to Untyped Plutus Core.
The Cardano component will contain validators for:
- stablecoin minting and burning
- programmable transfer policy
- reserve locks
- cross-chain settlement escrows
- solver bonds
- dispute resolution
- threshold approvals
- emergency pause authority
- governed freeze operations
- governed seizure operations
- treasury operations
- protocol configuration
- settlement receipts
These components will be separated instead of constructing one extremely large validator.
Cardano's programmable-token work is relevant to regulated stablecoin use cases. CIP-0143 was incorporated into the candidate CIP-0113 work and describes mechanisms intended to make programmable token-like assets interoperable with existing applications.
Because this architecture remains under standards development Ntokazi Protocol should maintain an abstraction around programmable assets.
The stablecoin engine must therefore support:
Transfer
Mint
Burn
Freeze
Unfreeze
Seize
Recover
Pause
Unpause
Each operation must have an independent authorization policy.
A freeze must temporarily restrict movement without automatically transferring ownership.
Supported states should include:
ACTIVE
SOFT_FREEZE
ADDRESS_FREEZE
ASSET_FREEZE
BRIDGE_FREEZE
JURISDICTION_RESTRICTION
GLOBAL_EMERGENCY_PAUSE
A bridge freeze should disable cross-chain mint or release operations without unnecessarily stopping ordinary transfers on the underlying blockchain.
An asset freeze should only be available where the asset's legal structure and technical design explicitly permit such action.
Seizure must require a stronger authorization process than freezing.
A typical workflow should be:
Investigation
│
▼
Evidence reference created
│
▼
Temporary freeze
│
▼
Required legal or contractual authority verified
│
▼
Independent attestations collected
│
▼
Threshold authorization
│
▼
Policy timelock where applicable
│
▼
Seizure execution
│
▼
Recovery or regulated escrow
│
▼
Permanent audit record
No administrator should possess a single unrestricted seize() capability.
Ntokazi Protocol will establish an attestation network consisting of independent entities capable of signing claims.
Possible attestor classes include regulated compliance providers, licensed financial institutions, independent auditors, legal authorities where applicable, protocol guardians, identity issuers and approved institutional validators.
An attestation does not itself make a statement legally valid.
Instead it provides cryptographic evidence that a specified attestor made a particular assertion.
CIP-0170 will be used to bind accountable entities and selected actions to persistent KERI identifiers.
CIP-0170 embeds KERI Autonomic Identifiers into Cardano transaction metadata. Those identities can be connected to credential chains such as vLEIs and organizational trust frameworks.
The Ntokazi Protocol attestation service will therefore maintain:
AID
KERI Key Event Log
ACDC credentials
Credential schemas
Issuer identity
Revocation state
Authorization scope
Validity period
Trust framework
The system will not interpret possession of a KERI identity as proof that an entity is trustworthy.
Trust comes from the credential chain and the policy governing the transaction.
The principal open-source implementation proposed for the KERI layer is KERIpy.
KERIpy provides Python implementation libraries for KERI and supports KERI, ACDC and CESR technologies.
The identity infrastructure should include:
KERI controllers
KERI witnesses
KERI watchers
ACDC credential registries
Credential schema registry
Credential revocation monitoring
CIP-0170 transaction indexer
Organizations may optionally be linked to Legal Entity Identifiers.
The GLEIF API provides access to LEI data including legal entity records, issuer data and organizational ownership relationships.
This means an institution could potentially prove:
This organization has LEI X.
The LEI is active.
This KERI identifier is authorized under the applicable credential chain.
This signer is authorized to act for the organization.
without treating an ordinary blockchain wallet address as a complete legal identity.
Midnight will provide privacy-preserving smart contracts for private credentials and selective disclosure.
Midnight currently supports a dual-state architecture in which public information can exist on-chain while private information remains local. Zero-knowledge proofs allow the network to verify claims about private information without receiving the raw information itself.
The Ntokazi Protocol privacy layer should support proofs such as:
User holds an approved credential.
Credential has not expired.
Credential has not been revoked.
Required identity checks were completed.
User satisfies the transaction policy.
Organization possesses valid legal-entity credentials.
Transaction amount is within an authorized threshold.
Required sanctions screening was completed.
Required jurisdictional conditions were satisfied.
The blockchain does not need to receive the person's full identity record merely to verify these statements.
Privacy contracts will be written in Compact.
Midnight describes Compact as a statically typed smart-contract language integrated with a TypeScript-oriented development workflow. Private information can enter through witness functions and client-side proofs can be created without sending the underlying secrets to the public network.
The initial Compact contracts should include:
CredentialProof.compact
EligibilityProof.compact
JurisdictionProof.compact
TransactionLimitProof.compact
InstitutionProof.compact
ComplianceProof.compact
DisclosureAuthorization.compact
PrivatePaymentReference.compact
Ntokazi Protocol must distinguish between proof and disclosure.
A zero-knowledge proof may establish:
The customer is eligible for this transaction.
Selective disclosure may establish:
The customer's jurisdiction is South Africa.
Full legal disclosure may establish:
The customer's legally verified identity is X.
Those are different levels of information.
The policy engine should therefore define explicit disclosure scopes.
Public records may contain transaction identifiers, asset references, settlement state, proof identifiers and necessary blockchain data.
Counterparties may receive invoice references, business credentials and other information necessary to complete their transaction.
Approved compliance parties may receive precisely defined regulatory attributes where legitimately required.
More extensive disclosure should require a separate authorized workflow and must be logged.
Midnight specifically describes selective disclosure as a means of proving required facts while keeping other information private.
Compliance requirements must not be scattered across PHP files, smart contracts and database triggers.
A dedicated policy engine will define the rule set.
Example policy:
Policy ID: ZA-EU-B2B-USD-001
Source jurisdiction:
South Africa
Destination jurisdiction:
European Union
Transaction class:
Business payment
Asset:
Approved USD stablecoin
Maximum transaction:
Policy-defined
Sender credential:
Required
Receiver business credential:
Required
Sanctions screening:
Required
Selective disclosure:
Required
Enhanced due diligence:
Triggered by configurable conditions
Every executed transaction should record the policy version used.
The recommended initial sanctions and politically exposed person screening data source is OpenSanctions or an appropriately licensed equivalent.
OpenSanctions provides a matching API specifically intended for entity screening against sanctions, politically exposed person and other risk datasets. Its /match endpoint accepts structured attributes and returns candidate matches rather than relying only on exact name equality.
Commercial operation requires the appropriate OpenSanctions licensing arrangement.
Screening results must never automatically become seizure orders.
A potential match should trigger the applicable review process.
Ntokazi Protocol should not use a model where all customer bridge assets enter one Coxygen-controlled hot wallet.
Instead Ntokazi Protocol will use an intent and solver architecture.
A user creates an intent such as:
I will provide:
1,000 units of approved stablecoin on Cardano.
I require:
The corresponding approved stablecoin amount on Ethereum.
Maximum total cost:
Defined by user.
Maximum slippage:
Defined by user.
Settlement deadline:
Defined by user.
Independent solvers compete to fulfil the request.
A solver is an independent liquidity provider that maintains capital on supported blockchains.
A solver does not need permanent custody of the user's assets.
Its responsibilities are to:
- monitor open intents
- calculate whether it can execute a route
- submit a quote
- lock or provide destination liquidity
- submit settlement evidence
- complete the source settlement
- maintain the required collateral where the protocol requires it
Solvers should earn fees from spreads or explicit protocol compensation.
Solvers handling asynchronous routes should post collateral.
The collateral mechanism must be calibrated through economic modelling rather than selecting an arbitrary value.
A possible rule is:
Required Bond
=
Base Bond
and
Risk-Adjusted Exposure Requirement
The risk model can consider outstanding exposure, settlement duration, supported chain, historical behaviour, liquidity and route risk.
Slashing must only occur according to deterministic and auditable conditions.
Each blockchain will use a dedicated adapter implementing a common interface.
ChainAdapter
getNetworkState()
getBalance()
getTransaction()
verifyTransaction()
getConfirmations()
getFinality()
estimateFee()
buildLock()
verifyLock()
buildClaim()
verifyClaim()
buildRefund()
verifyRefund()
submitTransaction()
subscribeBlocks()
subscribeTransactions()
This prevents the route engine from containing hard-coded blockchain-specific logic.
The Cardano adapter should use self-hosted infrastructure for production where practical.
cardano-node will provide direct blockchain participation.
Ogmios will provide JSON-RPC and WebSocket access to cardano-node. Ogmios is specifically designed as a lightweight interface between applications and a local Cardano node.
Kupo will provide lightweight chain indexing and efficient UTXO lookup. Kupo indexes matching Cardano transaction outputs, datums and scripts for fast querying.
Blockfrost may be used as a secondary infrastructure provider, development provider and independent verification source. The official JavaScript SDK is available as @blockfrost/blockfrost-js.
Mesh SDK may be used for Cardano transaction construction and application integrations where appropriate.
CIP-0030 will provide browser wallet interoperability. CIP-0030 is an active Cardano wallet web-bridge standard and is implemented by wallets including Lace, Eternl, Flint, GeroWallet, Nami, NuFi and Yoroi.
Ethereum and BNB Chain use EVM-compatible infrastructure.
The recommended application library is viem because it provides strongly typed TypeScript interfaces to Ethereum JSON-RPC, contracts, ABI handling, typed data and multiple testing environments.
Smart contracts should be built with:
Solidity
Foundry
OpenZeppelin Contracts
Slither
Echidna
Foundry should be used for compilation, testing, fuzzing and deployment scripting.
OpenZeppelin should be used for established contract components instead of reimplementing standard cryptographic and access-control patterns.
Slither should be used for static analysis.
Echidna should be used for property-based smart contract fuzzing.
New Solana integration work should follow the current Solana SDK direction rather than building new infrastructure around obsolete interfaces.
The existing @solana/web3.js repository describes the 1.x branch as the maintenance branch and points developers toward newer SDK architecture based around @solana/kit.
The production adapter should therefore use the stable supported Solana SDK available at implementation time.
Token functionality will use the relevant Solana token program and associated official libraries.
Bitcoin support should be introduced after account-based and Cardano routes are stable.
The adapter can use:
Bitcoin Core
Bitcoin JSON-RPC
bitcoinjs-lib for appropriate application utilities
PSBT
HTLC or script-based settlement structures where suitable
bitcoinjs-lib has extensive test coverage and specifically recommends using tagged stable releases for production rather than the development branch.
Private-key generation and custody should not be delegated casually to browser libraries.
The application layer will use Midnight.js.
Midnight.js provides TypeScript libraries for transactions, wallet interaction, contract state, private state and zero-knowledge proof workflows.
Components will include:
Midnight.js
Compact compiler
Midnight wallet SDK
Midnight indexer
proof server
private state provider
ZK configuration provider
Where client-side proof generation is available and operationally feasible it should be preferred for sensitive personal information.
Cross-border settlement requires defensible pricing.
The system must never depend upon one unverified browser API for foreign-exchange or digital-asset pricing.
The primary decentralized market-data integration proposed is Pyth Network.
Pyth provides real-time market data from more than 120 first-party providers and supports price delivery across more than 100 blockchains.
Pyth provides REST, WebSocket and historical-data interfaces.
Production pricing should support at least two independent data sources for critical markets.
"Zero fees" must be defined accurately.
Blockchains consume resources and the infrastructure operating Ntokazi Protocol has real costs.
Therefore Ntokazi Protocol should promise:
Zero network fees charged directly to eligible end users on supported transaction classes.
This can be accomplished through sponsored transactions, institutional subscriptions, merchant fees, solver spreads, reserve economics and protocol treasury subsidies.
Midnight's architecture also separates NIGHT from DUST. Midnight describes DUST as the operational resource used to execute transactions while holding NIGHT generates DUST.
Zero user fees must therefore mean that the user is not required to acquire network gas tokens merely to perform an ordinary supported payment.
The protocol will expose a versioned API beginning with:
/api/v1/
POST /identity/register
GET /identity/{id}
POST /identity/credential
POST /identity/verify
GET /identity/credential/{id}
POST /identity/revoke
POST /attestations
GET /attestations/{id}
POST /attestations/verify
GET /attestors
GET /attestors/{id}
POST /compliance/evaluate
POST /compliance/screen
GET /policies
GET /policies/{id}
POST /proofs/request
POST /proofs/verify
GET /assets
GET /assets/{asset}
POST /mint/request
POST /burn/request
POST /freeze/request
POST /unfreeze/request
POST /seizure/request
GET /reserves/{asset}
POST /intents
GET /intents/{id}
GET /intents/{id}/quotes
POST /quotes
POST /quotes/{id}/accept
POST /settlements
GET /settlements/{id}
POST /settlements/{id}/proof
GET /rates
GET /rates/{pair}
GET /routes
POST /routes/quote
POST /solvers/register
GET /solvers/{id}
GET /solvers/{id}/bond
GET /solvers/{id}/performance
POST /solvers/{id}/quote
POST /risk/evaluate
GET /risk/transactions/{id}
POST /risk/incidents
GET /risk/incidents/{id}
GET /governance/proposals
POST /governance/proposals
POST /governance/vote
GET /governance/configuration
The first production architecture should anticipate the following external integrations.
| Service | Purpose |
|---|---|
| Cardano node | Direct Cardano blockchain access |
| Ogmios | Cardano node JSON-RPC and WebSocket access |
| Kupo | Cardano UTXO indexing |
| Blockfrost | Secondary Cardano API and independent verification |
| Midnight indexer | Midnight public state |
| Midnight proof infrastructure | ZK proof generation and verification |
| Ethereum JSON-RPC | Ethereum blockchain access |
| BNB Chain JSON-RPC | BNB Chain access |
| Solana JSON-RPC | Solana access |
| Bitcoin Core JSON-RPC | Bitcoin access |
| Pyth | Market prices and FX reference data |
| OpenSanctions | Sanctions and PEP screening |
| GLEIF | Legal Entity Identifier verification |
| KERI services | KEL and ACDC verification |
| Licensed KYC provider | Customer identity verification where legally required |
| Banking partner API | Fiat deposits and withdrawals |
| Payment provider API | Card and bank payment processing |
| Accounting integration | Merchant and treasury reconciliation |
| Notification provider | Transaction notifications |
| HSM or MPC provider | Institutional signing infrastructure where appropriate |
Commercial providers must remain replaceable so that no central API provider becomes a permanent protocol dependency.
The recommended core stack is:
cardano-node
Plutus Haskell
Ogmios
Kupo
Mesh SDK
Blockfrost SDK
CIP-0030 wallet integration
Compact
Midnight.js
Midnight wallet SDK
Midnight indexer
Midnight proof infrastructure
KERIpy
ACDC
CESR
KERI witnesses
KERI watchers
Solidity
viem
Foundry
OpenZeppelin Contracts
Slither
Echidna
@solana/kit or current stable official successor
Solana validator tooling
official token-program libraries
Bitcoin Core
bitcoinjs-lib
PSBT tooling
Node.js
TypeScript
Python
PostgreSQL
Redis
NATS or Apache Kafka
OpenAPI
JSON Schema
Docker
Kubernetes for production orchestration
HashiCorp Vault
OpenBao as an open-source alternative
age for selected encrypted operational files
SOPS
Falco
Trivy
Semgrep
OWASP ZAP
Suricata where network deployment requires it
OpenTelemetry
Prometheus
Grafana
Loki
Tempo
Git
GitHub or equivalent repository infrastructure
unit testing
integration testing
property testing
fuzz testing
dependency scanning
container scanning
signed builds
software bills of materials
Blockchain state must never be replaced by an SQL database.
PostgreSQL will contain indexes, application records, workflow state and metadata.
Suggested primary tables include:
users
organizations
wallets
wallet_bindings
chains
assets
asset_representations
credentials
credential_schemas
credential_issuers
keri_aids
keri_events
attestors
attestations
policies
policy_versions
proof_requests
proof_results
transaction_intents
quotes
solvers
solver_bonds
settlements
chain_transactions
bridge_locks
bridge_claims
bridge_refunds
reserve_accounts
reserve_snapshots
risk_events
risk_scores
compliance_cases
freeze_requests
seizure_requests
approvals
governance_proposals
audit_events
notifications
api_clients
api_permissions
Personally identifiable information should not be placed in these tables merely because the schema permits it.
Sensitive information should be stored only where necessary and should be encrypted independently from general application data.
Every bridge settlement should move through deterministic states.
CREATED
POLICY_CHECK
AWAITING_PROOF
ELIGIBLE
QUOTING
QUOTE_SELECTED
SOURCE_LOCK_PENDING
SOURCE_LOCK_CONFIRMED
DESTINATION_SETTLEMENT_PENDING
DESTINATION_SETTLED
SOURCE_RELEASE_PENDING
COMPLETED
Failure states should include:
EXPIRED
CANCELLED
POLICY_REJECTED
PROOF_FAILED
SOURCE_FAILED
DESTINATION_FAILED
REFUND_PENDING
REFUNDED
DISPUTED
QUARANTINED
The database must not mark a transaction COMPLETED merely because an HTTP request returned status 200.
Each blockchain has different finality characteristics.
The settlement system will maintain chain-specific finality rules.
The finality engine should answer:
Did the transaction exist?
Was the expected contract or address used?
Was the correct asset transferred?
Was the required amount transferred?
Was the expected intent identifier present?
Has sufficient finality been achieved?
Has the transaction been replaced or invalidated?
Has a chain reorganization affected it?
Only then may the corresponding settlement progress.
The routing engine should support stablecoin and fiat liquidity corridors.
Example:
Customer holds USD stablecoin on Ethereum
│
▼
Ntokazi Protocol intent
│
▼
Compliant solver auction
│
▼
USD to ZAR liquidity route
│
▼
Approved South African settlement provider
│
▼
Merchant receives ZAR
Routes should compete on:
final amount
exchange rate
slippage
settlement speed
counterparty risk
available liquidity
blockchain cost
policy eligibility
route reliability
The final user interface should show the amount the recipient is expected to receive before the transaction is accepted.
AI will support anomaly detection and investigation.
It will not possess mint, freeze or seizure keys.
The AI system can analyse:
transaction velocity
unexpected mint behaviour
bridge reserve divergence
unusual solver behaviour
failed proof patterns
credential anomalies
signer anomalies
large withdrawal patterns
unusual destination changes
RPC inconsistencies
unexpected smart-contract events
liquidity deviations
chain reorganization behaviour
oracle divergence
The AI engine should create:
risk event
reason codes
supporting evidence
confidence
recommended response
The recommendation may be reviewed by deterministic policy systems or authorized personnel.
AI must supplement rather than replace deterministic safeguards.
The protocol should enforce hard invariants such as:
Minted supply must not exceed authorised backing.
A destination bridge mint requires verified source settlement.
A source release requires verified destination settlement where the route requires it.
A solver cannot exceed its approved exposure.
A paused route cannot create new settlements.
An expired intent cannot be executed.
A revoked signer cannot approve new actions.
A single ordinary administrator cannot seize funds.
These rules are significantly more important than a machine-learning risk score.
Production signing must be separated from the public application.
Internet
│
▼
Public API
│
▼
Authenticated internal request
│
▼
Policy verification
│
▼
Signing coordinator
│
├──── HSM or MPC signer A
├──── HSM or MPC signer B
├──── HSM or MPC signer C
├──── Independent signer D
└──── Independent signer E
The website must not contain the keys capable of minting stablecoins, moving bridge reserves or authorizing seizure.
Sensitive actions should require threshold approval.
Example production configuration:
Routine operational signing:
2 of 3
Treasury movement:
3 of 5
Emergency protocol upgrade:
4 of 7
Seizure authorization:
Policy-dependent threshold
Root administration:
Offline recovery threshold
These values are initial design examples rather than immutable final settings.
They must be selected after threat modelling and governance review.
The protocol should support narrowly scoped emergency controls.
These include:
pause one bridge route
pause one asset
pause new intents
pause one solver
pause destination minting
disable compromised credential issuer
disable compromised attestor
rotate compromised signer
increase confirmation requirements
disable an oracle source
switch RPC provider
A global pause should be the last resort.
Where Ntokazi Protocol supports backed stablecoins it should provide reserve transparency.
Reserve data may include:
on-chain supply
custodial reserve references
attested reserve reports
redemption obligations
locked bridge balances
minted cross-chain representations
burned supply
pending bridge liabilities
Proof-of-reserve mechanisms must not be represented as proof-of-solvency unless liabilities are appropriately included.
Every high-value operation must create an audit event.
An audit record should answer:
What happened?
Who requested it?
Which identity or credential authorized it?
Which policy version applied?
Which system executed it?
When did it happen?
What blockchain transaction resulted?
Was it successful?
Were there additional approvals?
Audit logs must be tamper evident.
Ntokazi Protocol will eventually require protocol governance.
Governance should be divided into powers rather than giving one group total authority.
Suggested governance bodies include:
The Technical Council manages protocol releases and technical emergency procedures.
The Security Council handles emergency cybersecurity actions.
The Compliance Council manages policy frameworks without controlling software deployment independently.
The Attestor Registry determines which credential issuers or attestors are recognized for specific purposes.
Community governance may control selected protocol parameters and ecosystem funding.
No governance structure should allow a simple token vote to bypass lawful asset-control processes.
A zero-fee user experience does not mean Ntokazi Protocol has no revenue.
Potential revenue sources include:
Banks, fintech companies, payment companies and large merchants may pay for API access and service-level commitments.
Merchants may pay a small settlement or currency-conversion charge.
Liquidity providers may quote a transparent spread and share protocol revenue.
Issuers may pay for compliance, distribution and multi-chain infrastructure.
Institutions may pay for privacy-preserving credential and settlement infrastructure.
A small protocol charge may be taken from successful solver settlements.
Banks and financial institutions may deploy branded versions of the payment interface.
Enterprise users may subscribe to policy management, credential verification and audit products.
The addressable opportunity should be understood as several overlapping markets rather than one number.
Approximately $190 trillion crossed international borders in 2025 according to McKinsey. The associated payment industry generated more than $290 billion in revenues.
The World Bank estimated $856 billion in global remittance flows in 2024.
Visa reported approximately $274 billion of stablecoin supply at the end of 2025 and adjusted annual transaction activity exceeding or approaching $10 trillion during that year.
Visa's continuing expansion of stablecoin settlement across multiple chains demonstrates that institutional payment companies increasingly expect multi-chain settlement capability.
Ntokazi Protocol should initially target narrow corridors rather than attempting to serve the entire global market immediately.
The most credible initial commercial strategy is:
one stablecoin
one sending corridor
one receiving corridor
two or three blockchain networks
one regulated fiat partner
one defined customer segment
Successful operation can then be expanded.
A practical first corridor would be:
South Africa to selected international business and remittance corridors.
The initial product could provide:
ZAR funding
USD stablecoin settlement
Cardano settlement
Ethereum settlement
Midnight privacy proofs
merchant settlement
business-to-business payments
The first regulated deployment should be determined only after jurisdiction-specific legal analysis.
Ntokazi Protocol combines technologies that normally exist separately. It integrates programmable Cardano assets, privacy-preserving Midnight contracts, decentralized identity, cross-chain liquidity and compliance policy into a unified settlement architecture.
Its eUTXO foundation provides an attractive environment for deterministic asset-control logic.
The KERI architecture provides persistent cryptographic identities with key rotation instead of treating wallet addresses as permanent organizational identities.
Midnight provides selective disclosure that can reduce unnecessary dissemination of sensitive personal data.
The solver model reduces dependence upon a single centralized bridge liquidity wallet.
The modular adapter architecture enables additional blockchains to be introduced without redesigning the entire protocol.
The complete system is technically complex.
It crosses several blockchain architectures, identity frameworks, privacy technologies and legal regimes.
Some relevant Cardano standards remain proposed or under development. CIP-0170 is currently proposed and its verification process remains off-chain.
Operating regulated stablecoins or fiat conversions requires substantially more than smart-contract development.
Liquidity fragmentation can prevent good pricing during early network adoption.
Zero-knowledge proof systems can introduce additional operational and engineering complexity.
Stablecoin settlement is moving toward institutional adoption.
Cross-border payments represent an enormous established market.
Privacy regulation creates demand for systems that can demonstrate compliance without unnecessarily exposing customer data.
Businesses increasingly operate across multiple blockchain networks.
Financial institutions can use Ntokazi Protocol as infrastructure without replacing their complete existing technology systems.
Africa provides important opportunities for cross-border payments, remittances and digital financial infrastructure.
Regulatory requirements can change.
Stablecoin regulation may require local licensing or restrict particular issuance models.
Bridge vulnerabilities are historically significant cybersecurity risks.
A critical flaw in a smart contract could create financial losses.
A compromised signer or attestor could submit fraudulent authorization.
Oracle manipulation could affect foreign-exchange settlement.
Large payment companies, banks and established stablecoin issuers may develop competing infrastructure.
Insufficient liquidity could make the service commercially unattractive even if the technology works correctly.
The project must be built in a deliberate order.
Duration: 8 to 12 weeks
Before production coding begins the project must define:
target jurisdiction
initial customer type
asset legal structure
stablecoin strategy
custody model
freeze authority
seizure authority
data-controller responsibilities
AML responsibilities
privacy obligations
bridge liability
solver obligations
reserve model
governance model
Deliverables include the legal architecture, regulatory matrix, threat model, protocol economics and initial technical specification.
Duration: 12 to 16 weeks
Build:
monorepo
API gateway
service identity
PostgreSQL schema
Redis
event bus
transaction intent engine
audit service
policy engine
configuration registry
chain adapter interface
observability
CI pipeline
No real funds should be handled.
Duration: 12 to 16 weeks
Build:
Plutus Haskell contracts
Cardano node infrastructure
Ogmios
Kupo
CIP-0030 wallet integration
asset registry
stablecoin test asset
lock contract
claim contract
refund contract
settlement receipts
Test on Cardano Preview and Preprod environments before production.
Duration: 10 to 14 weeks
Build:
KERIpy infrastructure
AID management
KEL verification
ACDC support
watchers
credential registry
CIP-0170 metadata generation
CIP-0170 indexing
GLEIF integration
attestor registry
revocation service
The team must explicitly test key rotation and credential revocation.
Duration: 12 to 16 weeks
Build:
Compact contracts
Midnight.js services
private state
credential proofs
eligibility proofs
selective disclosure
proof verification
policy integration
Sensitive user information should remain local wherever the intended proof architecture permits it.
Duration: 12 to 16 weeks
Start with:
Cardano
Ethereum
Build:
EVM contracts
viem adapter
intent matching
solver registration
solver collateral
quotes
cross-chain lock
destination settlement
source release
refund
finality monitoring
reconciliation
Do not add five networks before this route operates reliably.
Duration: 10 to 14 weeks
Build:
solver software
quote API
solver dashboard
bonding
route inventory
liquidity monitoring
performance scoring
settlement proofs
failure handling
slashing rules
Release the solver node as open source where security review permits.
Duration: 12 to 20 weeks
Integrate:
licensed KYC provider
OpenSanctions
GLEIF
banking partner
fiat deposit
fiat withdrawal
merchant settlement
case management
compliance reporting
This phase requires regulated partners and should not be treated as merely another programming milestone.
Duration: 16 to 24 weeks
Add in controlled sequence:
Solana
BNB Chain
Midnight asset routes
Bitcoin
XRP Ledger
other approved networks
Every network requires its own security assessment.
Duration: 12 to 16 weeks
Complete:
smart contract audit
bridge audit
infrastructure penetration testing
privacy review
key ceremony
disaster recovery exercise
economic attack simulation
oracle failure simulation
chain reorganization tests
attestor compromise tests
solver default tests
load testing
incident response exercise
Production limits should initially be deliberately low.
Duration: approximately 6 months after pilot readiness
Start with:
limited transaction size
limited daily volume
limited routes
limited stablecoins
whitelisted institutional solvers
high monitoring
manual escalation
Limits may be increased as evidence accumulates.
A responsible production roadmap should assume approximately 24 to 30 months for the first mature regulated deployment.
A technical testnet demonstration can exist much earlier.
Approximate programme sequence:
| Period | Major Goal |
|---|---|
| Months 1–3 | Legal architecture, economics and security design |
| Months 3–6 | CUSP core |
| Months 5–9 | Cardano settlement |
| Months 7–11 | Identity and KERI |
| Months 9–13 | Midnight privacy |
| Months 11–16 | Cardano to Ethereum bridge |
| Months 14–18 | Solver network |
| Months 15–21 | Compliance and fiat pilot |
| Months 18–24 | Additional networks |
| Months 21–26 | Independent security audits |
| Months 24–30 | Controlled production expansion |
Several workstreams can overlap after their architectural dependencies are stable.
A serious implementation requires a multidisciplinary team.
The core team should contain approximately:
1 programme director
1 protocol architect
2 Cardano/Plutus Haskell engineers
2 EVM engineers
1 Solana engineer
2 Midnight/zero-knowledge engineers
2 identity/KERI engineers
4 backend engineers
2 frontend/mobile engineers
2 DevOps/SRE engineers
2 security engineers
1 applied cryptography specialist
1 data/AI security engineer
2 QA engineers
1 product manager
1 UI/UX designer
2 compliance specialists
legal counsel
external smart-contract auditors
external penetration testers
Some positions can initially be fractional or contracted.
The following figures are planning estimates rather than quotations.
Estimated budget:
USD 150,000 to USD 300,000
This covers protocol architecture, legal research, economic modelling, security threat modelling and proof-of-concept design.
Estimated cumulative budget:
USD 750,000 to USD 1.5 million
This stage should deliver Cardano settlement, basic Midnight proofs, Ethereum connectivity, CUSP APIs and an early solver.
Estimated cumulative budget:
USD 2 million to USD 4 million
This includes expanded engineering, identity infrastructure, compliance integration, institutional security infrastructure, external audits and pilot operations.
Estimated cumulative development and launch budget:
USD 5 million to USD 9 million
This assumes a professional team, security audits, compliance implementation, infrastructure, legal work and controlled production deployment across multiple chains.
A larger regulated international programme can require:
USD 10 million to USD 20 million or more
The actual figure depends heavily on licensing, jurisdictions, banking partnerships, insurance and liquidity requirements.
Importantly the liquidity required by solvers and stablecoin reserves is not included in the software-development budget.
Capital requirements may therefore exceed engineering expenditure substantially.
A USD 7 million example programme could allocate approximately:
| Category | Approximate Allocation |
|---|---|
| Engineering | $2,800,000 |
| Security and independent audits | $700,000 |
| Legal and regulatory work | $700,000 |
| Cloud, nodes and infrastructure | $500,000 |
| Identity and compliance services | $350,000 |
| Product design and applications | $300,000 |
| QA and testing | $300,000 |
| Business development and institutional integrations | $250,000 |
| Contingency | $1,100,000 |
| Total | $7,000,000 |
Bridge liquidity and stablecoin reserves remain separate.
Testing must occur at several levels.
Every component must test its functions independently.
Smart-contract invariants must be expressed as properties.
Unexpected data and transaction combinations must be generated automatically.
Services must be tested against actual testnet nodes.
Tests must deliberately attempt:
double settlement
fake deposits
replayed deposits
expired intents
wrong asset
wrong recipient
insufficient finality
chain reorganization
solver disappearance
oracle manipulation
duplicate proofs
revoked credentials
compromised attestors
Production-like environments should intentionally lose RPC servers, databases, signers and message brokers.
The objective is to determine whether the protocol fails safely.
No unaudited contract should control economically significant production funds.
Each independent audit should cover:
authorization
value preservation
double satisfaction
replay prevention
state transitions
timelocks
emergency controls
upgrade mechanisms
minting invariants
bridge invariants
signature validation
integer handling
denial-of-service conditions
For Cardano specifically the team should follow established eUTXO design patterns and explicitly test against double-satisfaction issues. Plutus Haskell has security-oriented design patterns addressing these classes of eUTXO concerns.
Ntokazi Protocol should follow data minimization.
The system must ask:
Does this information need to exist in our infrastructure at all?
If not it should not be collected.
Where identity information must be retained it should be encrypted.
Encryption keys should be segregated from database servers.
Logs must never accidentally include passports, identity numbers, private wallet keys or credential secrets.
The following must never be stored in an ordinary application configuration file:
stablecoin mint authority keys
bridge treasury keys
root governance keys
KERI root secrets
HSM recovery material
MPC recovery shares
database root credentials
wallet seed phrases
Production systems should use HSM, MPC or comparably hardened signing controls appropriate to the value at risk.
The disaster recovery plan must cover:
database loss
node loss
data-centre loss
RPC provider outage
signer loss
attestor compromise
credential issuer compromise
blockchain halt
blockchain reorganization
oracle failure
banking partner outage
solver insolvency
stablecoin depeg
cybersecurity breach
Every category should have a documented recovery procedure.
The production deployment should contain independent security zones.
PUBLIC ZONE
Web applications
API gateways
APPLICATION ZONE
CUSP services
policy engine
route engine
DATA ZONE
PostgreSQL
Redis
analytics
BLOCKCHAIN ZONE
nodes
indexers
IDENTITY ZONE
KERI
credential services
SIGNING ZONE
HSM
MPC
guardian infrastructure
MONITORING ZONE
SIEM
Prometheus
Grafana
security analytics
Firewall rules should enforce the minimum communication required between zones.
The protocol should operate its own critical blockchain infrastructure where feasible.
Third-party providers such as Blockfrost are valuable for redundancy and development but one provider should not determine whether the entire protocol can operate.
For critical blockchain state the preferred model is:
self-hosted node
self-hosted indexer
independent commercial provider
second independent verification source
Disagreement between sources should trigger investigation rather than automatically selecting whichever response arrived first.
The MVP should not attempt to deliver universal finance.
A realistic MVP is:
Cardano
Ethereum
one existing approved stablecoin
CUSP intents
one solver
Cardano lock contract
Ethereum settlement contract
KERI attestor identities
basic CIP-0170 metadata
one Midnight compliance proof
transaction monitoring
refund mechanism
audit trail
testnet only
This is enough to prove the central architecture.
A regulated pilot adds:
one commercial corridor
licensed identity provider
sanctions screening
regulated payment partner
controlled solver group
production HSM or MPC
external contract audits
fiat funding
fiat redemption
transaction limits
incident procedures
customer support
compliance case management
Only after this works should the platform attempt broader geographic expansion.
Technical success should be measured using:
settlement success rate
median settlement time
failed route rate
refund success rate
bridge accounting mismatch
node uptime
proof generation time
proof verification time
false compliance alert rate
number of security incidents
reconciliation differences
solver availability
liquidity depth
Commercial success should include:
active customers
active merchants
active institutions
monthly settlement volume
cross-border volume
number of corridors
average transaction value
revenue per transaction
merchant retention
solver liquidity
customer acquisition cost
The protocol should never become a centralized website holding all customer funds.
It should never depend on one private key.
It should never call itself private while storing every customer's complete identity in application logs.
It should never call itself decentralized simply because transactions ultimately appear on a blockchain.
It should never claim zero cost when hidden spreads make transfers expensive.
It should never allow artificial intelligence to confiscate assets.
It should never treat a sanctions-screening similarity score as proof of identity.
It should never mint destination assets because a bridge API returned a successful HTTP status.
It should never introduce a new blockchain before the existing adapters can be reconciled reliably.
Ntokazi Protocol/
│
├── apps/
│ ├── wallet/
│ ├── merchant/
│ ├── compliance/
│ ├── solver-dashboard/
│ └── admin/
│
├── services/
│ ├── api-gateway/
│ ├── intent-engine/
│ ├── policy-engine/
│ ├── routing-engine/
│ ├── settlement-engine/
│ ├── finality-engine/
│ ├── attestation-engine/
│ ├── credential-engine/
│ ├── proof-engine/
│ ├── risk-engine/
│ ├── reserve-engine/
│ ├── reconciliation-engine/
│ ├── notification-engine/
│ └── audit-engine/
│
├── chains/
│ ├── cardano/
│ ├── midnight/
│ ├── ethereum/
│ ├── bnb/
│ ├── solana/
│ ├── bitcoin/
│ └── shared/
│
├── contracts/
│ ├── plutus-haskell/
│ ├── compact/
│ ├── solidity/
│ └── solana/
│
├── identity/
│ ├── keri/
│ ├── acdc/
│ ├── cip170/
│ └── schemas/
│
├── solver/
│ ├── node/
│ ├── strategies/
│ ├── inventory/
│ └── bonding/
│
├── infrastructure/
│ ├── docker/
│ ├── kubernetes/
│ ├── monitoring/
│ ├── vault/
│ └── terraform/
│
├── tests/
│ ├── unit/
│ ├── integration/
│ ├── adversarial/
│ ├── economic/
│ └── end-to-end/
│
└── docs/
├── architecture/
├── protocols/
├── APIs/
├── compliance/
├── security/
├── operations/
└── governance/
A sensible version sequence is:
v0.1
CUSP architecture and transaction intents
v0.2
Cardano settlement contracts
v0.3
KERI and CIP-0170 attestations
v0.4
Midnight privacy proofs
v0.5
Ethereum adapter
v0.6
Cardano to Ethereum solver prototype
v0.7
Solver bonding and reconciliation
v0.8
Compliance policy engine
v0.9
Fiat pilot integration
v1.0
Audited Cardano to Ethereum production pilot
v1.1
Solana
v1.2
BNB Chain
v1.3
Midnight private settlement routes
v1.4
Bitcoin
v1.5
Institutional APIs
v2.0
Multi-currency universal settlement network
Version 1.0 should not be declared because the web interface looks complete.
Version 1.0 should mean that:
A user can create a settlement intent.
The protocol can determine the required policy.
The user can produce the required compliance proof.
An approved solver can quote the transaction.
The user's source assets can be locked.
The protocol can independently verify the lock.
The solver can provide the destination settlement.
The protocol can independently verify the destination transaction.
The source contract can complete the corresponding settlement.
The accounting system can reconcile both chains.
A failed transaction can safely refund according to the protocol.
Every important action is auditable.
The contracts have received independent security review.
No web server possesses unrestricted custody keys.
Emergency procedures have been tested.
That is the milestone at which Ntokazi Protocol begins to become financial infrastructure rather than a blockchain demonstration.
Ntokazi Protocol should not compete by claiming to be another faster bridge.
Its strongest positioning is:
A universal privacy-preserving compliance and settlement protocol for stable value.
Its differentiated combination is:
Cardano eUTXO settlement
programmable stablecoin controls
Midnight programmable privacy
KERI decentralized identity
ACDC credentials
CIP-0170 accountable attestations
selective disclosure
cross-chain solver liquidity
cross-border FX
sponsored user transactions
decentralized attestation
governed recovery
AI-assisted cybersecurity
institutional APIs
No individual feature should be presented as the innovation.
The architecture integrating them is the primary value proposition.
The complete Ntokazi Protocol flow should eventually work as follows.
USER
│
│ "Send 1,000 USD value to this recipient."
▼
Ntokazi Protocol WALLET OR API
│
▼
TRANSACTION INTENT
│
├── source asset
├── destination
├── jurisdiction
├── requested currency
└── settlement preferences
│
▼
POLICY RESOLVER
│
▼
CREDENTIAL REQUIREMENTS
│
▼
KERI / ACDC / CIP-0170
│
▼
MIDNIGHT PRIVATE PROOF
│
▼
COMPLIANCE RESULT
│
▼
AI AND DETERMINISTIC RISK CONTROLS
│
▼
ROUTING ENGINE
│
▼
SOLVER AUCTION
│
▼
BEST ACCEPTABLE ROUTE
│
▼
SOURCE LOCK
│
▼
INDEPENDENT SOURCE VERIFICATION
│
▼
DESTINATION SETTLEMENT
│
▼
INDEPENDENT DESTINATION VERIFICATION
│
▼
SOURCE CLAIM OR BURN
│
▼
RECONCILIATION
│
▼
AUDIT RECORD
│
▼
RECIPIENT
The customer experiences a payment.
Underneath that payment Ntokazi Protocol coordinates cryptographic identity, programmable privacy, regulatory policy, decentralized liquidity, multiple blockchain networks and deterministic settlement verification.
That is the fundamental purpose of CUSP.
Ntokazi Protocol has the potential to become substantially more important than a cross-chain bridge.
A bridge answers the question:
How can an asset move from blockchain A to blockchain B?
Ntokazi Protocol attempts to answer a much larger question:
How can legitimate digital value move between people, businesses, financial institutions, currencies, countries and blockchain networks securely while maintaining privacy, auditability and compliance?
Cardano can provide a deterministic eUTXO settlement environment and programmable asset controls.
KERI, ACDC and CIP-0170 can provide cryptographically accountable identity and attestation infrastructure.
Midnight can provide private state, zero-knowledge proofs and selective disclosure. Midnight's current documentation explicitly positions these capabilities for situations in which correctness or compliance needs to be proven without revealing the underlying sensitive information.
A decentralized solver network can provide cross-chain and cross-border liquidity without requiring Ntokazi Protocol to become the custodian of every transaction.
The policy engine can provide compliance without embedding one country's regulatory assumptions permanently into the blockchain protocol.
Threshold signing and independent guardians can prevent a single administrator from controlling critical financial powers.
AI can improve cyber-defence without becoming the authority that controls customer money.
If these principles are maintained the result will not merely be a universal stablecoin.
Ntokazi Protocol can become an interoperable settlement fabric connecting regulated finance, decentralized finance, privacy-preserving identity and multiple blockchain ecosystems.
Its core promise can therefore be expressed simply:
One settlement protocol, many currencies, many blockchains, many jurisdictions, user-controlled privacy and verifiable trust.