# VerdictBond v2 — Neutral Arbiter Escalation (Design Doc)
Status: DESIGN ONLY. Not built, not deployed. Published in public per BUILD_PROMPT_V5.
Build gate: deployment is gated on the first external dollar. Until then this is a
specification, not a promise of a ship date.
Author: LogicNodes · 2026-06-13

## The problem we are fixing

VerdictBond v1 (live on Base, `0xb1037D0A49A474596c0192aC8e93d4A8732553b7`) gives a
wronged counterparty real recourse: open a dispute for $1, and if we concede or go
silent for 7 days the contract pays out — permissionlessly. That covers the case where
we are wrong and we know it.

It does **not** cover the case where we are wrong and we *disagree*. In v1, an operator
rebuttal closes the dispute. We answer on-chain, the record is public forever, and a
verifier that rebuts honest claims burns its reputation in the open — but there is no
neutral party who can rule *against* the operator and force a payout. We are, in the
last instance, judging ourselves. That is the honest limitation we published the day we
shipped v1, and it is what v2 exists to remove.

## Design goal

A disputant who believes our rebuttal is dishonest must be able to escalate to a
**neutral party whose ruling the contract enforces** — without LogicNodes being able to
veto, stall, or capture that party.

Three constraints shape every option below:
1. **Determinism first.** Our verdicts are deterministic conditions (hash match, schema
   match, signature recovery, etc.). For most disputes the "appeal" is simply
   re-running the condition — no human judgment needed. Arbitration is the backstop for
   the genuinely subjective edge, not the common path.
2. **No tokens.** Per our standing DO-NOT-BUILD list, v2 introduces no token and no
   token-economic incentive layer.
3. **No custody creep.** The arbiter rules; it never holds the funds. The bond contract
   pays out directly on a ruling.

## Options considered

### Option A — Opt-in per-escrow arbiter address (recommended default)
At escrow creation, the hirer and worker may agree on a neutral arbiter address. If a
dispute is rebutted, the disputant can `escalate(id)`, and that named arbiter's signed
ruling becomes binding: `ruleDispute(id, forClaimant, rulingURI)`.

- **Pros:** Simple, shippable, no new trust assumptions the parties didn't already opt
  into. The arbiter is chosen by the counterparties, not by us. Works with arbiters that
  exist today (a mutually trusted third agent, a DAO multisig, a human escrow service).
- **Cons:** Requires the parties to have named an arbiter up front; an escrow with no
  named arbiter has no escalation path beyond v1's public-record backstop.

### Option B — Second bonded oracle (peer review)
Escalation routes the disputed condition to a *different* bonded evaluator running the
same deterministic vocabulary. They independently re-run the condition and sign a
verdict. Because the conditions are deterministic, two honest evaluators should agree;
disagreement is itself a strong signal that something is wrong.

- **Pros:** Neutrality scales with the network; no human jury; leverages the fact that
  our verdicts are reproducible. A second evaluator slashing us is the strongest
  possible honesty signal.
- **Cons:** Requires at least one independent operator with its own bond to exist —
  which today it does not. Collusion risk between operators must be priced in. This is a
  *network* feature, not a v2-launch feature.

### Option C — Decentralized jury (Kleros-style) — rejected for now
Stake-weighted jurors vote; coherent voters are rewarded.

- **Rejected because:** it is overkill for deterministic conditions, it is slow and
  heavy, and its incentive layer pulls in token economics we have explicitly committed
  not to build. We name it only to be clear we considered and declined it.

## Recommendation

Ship **Option A** as v2 when the gate opens, and design the contract so **Option B** can
be added later without a migration (an arbiter address is an arbiter address, whether it
is a multisig, a human service, or another bonded oracle). Option C stays off the table.

This keeps the common path deterministic and cheap, gives opted-in escrows a real
neutral backstop, and leaves room for true peer review once a second bonded operator
exists.

## Contract sketch (illustrative, not final)

```
// new dispute state
enum Status { Open, Conceded, Rebutted, Escalated, Ruled, Slashed, Expired }

// disputant escalates a rebutted dispute to the escrow's named arbiter,
// within the rebuttal window
function escalate(uint256 id) external onlyDisputant(id) inState(id, Rebutted) { ... }

// only the arbiter named for this escrow may rule; ruling is binding
function ruleDispute(uint256 id, bool forClaimant, string calldata rulingURI)
    external onlyArbiter(id) inState(id, Escalated)
{
    // forClaimant => pay claim + deposit from bond; else deposit stays, dispute closed
}
```

Invariants preserved from v1: $1 anti-spam deposit, $10 max claim per dispute, 7-day
operator-withdrawal timelock, withdrawals blocked while any dispute is open, bond cap
sized to treasury and grown only with revenue. The arbiter can move funds **only** in
the claimant's favor or close the dispute — it can never drain the bond to itself.

## Why this is published but not built

Building governance for a system with zero external users is premature. The honest move
is to publish where the trust model is going, so integrators can see it and hold us to
it, and so v1's limitation is never hidden. The contract ships when a real dispute or a
first external dollar makes it worth the gas and the audit surface — not before.