Multiparty Protocol

Overview

The multiparty protocol enables entities on Axiomatic to interact with each other for intercompany reconciliation, bilateral audits, and settlement — all backed by zero-knowledge proofs and optional onchain anchoring. Each entity remains fully isolated with its own encrypted database, but can participate in multiparty workflows without revealing private financial data.

Entity Discovery

Entities can discover other entities available for bilateral interaction. Discovery returns each entity's capabilities so both sides can negotiate a compatible protocol version before exchanging data.

Capabilities

Each entity advertises its supported features:

Capability Negotiation

Before two entities interact, the protocol negotiates mutually supported features — computing the intersection of both entities' capabilities. This determines which protocol version, schema version, proof types, and settlement modes are available for the interaction.

Onchain Governance Registry

Entities can register onchain via the GovernanceRegistry contract on Base. Registration creates a permanent, verifiable record that an entity exists and is active within the Axiomatic network.

The governance registry supports:

• Entity registration — register an entity with its type and metadata URI
• Proof policies — declare which proof types are required for each entity (period close, solvency, NAV, waterfall, settlement, IC reconciliation)
• Verification key registration — publish verification keys so anyone can verify proofs without trusting the prover
• Active status checks — verify whether an entity is active in the registry

Intercompany Reconciliation

When two entities have intercompany balances (e.g., entity A has an intercompany receivable and entity B has a corresponding payable), the IC reconciliation flow verifies that both balances match — without either party revealing their actual balance to the other.

How It Works

1. Each entity's intercompany balance is computed from their respective ledgers
2. Both balances are committed using Poseidon commitments with random blinding factors
3. The ZK circuit verifies that the two committed values are equal
4. The proof is generated and stored, recording whether the balances matched and any variance

The result is a cryptographic attestation that intercompany balances reconcile, without either entity needing to share its actual balance.

Via the API

POST /api/proofs
{
  "action": "generate",
  "entityId": "entity-a-id",
  "bookId": "entity-a-book-id",
  "type": "IC_RECONCILIATION",
  "counterpartyEntityId": "entity-b-id",
  "counterpartyBookId": "entity-b-book-id"
}

Bilateral Audit

A bilateral audit verifies the relationship between two entities by checking all relevant proofs across both sides. The audit examines:

The audit returns an overallVerified flag that is true only when all components pass: IC balances match, both entities have valid period close proofs, and proofs have been independently verified.

Canonical Settlements

A canonical settlement is a normalized record of any value transfer between entities, regardless of its source. Settlements provide a single, unified view of cross-entity activity.

Settlement Sources

Settlement Flow

1. A settlement is recorded with its source, direction (inbound/outbound), amount, currency, and counterparty
2. The settlement is linked to the originating event in the ledger (if applicable)
3. A ZK proof can be attached to the settlement for cryptographic attestation
4. Optionally, the settlement is anchored onchain with a transaction hash

Settlements are idempotent — duplicate records with the same source type and source ID are silently ignored.

Direction Inference

The system automatically infers settlement direction from the event type:

• Inbound: crypto_received, investment_received, capital_contribution, invoice_payment, fee_settlement
• Outbound: crypto_sent, distribution_paid, capital_call_issued, bill_payment, gas_expense

Network Audit

A network audit extends bilateral verification to the full entity network. For any pair of entities, the audit checks:

1. Both entities' period close proofs are valid
2. The IC reconciliation proof confirms matching balances
3. If the entities share a common parent, the consolidation proof covers both subsidiaries
4. Onchain registration status for both entities

This creates a trustless verification layer where any participant — or external auditor — can verify the financial integrity of cross-entity relationships without accessing the underlying encrypted data.

Privacy Model