DarkFi Development Uncensored Part 13
Parallel societies are not a metaphor. They are a specification. The opcode layer now provides the mathematical completeness required to build them and they will be built by workers who do real work.
Further to
the legacy smart contracts using the safemath workarounds have been deprecated on an archived fork of the Uncensored DarkFi repo, on the master branch all contracts have been thoroughly rewritten, putting Object Capability Security patterns and contract composition first. The Identity contract particularly benefits from this paradigm shift because it can then easily compose with insurance and finance functions without privacy compromises. The latest version of the Uncensored DarkFi Book is now back down under 1000 pages, compared to the previous one, but is now much more informationally dense with respect to how contracts compose with with each other from the worker to the boardroom to the stock trading floor and back again: everything is accountable, prove-able and composes with everything else. The write up below was created with Deepseek.
The Identity Contract as Cornerstone: O‑Cap, the Mutual Pipeline, and Parallel Societies
1. Parallel Societies and the Worker’s Position
The “Parallel Societies” chapter of the Uncensored DarkFi Book documents a persistent exclusion: industries vital to social reproduction – healthcare, domestic labour, education, freelance work, mutual insurance, union organisation – have been largely absent from privacy‑preserving crypto systems. The technical reasons are not ideological. They are mathematical.
Threshold checks (e.g., “experience ≥ 5 years”), ratio calculations (e.g., “premium = risk_score / 10000”), and selective disclosure (e.g., “I am over 18, but nothing else”) could not be expressed in zero‑knowledge circuits with the same soundness as simple arithmetic or hashing. The opcode layer of DarkFi’s zkVM, until recently, lacked return‑value comparisons and division. Contract authors could build private dice or atomic swaps; they could not build a private labour market or a mutual insurance DAO without resorting to plain WASM workarounds that broke composability and exposed sensitive data.
This is not a critique of intent. It is a description of a structural gap.
A worker in the real economy has three non‑negotiable expectations:
Verifiable competence – the ability to prove skills, credentials, and experience without surrendering a complete personal history.
Fair compensation – payment conditional on quality, without wage surveillance or identity‑based discrimination.
Organisational participation – membership in mutuals, unions, or cooperatives without identity exposure that could lead to retaliation or exclusion.
Current crypto systems place the burden of transparency on the worker. The challenge, as articulated in the Uncensored Fork, is to shift that burden to the system and to management (the organisational “bourgeoisie”). The Identity contract, now completed by the formal verification of LessThanOrEqual and the implementation of BaseDiv, does exactly that.
2. Opcode Status – Enabling the Identity Contract
The “DarkFi Opcodes and Formal Verification” chapter provides the current status of the zkVM’s comparison and arithmetic opcodes. The relevant entries for the Identity contract and the downstream mutual pipeline are as follows:
OpcodeStatusEnables
LessThanOrEqual(0x55)✅ Verified sound (Lean 4 exhaustive testing)Threshold predicates (experience >= 5), selective disclosure (Level 1 privacy), conditional paymentsBaseDiv(0x58)✅ Implemented (binary exponentiation, Fermat’s little theorem)Actuarial premium calculation, ratio‑based pricing, profit splitsIsEqualBase(0x54)❌ Bug (delta‑invert unconstrained when a == b)Useconstrain_equal_basefor assertion‑only equality
The verification of LessThanOrEqual means that a circuit can now compute is_authorized = less_than_or_equal(threshold, attribute_value) and use the resulting 0/1 field element in subsequent logic (e.g., cond_select, bool_check, or as a public instance output). This is the foundation of selective disclosure: the verifier learns whether the condition holds, but not the actual attribute value.
The implementation of BaseDiv allows circuits to compute quotient = base_div(a, b) directly, using binary exponentiation (cost ~500 field multiplications). This is essential for any ratio‑based calculation – premiums, percentages, or proportional splits – that must be proved in‑circuit rather than computed in plain WASM.
With these opcodes sound and present, the Identity contract’s Object Capability (O‑Cap) features can be implemented with full cryptographic guarantees for all threshold and ratio‑based predicates.
3. O‑Cap and the Identity Contract – A TL;DR from the Worker’s Perspective
The “O‑Cap & Composable Privacy” chapter describes a paradigm shift in authorisation. Traditional systems use Access Control Lists (ACLs): the system asks “who are you?” and looks up your permissions. This forces the user to reveal identity before proving authority.
Object Capabilities invert the question. The system asks: “what can you prove you can do?” The proof is a zero‑knowledge argument that the user holds a capability – a cryptographic token bound to a secret. The verifier learns only that the capability is valid, not who the user is.
The Identity contract implements four opcodes that make this paradigm operational:
RegisterCapabilityV1(0x09) – defines a capability (e.g.,qualified_contractor) and its credential requirements (e.g., must hold asenior_engineercredential and proveexperience ≥ 5).IssueCapabilityV1(0x0a) – issues a capability to a worker who proves (in ZK) that they meet the requirements.VerifyCapabilityV1(0x0b) – allows any other contract to check whether a worker holds a given capability, without learning the worker’s identity.RevokeCapabilityV1(0x0c) – allows the issuer to revoke a capability (e.g., when a credential expires or a bond is slashed).
Why this is a game‑changer for labour markets:
A worker can obtain the qualified_contractor capability by proving they hold a senior_engineer credential and that experience >= 5. The proof uses LessThanOrEqual to output a public predicate_result (1 if the threshold is met, 0 otherwise). The actual years of experience remain hidden. The worker’s identity is never stored on‑chain; only a nullifier derived from the capability secret is recorded.
When the worker bids on a tender, the tender contract calls VerifyCapabilityV1 and learns only that the worker holds qualified_contractor. The worker’s name, employer, salary history, and exact experience are never revealed. The same capability can be verified again when the worker submits a deliverable (defence against delegation or expiry), and again when receiving payment. The system proves competence; the organisation respects privacy.
4. The Composability Matrix – Identity Through Tendering and Payment
The “Composability & General Primitives” chapter includes a cross‑contract composability matrix that maps which contracts call which, and which O‑Cap capabilities are verified. For the mutual pipeline – the worker’s journey from credential to wage – the relevant subset is as follows:
Contract (Caller) →Identity (O‑Cap)MoneyDAO‑EscrowTenderInsurance MarketLabor MarketAttestationWorker (via Tender)Prove
qualified_contractor––Submit sealed bid–––Worker (via Labor Market)Provequalified_contractor(again)––––Submit deliverable–Worker (via Insurance)Provepolicy_holder–––File claim––Tender (selecting winner)Verify winner’s capability––––Create job–Labor Market (releasing payment)Verify worker capabilityPayment transfer––––Verify deliverable claimInsurance Market (underwriting)Verifyverified_underwriterPremium, payout––––Verify loss claimDAO‑Escrow (governance)Verifymember_in_good_standingTreasury/endowment–––––
Key observations:
The Tender contract verifies
qualified_contractorbefore accepting a sealed bid. This ensures that only competent workers can bid, without revealing who they are.The Labor Market contract verifies the same capability again when the worker submits a deliverable. This prevents delegation (a worker passing the bid to an unqualified subcontractor) and ensures the capability has not expired or been revoked.
Payment release from the mutual’s treasury to the worker is conditional on a successful attestation. The Attestation contract verifies quality using
LessThanOrEqual(required_score, earned_score). The Money contract transfers the wage with amounts hidden via Pedersen commitments.The worker is never asked “who are you?”. Only “do you hold the required capability?”. This places the burden of proof on the system (crypto) and the organisation (management), while the worker retains full privacy over identity.
5. The Mutual Pipeline – Worker’s Journey (Identity‑Centred)
The following contracts, all documented in the Uncensored Book, compose into a closed‑loop real‑economy pipeline. The worker’s journey is traced step by step, with Identity contract interventions highlighted.
5.1 Worker obtains capabilities
The worker registers for the qualified_contractor capability (and optionally verified_underwriter, union_member) with the Identity contract. The issuer – a professional body, a trade association, or the mutual itself – verifies the worker’s credentials and threshold predicates via LessThanOrEqual proofs. The Identity contract issues capability nullifiers. The worker’s identity is never stored on‑chain; only the capability’s nullifier and expiry are recorded.
5.2 DAO‑Escrow as the mutual container
The mutual is deployed using DAO‑Escrow in MODE_TREASURY_ENDOWMENT. Workers pay premiums, which are split into a treasury pool (operational costs) and an endowment pool (insurance reserve). Membership notes are issued with block‑based expiry, enforced in‑circuit by less_than_strict. Optional DrainProtection (graduated tiers, exit queue, circuit breaker, etc.) can be enabled at deployment to guard against malicious governance or mass exit.
5.3 Tendering – worker bids on work
The mutual (or a member) creates a tender requiring the qualified_contractor capability. The worker submits a sealed bid via the Tender contract’s SubmitBidV1. The bid circuit includes a proof of capability obtained from VerifyCapabilityV1. During the reveal phase, LessThanOrEqual compares bid amounts; the winner is selected without revealing losing bids or the identities of losing bidders.
5.4 Insurance – worker purchases coverage (or mutual provides it)
Depending on the mutual’s policy, the worker (or the mutual on the worker’s behalf) purchases insurance for the job. The Insurance Market contract calculates the premium using BaseDiv (e.g., premium = base_div(risk_score, 10000)). The underwriter’s capability (verified_underwriter) is verified via Identity. If a claim is filed, the Attestation contract verifies the loss, and the Insurance Market contract releases payout from the endowment pool.
5.5 Labour – worker executes and receives payment
The Labor Market contract creates a job from the tender winner (CreateJobV1). The worker submits a deliverable via SubmitDeliverableV1. The Attestation contract verifies the deliverable’s quality using LessThanOrEqual(required_score, earned_score). Upon successful verification, the Labor Market contract calls the Money contract to transfer payment from the mutual’s treasury to the worker. The amount is hidden via Pedersen commitments; only the fact of transfer is recorded on‑chain.
5.6 Back to DAO‑Escrow
The worker’s membership continues – premiums may be deducted from wages automatically, or paid separately. The mutual’s endowment grows from success fees (a small percentage of each completed job). The treasury funds operational costs, dispute resolution, and future tenders. The cycle repeats.
6. Why This Was Not Possible Before
Three separate gaps prevented the above pipeline from being built as a fully private, composable ZK system.
First gap – return‑value comparisons. Before the formal verification of LessThanOrEqual, the only sound comparison opcodes were less_than_strict and less_than_loose, which are constraint‑only: they fail the circuit if the relation does not hold, but they return no value. This is sufficient for assertion‑only checks (e.g., “collateral must be at least twice the debt”) but insufficient for selective disclosure (“the verifier must learn whether experience >= 5, but not the actual value”) or conditional logic inside the circuit. The Identity contract’s threshold predicates require a Boolean output that can be constrained to a public instance. LessThanOrEqual now provides that.
Second gap – division. Without BaseDiv, any ratio calculation – premiums, percentages, proportional splits – had to be performed in plain WASM outside the ZK circuit, breaking privacy and composability. The Insurance Market contract’s premium pricing model could not be verified in‑circuit. With BaseDiv implemented, actuarial logic can be moved entirely into ZK.
Third gap – O‑Cap as a production pattern. The conceptual framework of Object Capabilities existed, but without sound return‑value comparisons, the Identity contract could not issue capabilities that depend on threshold predicates. Workers could not prove “I meet the experience requirement” without revealing their exact experience. The entire mutual pipeline depended on this missing piece.
All three gaps are now closed. The circuits compile. The opcodes are formally verified. The O‑Cap composition is fully specified in the Uncensored Book.
7. Open Questions
The pipeline is implementable, but several empirical and design questions remain. These are not obstacles – they are invitations for further research and thoughtful contribution.
Gas costs. What are the empirical gas costs of a full pipeline transaction on DarkFi testnet? This includes: capability issuance (once per worker), sealed bid submission, bid reveal, job creation, deliverable submission with attestation, and payment release. How do these costs scale with the number of bidders or the complexity of quality attestations?
DrainProtection interaction.
DAO‑Escrow’s optionalDrainProtectionfeatures (graduated withdrawal tiers, exit queue, circuit breaker, guardian pause) are designed to protect the endowment from malicious governance. How should these features interact with pending tenders and in‑flight jobs? For example, if the circuit breaker is triggered, should ongoing work be paused, or should existing jobs be allowed to complete while new tenders are suspended?Time‑based revocation. The Identity contract’s
RevokeCapabilityV1is issuer‑initiated. Can it be extended to support time‑based automatic revocation – e.g., a capability that expires after a certain block height without requiring issuer action? This would reduce issuer overhead and increase trustlessness for time‑sensitive credentials.Multi‑capability UX. A worker may hold multiple capabilities (e.g.,
qualified_contractor,verified_underwriter,union_member). Should they maintain separate secrets per capability, or can capabilities be derived from a single root secret without compromising privacy? What are the trade‑offs in terms of nullifier management and revocation?Dispute resolution fallback. The pipeline relies on the Attestation contract’s quality check using
LessThanOrEqual. If the quality criteria are ambiguous or the attestation circuit fails (e.g., due to malformed evidence), can the mutual’s governance (viaDAO‑Escrow) provide a fallback mechanism? What would that mechanism look like – a vote, an arbitrator, a timeout?Organisational models.
DAO‑Escrowoffers three modes (MODE_ESCROW,MODE_TREASURY,MODE_TREASURY_ENDOWMENT). Which organisational models (flat cooperative, hierarchical mutual, guild) are best supported by each mode? How does the choice affect the worker’s privacy and bargaining power? For example, a mutual that prefers lower wages and better benefits (a traditional trade‑union model) would configure the treasury/endowment split differently than a platform cooperative that maximises individual payouts.
8. Closing Statement
The Identity contract, completed by the soundness of LessThanOrEqual and the implementation of BaseDiv, transforms DarkFi from a platform for speculative privacy into infrastructure for parallel societies. The capability matrix – from credential issuance, through tendering, to payment – places the worker’s reasonable expectations at the centre. The circuits are written; the opcodes are verified; the O‑Cap composition is specified. The remaining questions are empirical and design‑oriented. The code awaits audit; the testnet awaits deployment.
Until next time, TTFN.