ARTICLE 8|CYBER IMMUNITY

The Settlement Layer: Zero-Knowledge Accountability

How anonymous vouchers, three-identity compartmentalization, and monthly bulk settlement sustain a decentralized infrastructure without surveillance or networked consensus.

16 min read

Introduction

Each of the security guarantees established in the preceding articles depends on a decentralized network of independent nodes expending computational resources on behalf of users and vendors they have no direct relationship with.
This introduces a threat category beyond the cryptographic model: economic coercion. If payment flows reveal who is serving whom, an adversary can target specific nodes with bribes, legal pressure, or physical coercion. Payment transparency becomes an attack surface. This begs the question:
How do you compensate infrastructure providers without creating targeting opportunities?
In a centralized architecture, the vendor pays a cloud provider. In the Tide Cybersecurity Fabric, the ORKs are independently operated. They hold sensitive key shards and perform threshold computations for vendors and users they cannot identify. Defending against economic coercion requires a compensation model that satisfies five requirements simultaneously:
  • gate every operation (no computation without payment assurance),
  • preserve party anonymity (the billing system must not undermine the cryptographic privacy guarantees),
  • prevent fraud (no actor can generate free operations or replay tokens),
  • settle efficiently (real-time micropayments for millisecond operations are impractical), and
  • align incentives (honest nodes profit, malicious nodes suffer loses).
Tide solves this with the Anonymous Voucher - a compartmentalized, cryptographically signed micro-payment mechanism that flows through a strict four-actor model. This is the Settlement Layer, the fourth abstraction layer introduced in Article 2. It eliminates the economic attack surface while sustaining the decentralized architecture - without networked consensus requirements.
Loading diagram...

FIGURE 17: Settlement Layer High Level Flows

The Four-Actor Model

The Settlement Layer operates through strict compartmentalization. Four actors participate in every voucher transaction, each observing only the minimum information required for their role.
ActorRoleKnowsCannot Know
User Agent (Secure Web Enclave)Orchestrates the flow. Blinds ORK identities before requesting vouchers from the Vendor.Which ORKs are in the target swarm.The voucher's internal structure; cannot forge or manipulate vouchers.
TideCloakFunds the operation. Generates vouchers using its ephemeral payment key (VRK). Obfuscates its own organizational identity.Its own VRK, the requested action type.Which ORKs receive the vouchers (blinded by the SWE). The user's master identity.
ORK NodesService providers. Finalize the voucher, submit to a Payer for validation, then execute the cryptographic operation.That the voucher is funded and valid (confirmed by the Payer).The Vendor's organizational identity (obfuscated).
PayerClearinghouse. Validates voucher signatures, enforces credit balances and uniqueness, issues redemption proofs.The Vendor's ephemeral payment identity and an obfuscated derivative of the Vendor's organizational key.The Vendor's actual organizational identity. The ORKs' true identities. The User's identity.
No single actor learns the identity of any non-adjacent actor. The Vendor does not know which ORKs serve its users. The ORKs do not know which Vendor funds their work. The Payer can track billing without knowing the Vendor's true identity. The User is invisible to the economic layer entirely.

Phase 1: Credit Facility Setup and Licensing

Before any voucher can be issued, the Vendor must establish a funded credit facility. This occurs asynchronously, once per billing cycle, different facility each time.
The Vendor's TideCloak server generates an ephemeral Vendor Random Key (VRK) - not the organizational master key (VVK), but a payment-scoped key pair valid for a single monthly cycle. TideCloak registers this VRK with a Payer node, initially creating a provisional facility record. Financial settlement uses standard payment processors (e.g., Stripe): the Vendor completes a checkout flow, the Payer receives a webhook confirming the transaction, and the facility is activated with the corresponding credit.
During the VVK generation ceremony (Article 5), the VVK ORK swarm performs a semi-blind signature that links the ephemeral VRK to the organizational VVK. The Payer's facility record is then updated with an obfuscated derivative of the Vendor's organizational identity - sufficient for billing, but not reversible to the original VVK.
Every month, TideCloak generates a fresh anonymised VRK. The previous VRK expires and the new facility is registered and funded. This rotation limits the exposure window if a payment key is compromised, ensures accurate per-period accounting, and prevents the Payer from building a continuous behavioral profile across billing periods.

Phase 2: Per-Operation Voucher Allocation

Every time an ORK is asked to perform a computation - authentication, threshold decryption, or digital signature - a voucher transaction executes in milliseconds.
Loading diagram...

FIGURE 18: Voucher Issuance and Consumption Flow

The Secure Web Enclave (SWE) blinds the ORK swarm's public keys (BlurPORKi) before calling GetVouchers, so the Vendor cannot map its users to specific nodes. The Vendor generates a per-ORK VoucherPack using its funded VRK, obfuscates its own organizational identity as Y' (the triple-obfuscated vendor tag), and returns the packs alongside QPub, PayerPub, YHat, and UDeObf. Each ORK independently calls FinalizeVoucher to add its counter-signature (s2), obfuscates the User ID (UID'), queries the TWELVE-MAP directory to locate the Payer cluster, and submits the completed voucherFinal with QPub to one random Payer node from that cluster.
The Payer executes TestVoucher: deobfuscates the vendor identity to locate the facility record, validates the composite signature (s = s1 + s2), confirms the voucher nonce has not been submitted before, verifies the facility has sufficient credit within valid VRK dates, and checks the obfuscated User ID against the Vendor's MAU licensing limits. If all checks pass, the Payer debits the facility and returns redemptContent (action, timestamp, key, digest), redemptProof (Payer's signature), and obfgVVK (vendor identity for routing). If any check fails, the Payer returns a failure reason. No valid voucher, no computation.

