Private bearer note
DarkWow
A private bearer-note system: the note is the asset, possession is authority, and no protocol-level administrator can freeze or confiscate it.
- What
- DarkWow is a Layer 1 design for private DeFi and private organisations. Its base asset is a bearer note: a commitment held by whoever knows its spend secret. The issuer may redeem, refuse, or dilute; the holder prices that as counterparty risk. What the protocol does not provide is a freeze list, an allowlist, or an admin key over the note.
- Why
- A private chain usually asks members to trust an operator; a public chain exposes membership and strategy. DarkWow tries to get both without a protocol-level administrator: authority is a name you hold, not an identity you assert; supply is checked at the block boundary; and the assurance boundary is written down. I could see that the basis of what DarkFi had could achieve this, but DarkFi had no interest in doing so.
- The combination
- Rholang/RChain (names as authority) + Halo 2 (private state transitions) + a manifest-driven capability wallet + a per-block Pedersen supply audit.
The thesis
The note is the asset. The commitment is the note; the nullifier secret is possession. To transfer or redeem, the holder proves knowledge of the secret and publishes a nullifier; no entrypoint can move the note without it. There is no freeze opcode, no allowlist, and no admin key in the Promissory Note contract.
No turnstile at the protocol layer. The native token and the note do not require registration. Identity credentials are opt-in; issuer contracts and relayers are explicit counterparties. The protocol does not gate the base asset.
The issuer is the counterparty. PN does not enforce redemption, collateral, or a supply cap. RedeemV1 burns a note and creates a zero-value receipt; releasing the underlying asset is the issuer’s act. The issuer may also dilute. The holder prices both. The absence of enforcement is the design.
That is the difference from an ACL or membership system: there is no turnstile to capture. What remains is counterparty risk, stated and priced, not hidden behind an administrator.
How the system composes
- Promissory Note is the base asset.
RegisterTypeV1,IssueV1,TransferV1,OtcSwapV1,RevokeV1,RedeemV1. Minting is proof of knowledge of a mint secret stored astoken_auth_parentand bound into the asset id. Redemption burns the note and creates a zero-value receipt. The receipt is an on-chain redemption record, not proof of off-chain settlement. - Box and Purse are the ZK capability containers. Box is linear Put/Take: the old state is nullified and a new leaf is appended, so a capability can be delegated without a mutable account. Purse hides a balance in a Pedersen commitment and proves conservation homomorphically. The ZK versions are the fork-original work; the base abstractions are Agoric’s Invitation and ERTP Purse.
- Identity, Oracle, Attestation are the optional credential and data layer. Identity issues credentials and proves predicates; Oracle proves who wrote a datum, not that it is true; Attestation generalizes claims and predicates. Their gates are issuer-level and opt-in.
- Stablecoin and Bridge are issuer contracts. Stablecoin is a CDP over PN with a governance key and a dead-man switch; only the pooled-debt model is implemented. Bridge wraps an external asset as a PN 1:1; the wrapped note is user-held, external release is relayer-executed, and
bridge-verifyis fail-closed by default. - NativeToken and Uncle Merkle are the base layer. A shielded UTXO token with no premine; every block is checked against a Pedersen mass balance over native-token calls; the cumulative supply commitment chain is carried by the plaintext coinbase. This is host-side arithmetic, not a ZK block proof.
- The wallet and manifests make it composable. Each contract declares its functions, circuits, capability types, and actions in a TOML manifest. The wallet reads manifests, scans the chain, and composes capability types from the primitives it finds; keys stay in the AccountManager and never reach the daemon.
- The assurance layer is explicit. Lean 4 models 32 zkVM opcodes and 10 gadget files; the verdict is mixed per opcode. There are 6 assumptions, with
pallasPrimethe only arithmetic one. The gate checks instance derivation for 167 contract circuits (179 walked); it does not prove circuit correctness.OBL-Z12is closed in the obligation register. The proof-status ledger is the authority; counts drift.
What is fork-original
| Work | Fork-original | Boundary |
|---|---|---|
| Promissory Note | The no-freeze bearer note: proof-of-mint-secret issuance, a zero-value redemption receipt, and issuer-priced counterparty risk. The note is the asset; possession is authority. | Bearer notes and contract-mediated redemption predate it (Arcade, ERC-4626, Liquity). The no-freeze composition is the fork’s. Genesis-deployed; the issuer remains the counterparty. |
| ZK Box and Purse | The ZK versions of the capability containers: Box is a linear Put/Take slot whose prior state is consumed by a nullifier; Purse hides balances in a Pedersen commitment and proves conservation homomorphically. | Agoric’s Invitation/ERTP and Zcash/Semaphore notes supply the base abstractions. The ZK versions, circuits, and manifests are the fork’s. Genesis-deployed. |
| ZK contract suite | A single-chain suite with ZK circuits for the core state transitions of Identity, Oracle, Attestation, and Stablecoin. | Each component has prior art (Semaphore, Axiom/HyperOracle, Reclaim, Aztec zkDAI). The combination is the claim; some administrative and revocation paths remain signature-authenticated; Stablecoin is experimental. |
| Supply audit | A per-block Pedersen mass balance over native-token calls, plus a cumulative supply commitment chain carried by the plaintext coinbase. | Grin/Mimblewimble and Zcash ZIP 209 supply auditing. The check is host-side Pedersen arithmetic, not a ZK block proof; it is defense-in-depth, not a proof of full supply integrity. |
| Bridge | A fork-specific non-custodial redesign: deterministic deposit addresses, user-held withdrawal secrets, nullifier-based withdrawals, and wrapped notes held by the user. | IBC, atomic swaps, and trustless ZK bridges predate the non-custodial property. The current default refuses every deposit; with bridge-verify on, Ethereum, Monero, and Litecoin verify while Zcash and Aztec return errors. External release is relayer-executed. |
| Assurance | Lean 4 gadget-level theorems for less_than_or_equal, base_div, and is_not_equal, plus a canonical proof-status ledger that separates proved, assumed, manually audited, and not modelled. | Halo 2/Fermat constructions; Lean 4 verification of ZK gadgets exists elsewhere (halo2-formal, ArkLib). The current contracts use less_than_or_equal and a quotient-remainder pattern; base_div and is_not_equal are not used. The proofs are evidence, not an enabling layer; OBL-Z12 is closed in the obligation register. |
The base abstractions are prior art; the contribution is the composition and the boundary. Prior art is named only where it changes the claim.
Provenance
DarkWow is a fork of DarkFi. The zkVM, ZKAS circuit language, P2P stack, WASM runtime, and Halo2 backend are inherited. The fork-original work is the object-capability governance layer and genesis set, Uncle Merkle consensus, the TOML manifest/ABI, the capability wallet architecture, the ZK Box/Purse and the contract suite, the supply audit, and the added opcodes. The code is AGPL-3.0.
The contract design is a direct descendant of the Rholang/RChain work: a name is authority, capabilities compose, and the constraints have to be enforced from the beginning. The Rholo port is the other side of that lineage; the lessons of what happens when those constraints are not enforced are part of why this contract set is ZK-only.
The fork-era work was built by one primary developer with AI as a co-architect. The architecture is designed to contain what generated code can reach: capability boundaries, deterministic tests, and manifest-first integration. The formal record is in the obligation register.
The design stands on the 2005 ρ-calculus paper (Meredith & Radestock), the 2020 Halo 2 release (Zcash NU5 2022), and the 2026 fork-era work. Dates are publication and release dates, not claims of first use.
Evidence
| Measure | Value | Source |
|---|---|---|
| Contract codebases | 32 (9 genesis, 23 works in progress) | Contract catalog |
| Manifests | 32; on-chain hash pending | Manifest specification |
| Lean 4 coverage | 32 opcodes + 10 gadget files (partial); per-opcode verdicts, no blanket verdict | Opcode status |
| Circuit gate | 167 contract circuits; 179 walked; instance derivation only, not circuit correctness | Opcode and circuit status |
| Assumptions | 6; pallasPrime the only arithmetic one | Axiom boundary |
| Supply audit | Per-block Pedersen mass balance over native-token calls; cumulative supply audit chain | Consensus and supply audit |
| Obligation status | OBL-Z12 closed; OBL-C279 deferred to the next release | Obligation register |
| Premine | 0 | Repository |
Sources: repository README and architecture documents, as of October 2026. Counts drift; the linked artifact and proof-status ledger are authoritative.
[contract]
name = "example_contract"
category = "Example"
version = "1.0.0"
[[functions]]
name = "create_thing"
code = 0x00
requires_proof = true
proof_circuit = "create_thing_v1"
[[capabilities]]
discriminant = 0x00
name = "creator"
[[actions]]
function = "create_thing"
requires = { type = "none" }
produces = [{ name = "creator" }]Boundaries
- Issuer discretion. PN does not enforce redemption, collateral, or a supply cap. The issuer may refuse or dilute; the holder prices that as counterparty risk. A receipt is an on-chain redemption record, not proof of off-chain settlement.
- The bridge is deferred by default. With
bridge-verifyoff, every deposit is refused. With it on, Ethereum, Monero, and Litecoin have verifiers; Zcash and Aztec still return errors. The wrapped note is user-held; external release is relayer-executed. - Contract-level gates are explicit counterparties. Identity issuers can revoke credentials; Stablecoin has a governance key and a dead-man switch; relayers can censor. These are not protocol-level freezes over the note.
- The assurance boundary is written down. Lean covers opcodes and gadgets, not the contract circuits; 6 assumptions remain.
OBL-Z12is closed in the obligation register; one validator defect (OBL-C279) is deferred to the next release. The obligation register is the authority. - Known defects. The mass-balance check was inert until a token-commit constant was fixed, and historical blocks are unchecked. The obligation register records the current status; the check is host-side arithmetic, not a ZK block proof.
- No protocol-level freeze, not no trust. The note itself cannot be frozen or confiscated by a protocol administrator. The issuer, the credential issuer, the relayer, and the external chain are explicit counterparties. That is the design, not a missing feature.
- Manifests and wallet. On-chain manifest hashing is pending; the shipping wallet implements a subset of the ρ-calculus specification; there is no third-party audit and mainnet is TBD.
- What stands between this and production. A third-party audit; on-chain manifest hashing; bridge verifiers; the deferred validator defect OBL-C279. Mainnet is TBD.