There is a question that sits underneath every architectural decision in Zivana Protocol: what does trust infrastructure for the African informal economy actually need from its underlying stack?
Not what any blockchain offers in the abstract. Not what sounds good in a whitepaper. What this specific use case requires at the level of real infrastructure running under real conditions.
A market trader in Alaba International needs her reputation to travel across networks she did not originate in. A cooperative in Aba needs to issue credentials its members can present anywhere without calling the cooperative to verify. A savings group in Kano needs its members' economic contributions to be attestable by a third party that has never interacted with the group. A lender in Accra needs to evaluate a borrower whose entire economic history exists in a context the lender has no relationship with.
These requirements are not abstract. They translate directly into technical primitives: identity portability, privacy-preserving proof, verifiable attestation of real-world economic events, intelligent contextualization of economic signals, and composability across all of the above. The question Phase 0 was designed to answer is whether the Cardano and Midnight stack can actually deliver those primitives on real infrastructure before any protocol logic is built on top of them.
Phase 0 is not a demo. It is six discrete validation exercises, each proving that a specific component of the stack works when the conditions are real: a real blockchain, real fees, real network boundaries, real memory constraints, and real failure modes. The exercises are VAL-001 through VAL-006, covering the eUTxO settlement layer, the zero-knowledge privacy layer, the decentralized identity layer, the oracle attestation layer, the multi-agent intelligence layer, and the stablecoin payment layer. This post documents what each one proved, what broke, and what it means for the protocol.
VAL-001: The eUTxO Foundation
What was validated: Cardano's eUTxO settlement model as the base layer for covenant distribution, locking funds in an Aiken validator and distributing to beneficiaries when a correctly structured redeemer is presented.
The validator is deliberately simple. It locks funds against a datum carrying two beneficiary key hashes and a release epoch, then releases them only when the redeemer carries the string "zivana-distribute" as a tag, an epoch greater than zero, and transaction outputs that pay both beneficiaries. Nine unit tests, nine passing, each constructing a real datum, redeemer, and transaction context and invoking the actual validator handler directly. The tests were specifically written so that mutating the validator body to unconditionally return true would cause seven of them to fail; a passing test suite is only meaningful if it has been observed to fail under regression.
Why this matters for the protocol: The eUTxO model is what makes Zivana's covenant mechanics deterministic. A covenant that distributes value to contributors on verified completion is not a simple transfer; it is a conditional settlement that must be enforceable at the contract level, not just at the application level. VAL-001 proves the base primitive. Every distribution mechanism in the protocol builds on what was confirmed here.
One finding worth noting for builders: Cardano validators cannot read transaction metadata. It is outside the script context. Any condition that needs to be checked on-chain must be passed through the redeemer, which is the idiomatic eUTxO pattern and the correction that was made from the original task stub that assumed metadata access. You can find more about it here.
VAL-002: Privacy Without Exposure
What was validated: Midnight's zero-knowledge proof system as the privacy layer, proving that a trust score clears a threshold without revealing the score itself.
This is the primitive that changes what verification means for an informal economic actor. The current model of verification requires disclosure: show your bank statements, show your tax records, show your transaction history. The entire value of your proof is in the data you are forced to surrender. A zero-knowledge threshold proof inverts this. You prove you qualify without revealing the underlying data. The verifier learns exactly one bit: pass or fail.
VAL-002 built two Compact circuits on Midnight. The first is a single-threshold circuit where a participant proves their private trust score exceeds a public minimum. The design decision to use a disclosed boolean rather than an assertion-based abort was deliberate: an assert that aborts on failure would leak the fact that an attempt happened even without revealing the score, since a reverted transaction is itself information. A disclosed boolean keeps success and failure transactions shape-identical on-chain.
The second circuit extends this to two threshold tiers using one parameterized circuit rather than two separate ones. A Tier enum parameter selects which threshold to check, and the circuit discloses the tier before branching on it, a critical finding documented below.
Eight engineering challenges were encountered and resolved. The most instructive:
The circuit parameter disclosure requirement. Compact treats all circuit parameters as private unless explicitly disclosed, not just values declared via witness. When the tier parameter was used in a conditional branch and its result written to the ledger, the compiler flagged it as an undeclared potential disclosure path. The fix is const publicTier = disclose(tier) before using it. This is not intuitive when the parameter feels like metadata rather than secret data, but it reflects the compiler's correct reasoning: branching on an undisclosed value and writing the result of that branch to a public ledger is a disclosure path regardless of whether the branching variable itself feels sensitive.
DUST registration deadlock on Preprod. On Midnight's public testnet, a wallet sync that waits for shielded && unshielded && dust all at once, with DUST registration running after that wait, creates a deadlock. DUST only becomes available after an explicit on-chain registration transaction. Order matters: start the wallet, register, then run the full sync wait.
The Node.js heap exhaustion during long syncs. A fresh wallet syncing Midnight Preprod can exhaust Node's default heap after over twelve hundred sync emissions. The fix is running with NODE_OPTIONS='--experimental-vm-modules --max-old-space-size=8192'. This is not a Midnight-specific problem, it is what happens when a long-lived public network with real chain depth meets Node's default memory ceiling.
All ten tests pass against local devnet, covering both circuits across all tier and outcome combinations.
Why this matters for the protocol: VAL-002 is the proof that Zivana can implement selective disclosure at the protocol level. A trust score that can be proven above a threshold without being revealed is the core mechanism that lets informal economic actors prove they qualify for opportunities without surrendering ownership of the data that generated the score. This is not a feature. It is the reason Midnight is in the stack.
VAL-003: Identity That Travels
What was validated: Hyperledger Identus as the self-sovereign identity layer, end-to-end W3C DID publication, credential issuance, and presentation verification across three independent nodes on Cardano preprod.
The validation ran three fully independent Cloud Agent stacks, issuer, holder, and verifier, communicating over DIDComm V2 across separate Docker networks with no shared state. The objective was to prove that a credential issued by one agent can be independently verified by a completely separate agent using only the public Cardano blockchain as the source of truth, with no central server, no API callback to the issuer, and no trust in any single party.
What was confirmed, with verifiable on-chain evidence:
A PRISM DID was published to Cardano preprod at transaction f6becc5272cf26a328c5d822390a5fee68a769bc23b26e3fcf11f8e075688389, block 4,894,745, slot 127,424,674. The wallet balance decreased by 183,365 lovelace, real fee paid, real transaction submitted, not a simulation. A W3C Verifiable Credential in JWT format was issued by the issuer agent to the holder agent over a live DIDComm V2 connection, containing claims, a registered schema, and a resolvable credential status URL. The holder presented that credential to the independent verifier, which resolved the issuer DID from the Cardano preprod chain, verified the JWT signature, checked the credential status, and returned PresentationVerified.
Seven previously undocumented engineering findings were encountered, diagnosed, and resolved:
NODE_LEDGER=cardano is not the default. Without it, prism-node defaults to in-memory mode and reports PUBLISHED without submitting any Cardano transaction. The wallet balance will not change. The blockchain will have no record of the DID. This was the root cause of several hours of believing DIDs had been published on-chain when they had not. The proof was in the wallet: exactly 10,000,000,000 lovelace, one incoming transaction, and zero outgoing.
NODE_CARDANO_NETWORK must be testnet, not preprod. The enum in prism-node v2.6.0 accepts only Testnet or Mainnet. Passing preprod causes a NoSuchElementException crash at startup. This is not documented in the Identus setup guides.
POLLUX_STATUS_LIST_REGISTRY_PUBLIC_URL controls credential status URLs. It defaults to http://localhost:{port}. In a multi-container setup, localhost inside the verifier container resolves to the verifier itself, not the issuer. The verifier cannot reach the issuer's status list, and verification fails with ResourceNotFound. Setting this variable to the issuer's host bridge IP fixes it.
Docker bridge network gateway IPs must be pinned with IPAM subnets. Without explicit subnet configuration, Docker assigns bridge network subnets dynamically. Gateway IPs used in DIDComm service URLs will not match on a different machine or startup sequence. The result is silent failure: DIDComm connections appear to succeed, but messages never arrive.
Vault file backend hits Linux path length limits. Long DIDComm key names cause file name too long errors when using Vault's file storage backend. The fix is the Raft backend, which uses BoltDB and has no path length constraints.
Vault startup ordering matters. The Cloud Agent initialises its default wallet during startup. If Vault is not yet unsealed when the agent starts, the wallet initialization fails. Add a health check to the Vault container and set the Cloud Agent's depends_on condition to service_healthy rather than service_started.
The full Cardano infrastructure is heavy. Running a complete Cardano preprod stack, node, wallet, db-sync alongside issuer and verifier prism-nodes requires a minimum of 15GB RAM available to Docker. The verifier's prism-node must sync the entire Cardano preprod chain history before it can resolve a recently published DID, which takes three to six hours on the first run. This is a real constraint for new teams building on Identus.
Why this matters for the protocol: VAL-003 is the proof that identity can travel. A DID issued by one agent, anchored on a public blockchain, and verified by a completely independent agent that has never interacted with the issuer, this is what self-sovereign identity means in practice. For informal economic actors whose identity currently exists only inside their immediate community, this is the primitive that makes everything else in the protocol possible. The trust score means nothing if the identity it is attached to cannot be verified independently. VAL-003 proves the identity layer works.
VAL-004: Making Revenue Visible
What was validated: The oracle attestation layer, a Schema.org fact-statement for an SME revenue event, published as a signed on-chain datum on Cardano preprod using a protocol-compatible Aiken validator and queryable by any application that can read the chain.
This validation is where the informal economy's core invisibility problem becomes a concrete engineering problem. A trader's revenue exists. It is real. But it is not machine-readable. It cannot be seen by a smart contract. It cannot be acted on by a lender in another city. VAL-004 proves that real-world economic events can be attested on-chain in a standardized format, making informal revenue visible to any application built on the protocol without requiring the economic actor to go through a formal institution first.
The fact statement follows Orcfax's real FsDat<t> datum shape, verified against Orcfax's own publishing source. The t type is filled with a custom RevenueBody carrying the revenue amount in minor units to avoid on-chain floating-point, the ISO 4217 currency code, the period covered, the participant's DID, and the SHA-256 hash of the off-chain JSON-LD document. The validator is parameterised by a publisher verification key hash and enforces minting, spending, and content validity constraints across three rounds of security review.
The validation went through four review passes, each finding real issues:
First review: Six findings, including a critical one where the spend handler only checked the publisher's signature, meaning a published fact statement could be silently rewritten as new datum, same token, no burn, without re-running the mint handler's content checks. Fixed by making spend revoke-only: spending requires burning the token. Also fixed: inverted period validation, negative amounts, malformed currency codes, a floating-point bug in currency unit conversion, and a missing test suite. Fourteen Aiken unit tests added.
Second review: A deeper multi-UTxO bypass of the same spend fix. Given two fact UTxOs, a transaction could spend both, burn only one, and pay the surviving token to an ordinary wallet output. Each spend call independently saw a burn somewhere in the transaction and passed, even though only one token actually left circulation. Fixed by requiring zero fs tokens across all outputs, making the extraction transaction unbalanceable. Also fixed: a unit inconsistency where created_at carried milliseconds while period_start and period_end carried seconds, renamed to created_at_ms and validated against the transaction's validity range. Suite grew from 14 to 25 tests.
Third review: The validity range check was vacuously true when the range was unbounded, and nothing required it to be bounded. A transaction built directly through Lucid could leave the range as interval.everything() and declare any created_at_ms at all, including one far enough in the future to permanently outrank every legitimate later publication. Fixed by requiring both bounds to be Finite and capping the range width at one hour. Suite grew from 25 to 28 tests.
Fourth pass: Dependency pinning, secure seed phrase handling, currency decimal precision, and CI reproducibility. The gen-wallet.ts script was writing the seed phrase to stdout; fixed to write to a gitignored file with owner-only permissions. Currency display precision was using floating-point division, which silently loses precision for large amounts; fixed with integer-based decimal formatting.
The current live publication is at transaction f0ed0879366b2c01e59bfaaab920062a9f690d403d2741373a5ac26529ccb203, block 4,932,897, slot 128,295,396, on the fully corrected contract. The wallet balance independently confirms the transaction is real: fee plus locked min-ADA totals 2,040,043 lovelace, and 9,991,915,746 - 2,040,043 = 9,989,875,703, which matches exactly what Blockfrost reports at the address right now.
One finding was deliberately not adopted: a recommendation to cryptographically bind the participant field to the publisher key. This was disagreed with because it contradicts what an oracle is for. The publisher is the trusted attestor, Zivana's oracle key. The participant is the economic actor the attestation is about. Requiring the participant's DID to be controlled by the publisher would mean the publisher could only ever attest to facts about itself, turning a third-party attestation oracle into a self-report system. This mirrors Orcfax's real protocol exactly: for a CER feed, the collector attests to a fact about ADA; ADA does not sign the attestation.
Why this matters for the protocol: VAL-004 is the proof that economic activity can be made legible on-chain. A revenue event that happened in the physical world, attested by a trusted oracle, anchored on a public blockchain, queryable by any consumer contract, this is the primitive that makes informal economic reputation financeable. The trust score is not an opinion. It is built from attested events. VAL-004 proves the attestation layer works.
VAL-005: The Intelligence Layer
What was validated: Fetch.ai's multi-agent infrastructure as the intelligence layer, a uAgent deployed on Agentverse that calls ASI Cloud for market price computation and returns results as Orcfax COOP-compliant fact statements.
A trust score without context is not trustworthy. A trader with 500,000 naira in monthly revenue is doing well or doing poorly depending on her sector, her market, and what the seasonal pattern looks like. Without an intelligence layer that can contextualize economic data against real market benchmarks, a trust score is just a number. VAL-005 proves that Fetch.ai's multi-agent infrastructure can provide that contextualization at protocol scale.
The architecture is a Fetch.ai uAgent that accepts a MarketQuery message containing a product name and market region, calls the ASI Cloud inference endpoint with a structured prompt requesting a market price estimate, parses the JSON response, and returns a FactStatementResponse in Orcfax COOP JSON-LD format. The agent runs both locally and on Agentverse. Without an ASI Cloud API key, it runs in mock mode with hardcoded prices for testing.
The output follows Schema.org structure: a Claim whose about is a PriceSpecification with price, currency, validity window, and product description, plus metadata properties for data source and computation timestamp. The agent was deployed on Agentverse, verified in the dashboard, and tested end-to-end with a client querying cassava flour prices in Lagos.
Why this matters for the protocol: VAL-005 is the proof that the intelligence layer can operate at protocol scale using open multi-agent infrastructure. A benchmark is not surveilled; it is the context that makes an attestation meaningful. Knowing that a trader's revenue cleared 500,000 naira means something different in a high-volume wholesale market than in a small neighborhood retail context. The intelligence layer provides that context. Combined with VAL-004's attestation layer, this is what turns raw economic data into a meaningful, benchmarked trust signal.
VAL-006: Cross-Chain Settlement
What was validated: Celo's EVM-compatible stablecoin infrastructure as the settlement layer for covenant distributions delivered through Opera MiniPay.
One practical constraint in the informal economy is that value must reach people where they are. For hundreds of millions of people across West Africa, that means a mobile device with limited connectivity, and increasingly, a MiniPay wallet inside Opera Mini. VAL-006 proves that the settlement layer can reach that endpoint.
The validation deployed a token-agnostic CusdPaySplitter contract on Celo Sepolia, funded it with USDC via the Circle faucet, and distributed payouts to two recipients in a single transaction. The contract is intentionally token-agnostic: it works with USDC on Celo Sepolia, USDm via Mento, and cUSD on mainnet, with the stablecoin address passed at deployment.
One important finding for builders: Alfajores, the testnet named in the original task, was deprecated when Ethereum Holesky sunset in September 2025. The live developer testnet is Celo Sepolia, chainId 11142220. Classic cUSD is not deployed on Celo Sepolia; the equivalent stablecoins are USDC and Mento USDm.
The live deployment is at 0x37927bE9BC87c4124a2A2ba3FD1fAD6A0e141c8f on Celo Sepolia, verified on Blockscout. The distribute transaction 0xd045f93a... paid Recipient 1 0xdD75...0b25 0.4 USDC and Recipient 2 0x7E9c...9F83 0.6 USDC in a single on-chain operation.
A Lucid base-versus-enterprise address mismatch cost the most time: the wallet was generated with an enterprise address, but selectWallet.fromSeed without an explicit addressType option derives a base address from the same seed, a different bech32 string, even though the underlying payment key is identical. Lucid's coin selection queries the derived address, finds nothing, and reports insufficient funds rather than a wrong address.
Why this matters for the protocol: VAL-006 is the proof that the settlement layer can reach MiniPay. Zivana Protocol's covenant mechanics settle value for protocol users on verified completion. That settlement must reach people through the channels they actually use. Celo's EVM compatibility and MiniPay's reach into the African mobile ecosystem make this the right settlement layer for the protocol's distribution mechanics.
What a Complete Protocol Interaction Looks Like
The five primitives above are not independent. They compose. Here is what a complete end-to-end protocol interaction looks like when they all work together, using a single economic actor as the thread.
Amara is a tailor in Oshodi. She has been running her business for four years, has consistent monthly revenue, and has trained two apprentices. She does not contribute to Zivana Protocol. She is the person the protocol is built for.
Identity. Amara's cooperative issues her a W3C Verifiable Credential attesting her membership, her role, and her years of contribution, anchored to a PRISM DID published on the Cardano blockchain. The credential belongs to Amara. It lives in her Identus wallet. When she applies for a loan from a capital provider in another city who has never interacted with the cooperative, the verifier resolves her DID from the Cardano chain, verifies the credential signature, and confirms it is genuine, without calling the cooperative, without trusting a central database, and without Amara surrendering any data beyond what she explicitly chooses to present.
Attestation. An application built on Zivana's oracle layer publishes a revenue event fact statement attesting to Amara's monthly business revenue. The datum is on-chain, signed by the attesting party, anchored at a specific block and slot. The capital provider's evaluation system reads this datum directly from the chain. It does not need to call anyone. It does not need to trust a report Amara produced herself. The attestation is third-party, verifiable, and permanent.
Intelligence. The market benchmarking layer queries the going rate for cooperative tailoring revenue in Lagos. Amara's attested revenue is 320,000 naira. The benchmark for her category and region is 280,000 naira. Her revenue clears the benchmark by fifteen percent. This context is what turns the raw attestation into a meaningful signal. Without it, 320,000 naira is a number. With it, it is above-average performance in her specific market.
Privacy. A zero-knowledge proof is generated confirming that Amara's trust score, computed from her credentials, her attestations, and her benchmark position, exceeds the capital provider's minimum threshold. The proof reveals one bit: pass. The capital provider learns that Amara qualifies. They do not learn her score, her revenue figure, her benchmark position, or any of the underlying data. Amara controls what is disclosed.
Settlement. When the loan is approved and the capital provider disburses funds, the settlement layer routes the payment through a stablecoin splitter to Amara's MiniPay wallet. One transaction, on-chain, verifiable, reaching her where she is.
This is what the stack enables. Not in theory. In production, on real infrastructure, with on-chain evidence at every step.
Go deeper into each validation
Each exercise in Phase 0 has its own full write-up with engineering findings, on-chain evidence, and reproduction steps. If you want to go further than the summary above:
What Phase 1 Looks Like
Phase 0 was about proving components. Phase 1 is about composing them.
The protocol primitives are confirmed. The identity layer anchors to Cardano. The privacy layer runs on Midnight. The attestation layer publishes to Cardano. The intelligence layer runs on Fetch.ai. The settlement layer reaches MiniPay through Celo. Each of these was verified in isolation, against real infrastructure, with documented findings that the next builder does not need to rediscover.
Phase 1 begins building the protocol logic that composes these primitives: the trust scoring mechanism that aggregates attested events, the covenant smart contracts that govern contribution and distribution, the governance layer that manages protocol parameters, and the integration layer that connects the Cardano and Midnight stacks into a coherent protocol surface.
The findings from Phase 0 are all public. The validation repository is at https://github.com/zivana-labs/zivana-validation. The individual write-ups are published at nextrium.org/blog. The on-chain evidence is verifiable by anyone with a Blockfrost key or a Cardano preprod explorer.
Phase 0 was where the real conditions were encountered. Phase 1 is where they are built on.
Follow the Zivana Protocol blog at zivana.network/blog and the Zivana GitHub organization at https://github.com/zivana-labs for updates as they are released.