Tie resolves to a 50/50 split rather than the documented consumer-protection default
The specification describes a consumer-protection tie-break that refunds the buyer, but the tally resolves ties to a 50/50 split.
Description
docs/PROTOCOL_SPEC.md describes a consumer-protection tie-break: on tally deadlock, default to a buyer refund. ArbitrationPoolTallyLib.determineRuling (contracts/lib/ArbitrationPoolTallyLib.sol#L52-L61) returns a 50/50 split instead:
uint256 revealed = forBuyer + forSeller + forSplit;uint256 threshold = (revealed / 2) + 1;...return (ArbitrationPoolTypes.Resolution.Split, 5000, true); // tie
With the default revealQuorum of 2 (contracts/ArbitrationPool.sol#L172) on a three-juror panel, two jurors revealing on opposite sides while the third abstains gives revealed = 2 and threshold = 2. Neither side reaches it, so the ruling is Split at 5000 bps and a party who would have lost outright receives half the disputed amount.
The implemented behaviour is the defensible one and the specification sentence is stale rather than the code being wrong: defaulting a deadlock to the buyer would make deadlock worth half the disputed amount to a buyer who engineers one, which is the incentive docs/AUDIT_GATE.md DD-1 removed when it dropped a time-based 50/50. TiedRuling is emitted, so occurrences are observable on-chain. This is therefore a documentation correction, not a code change.
One operational coupling is worth recording alongside it. A tie requires a juror to miss reveal, and missed reveals are currently suppressed by relayer-side auto-reveal. Any change that has jurors reveal for themselves removes that suppression, so tie frequency — and therefore 50/50 rulings on disputes that have merit on one side — should be expected to rise.
Recommendation
Correct the tie-break sentence in docs/PROTOCOL_SPEC.md to record the 50/50 outcome and the reasoning behind it, so the specification and the contract agree. Model the expected tie rate before changing the reveal path, since the change removes what currently keeps ties rare.
Resolution
Fixed. The specification now records the deadlock behaviour and the reasoning behind it, and keeps the operational note that auto-reveal suppression is what currently keeps ties rare.
One correction while you are in there: the specification's mechanics note states that a tie returns (Split, 5000, wasTied), but the code now returns (None, 0, true). Both are sentinels and tally checks the deadlock flag before any settlement write, so there is no behavioural risk — the sentence is simply out of date with its own fix.