Phase 3: Monthly Bulk Redemption

Real-time validation (Phase 2) ensures operations are authorized instantly. ORK operators receive financial compensation through a monthly batch process.
Throughout the month, each ORK archives its RedemptProofs, grouped by Payer cluster and action type. At the close of the billing cycle, the ORKs submit aggregated redemption lists to the Payer, accompanied by payment instructions signed with their obfuscated voucher key.
The Payer re-verifies every submitted voucher against its historical audit trail, approves valid redemptions, and processes a bulk payment transfer. Disputed vouchers trigger a forensic process: the ORK submits the full cryptographic proof chain for re-evaluation, which identifies the failure source - a rogue ORK forging signatures, a Vendor exceeding credit, or a Payer rejecting valid proofs. Following settlement, both parties purge the processed records.

Three-Identity Compartmentalization

The privacy guarantees rest on three independent blinding operations, each protecting a different identity from a different actor.
  1. SWE to Vendor blinding: The SWE transforms the ORK swarm's public keys before requesting payment. The Vendor funds vouchers without knowing which nodes receive them.
Loading diagram...
  1. Vendor to ORKs and Payer blinding: The Vendor obfuscates its organizational identity using its ephemeral VRK and the Payer's public key. The Payer can partially reverse the obfuscation to locate the facility record, but cannot strip the final layer to recover the actual VVK. The ORKs see only the opaque obfuscated value.
Loading diagram...
  1. ORK to Payer and Vendor blinding: Each ORK obfuscates the User ID before submitting the voucher. The Payer receives a consistently derived identifier sufficient for MAU counting, but cannot trace it to the user's master identity.
Loading diagram...
Each blind is independently reversible only by its intended recipient - enough for that actor to fulfill their role, no further.

The BYOiD Integration

A notable efficiency arises from how the Settlement Layer integrates with the authentication mechanics described in Article 4: BYOiD.
During BYOiD authentication, the ORKs evaluate a Threshold Oblivious Pseudorandom Function between the user's secret (CMK) and the Vendor secret (VVK) to establish the user's contextual identity. The obfuscated Vendor identity generated for the voucher serves double duty as exactly this Vendor secret contribution. When the ORK processes the request, it uses the voucher's obfuscated Vendor identity to compute its partial contribution. The SWE interpolates the partials and deobfuscates the result to recover the true user contextual identity.
This fusion means the per-ORK voucher validation and the BYOiD authentication execute within the same network call. The voucher allocation itself (SWE → TideCloak → SWE) is an additional round-trip preceding the sMPC flow, but the per-ORK validation introduces no extra latency to the threshold computation. For the full construction, see Protocol: Anonymous Voucher.

Privacy Properties

PropertyMechanism
Vendor cannot identify ORKsORK public keys blinded by SWE before voucher request.
Vendor cannot learn User Master IDVendor receives only the VUID (vendor-specific derivative); the user's CMK is computationally unreachable.
ORK cannot identify VendorVendor identity obfuscated within the voucher. ORK sees only the opaque value.
Payer cannot learn actual VVKPayer deobfuscates only to the facility ID level. Without the Vendor's ephemeral VRK scalar, the organizational key is irrecoverable.
No cross-vendor correlationUser IDs are derived uniquely per vendor context. No entity - including Tide - can correlate a user's activity across applications.
SWE cannot forge vouchersVouchers require the Vendor's VRK signature. The SWE routes but cannot fabricate payment authorization.
Vouchers are non-replayableThe Payer indexes every validated voucher nonce. Duplicate submissions are rejected.

Economic Security Model

ORKs are compensated per validated operation. Honest, available service produces validated vouchers and monthly payment settlement. Malicious behavior - forged partials, corrupted signatures - triggers two fail-safes: the SWE's zero-knowledge proof verification rejects invalid responses (the ORK never receives a finalized voucher), and the Payer rejects forged vouchers during validation. Malicious behavior produces zero revenue.
Vendors prepay for operational credit within a monthly billing cycle. The Payer tracks consumed credit via a per-action debit counter and enforces two independent licensing limits: a total account ceiling (MaxAccounts) and a rolling 30-day concurrent active user limit (MaxConcurrentAccountsPerMonth). If a Vendor exhausts either limit, the Payer rejects further vouchers for the gated action type. Monthly VRK rotation limits financial exposure from a compromised payment key.
Payers operate as a scrutinized node class responsible for clearinghouse functions and payment infrastructure. Their revenue derives from a transparent fee on settlement batches.
Users are invisible to the Settlement Layer. Authentication and data operations are funded by the Vendor's organizational credit. The user never pays a fee, manages a credit facility, or sacrifices anonymity to an infrastructure provider.

Anti-Fraud Mechanisms

MechanismWhat It Prevents
Voucher nonce indexingReplay attacks - no vendor voucher can be submitted twice.
Per-VRK balance enforcementResource exhaustion - a compromised Vendor cannot execute unlimited operations.
Obfuscated MAU trackingLicense violations - Payer enforces user caps without identifying users.
Forensic proof chainDisputed vouchers demand the full cryptographic chain, identifying rogue ORKs, Vendors, or Payers.
For a detailed analysis of collusion scenarios and their mitigations, see Article 9: Threat Model.

Further Reading

References