Private Oracle Voting with ZK Proofs Explained

The Problem with Transparent Voting

In any system where multiple parties vote on an outcome, transparency during the voting process creates perverse incentives. If oracle A can see how oracle B voted before submitting their own vote, they might copy that vote rather than performing their own independent assessment. This "herding" behavior undermines the entire purpose of having multiple independent evaluators and reduces the oracle panel to a follow-the-leader dynamic.

KAMIYO solves this with a two-phase commit-reveal scheme. Oracles commit a SHA-256 hash of their vote during the commit phase, then reveal the actual score and salt after the commit window closes. The result is a voting system where each oracle is cryptographically guaranteed to vote independently, and no oracle can see any other oracle's vote until the reveal phase begins.

Commit-Reveal Mechanics

The commit-reveal scheme operates in two distinct phases, each enforced by the on-chain program's state machine. Attempting to reveal before the commit window closes, or committing after it closes, results in a rejected transaction.

Phase 1: Commit

During the commit phase, each oracle evaluates the deliverable or dispute evidence independently. They form their vote — approve, reject, or a quality score on a defined scale — and then compute a commitment. The commitment is a cryptographic hash of the vote concatenated with a random nonce (salt):

// commitment = SHA-256(transaction_id || score || salt)
const score = 85; // quality score 0-100
const salt = randomBytes(32);
const commitment = sha256(Buffer.concat([
  Buffer.from(transactionId),
  Buffer.from([score]),
  salt,
]));

// Submit commitment on-chain (5-minute commit window)
await program.methods.commitOracleScore(commitment).rpc();

The commitment is stored on-chain. Because the hash is one-way, no one — including other oracles, the payer, or the payee — can determine the vote from the commitment alone. The salt ensures that even identical votes produce different commitments, preventing statistical analysis.

Phase 2: Reveal

After the commit window expires, the reveal phase begins. Each oracle submits their original vote and salt. The program recomputes the hash and verifies it matches the stored commitment. If the hash matches, the vote is recorded. If it does not match (the oracle tried to change their vote), the transaction is rejected and the oracle's stake is subject to slashing.

// Reveal the score and salt (after 5-minute delay)
await program.methods.submitOracleScore(score, salt).rpc();

// The program verifies: SHA-256(tx_id || score || salt) === stored_commitment
// If valid, the score is recorded
// If invalid, the reveal is rejected

Zero-Knowledge Proof Integration

KAMIYO's codebase includes a dual ZK system designed to strengthen the oracle voting flow. Halo2 circuits (no trusted setup required) handle commitment hiding via Poseidon hashes, while Groth16 circuits provide on-chain verification using Solana's alt_bn128 precompiles.

Currently, Groth16 proofs are active for reputation tier verification and agent reputation proofs — allowing agents to prove they meet trust thresholds without revealing their exact score. The oracle vote ZK circuits are implemented and tested but not yet activated in the voting flow, where the commit-reveal scheme with SHA-256 provides the primary anti-collusion guarantees. The ZK infrastructure is designed to be activated through governance when the oracle network scales to a size where additional privacy guarantees become necessary.

• Reputation Proofs (Active): Agents can prove their reputation exceeds a threshold without revealing the exact score, using Groth16 proofs verified on-chain.
• Oracle Vote Circuits (Implemented): Halo2 circuits verify that a commitment encodes a valid score within the allowed range [0–100] without revealing the score itself.
• Commitment Binding: ZK proofs can verify the commitment is correctly computed as the Poseidon hash of the score and salt, preventing garbage commitments.

The current commit-reveal scheme handles strategic non-revelation through slashing: oracles who commit but fail to reveal within the 30-minute reveal window are slashed 10% of their staked amount.

Consensus and Tallying

After all reveals are submitted (or the reveal window expires), the program tallies the votes. Consensus is determined by a configurable threshold — typically a simple majority, but governance can adjust this per use case. Votes can optionally be stake-weighted, giving oracles with more at stake proportionally more influence.

The tallying algorithm handles several edge cases. If an oracle commits but fails to reveal within the window, their vote is excluded from the tally and their stake is partially slashed. If the total valid votes fall below a quorum threshold, the voting session is marked as failed and a new panel can be assembled.

Outcome Execution

The voting outcome is written to the session PDA and can be consumed by other programs via CPI (cross-program invocation). The escrow program reads the voting result to determine whether to release funds to the payee, refund the payer, or split funds according to a partial-quality assessment. This composability is what makes the voting system useful beyond just dispute resolution — it can drive any on-chain decision that requires decentralized consensus.

Oracle Selection and Incentives

Oracle participation in KAMIYO is permissionless. Any registered oracle who meets the minimum stake requirement can participate in dispute resolution — there is no pre-selection or panel assignment. The required number of oracles scales with escrow value: 3 oracles for escrows under 10 SOL, 4 for 10–100 SOL, and 5 for escrows above 100 SOL. A quorum of at least 50% of registered oracles must participate for consensus to be valid.

Oracles earn 1% of the escrowed amount as a reward pool, split among participants who vote within the consensus deviation threshold. Oracles whose scores deviate more than the configurable max_score_deviation from the median receive no reward and are slashed 10% of their stake. After 3 violations, an oracle is automatically removed from the registry.

Performance on Solana

The commit-reveal cycle is optimized for Solana's transaction model. Commits and reveals are single-instruction transactions that finalize in under 500 milliseconds. The commit window is 5 minutes, followed by a 5-minute delay and a 30-minute reveal window. A typical dispute resolution — from first commit to finalization — completes in under 40 minutes, enabling near-real-time dispute resolution that traditional arbitration systems cannot match.

Applications Beyond Dispute Resolution

While dispute resolution is the primary consumer of the voting program, the commit-reveal mechanism is general-purpose. Other applications include quality scoring for AI agent outputs (where oracles rate deliverables on a numeric scale), parameter updates via governance votes, and oracle-driven data feeds where multiple independent sources commit observations before revealing them. The ZK proof integration ensures that all of these applications benefit from the same anti-collusion guarantees as dispute resolution voting.