Auditing the Bilateral 5% Dispute Stake: Attack Vectors

TL;DR

• A bilateral dispute stake charges both sides 5% of the disputed milestone, so filing a bad-faith claim costs the filer real money, not just the defendant.
• Using only the disclosed 5% stake and 30/70 payout split, this piece derives a breakeven win probability of roughly 71% below which a rational bad-faith filer loses money on average.
• Symmetric bonding closes the specific rational-griefer failure mode that a published game-theoretic study found in a one-sided bonded penalty design.
• Collusion and juror-bribery remain live risks; the stake raises their cost floor, it does not remove it.
• A technical evaluator can re-derive every number here from the 5%, 30%, and 70% parameters alone, without trusting a single platform-reported statistic.

A bilateral dispute stake is economically secure when the expected value of filing or defending a bad-faith claim is negative for a rational actor, not merely when the stake feels large. Using only the disclosed 5% stake and 30/70 split, this piece derives a roughly 71% breakeven win probability below which filing in bad faith is a losing bet.

Most public writing about staked dispute mechanisms describes what the stake is, not what a rational adversary can still do to it. Reputation systems, payment channels, and validator sets all use a bond to raise the cost of bad behavior, and a security researcher evaluating any of them needs the same three questions answered: what does an attacker actually gain, what is the smallest bond that still deters them, and where does symmetric bonding fail to close a gap that a one-sided bond leaves open. This piece answers those questions for a bilateral, percentage-of-milestone dispute stake using only FiduWork's disclosed parameters and independently published mechanism-design research, treating every derived number as original analysis rather than a platform-reported fact.

What problem does a bilateral dispute stake actually solve?

A bilateral dispute stake solves the problem that a free-to-file dispute process has 0 cost for the filer, which makes stalling and bad-faith claims rational even when the case is weak. Charging both sides 5% of the milestone converts a costless accusation into a priced wager, the same two-sided reporting logic behind a published mechanism where attaching any fine to a false claim makes truth-telling each claimant's weakly dominant strategy (arxiv.org/pdf/2202.10950).

A one-sided bond, where only the party being accused posts money, still leaves the accuser's side of the ledger at zero cost. That asymmetry is exactly what a griefing attacker exploits: file cheap, force the other side to defend at real cost, and repeat regardless of the case's merit. A bilateral design removes the free option on both sides of the table at once, which is a structurally different guarantee than "the stake is large" or "the stake is disclosed."

Why symmetry, not size, is the load-bearing property

The commonly cited number for this design is 5%, but the property doing the actual work is that both the challenger and the challenged post the same percentage before either side knows how the panel will rule. A stake that only one side pays can still be economically rational to abuse, however large it is, because the abusing side never risks it. A stake that both sides pay changes the sign of the abuser's expected value, which is the condition this piece derives below rather than assumes.

How does the stake move through the escrow and juror panel on-chain?

A plausible, unconfirmed model of the flow: the stake moves as two separate USDC transfers, the same programmable stablecoin rail Circle documents for on-chain settlement (Circle developer docs), into a pool that settles once after the 72-hour window closes, with both legs traceable on Sepolia. The exact transfer and settlement structure is not itself a disclosed Phase-0 fact and should be confirmed against the deployed contract.

Protocol mechanics: roles, states, and on-chain events

Three wallet roles participate in a staked dispute: the client, the freelancer, and the juror set drawn for that specific case. Everything below beyond the disclosed 5% stake, 3/5/7 panel, 72-hour window, and 30/70 split is a conceptual illustration of how those parameters could plausibly compose into a flow, not a confirmed FiduWork state machine, balance structure, or sequencing; the exact states, event names, function selectors, and default rules live in the deployed contract source and should be read from there before being quoted as guarantees. What is documented publicly is only the shape of the flow: funding, staking, a 72-hour vote, and settlement.

Escrow contract walkthrough: deposit, stake, vote, settle (illustrative sequence, not confirmed FiduWork architecture)

Deposit. The client funds the milestone in USDC, the balance the dispute is fought over.

Contest. Either party disputes the milestone before or after a confirmation attempt, opening a plausible staking window.

Stake. Both the client and the freelancer post 5% of the disputed milestone, the disclosed bilateral parameter this piece analyzes.

Vote. A panel of 3, 5, or 7 jurors is drawn and votes inside the disclosed fixed 72-hour window on an Aragon OSx voting plugin instance. The Aragon OSx 1.x plugin architecture documents plugin actions as requiring the EXECUTE_PERMISSION_ID permission, with calls carrying the auth modifier authorized through the DAO's permission manager rather than a bare admin key (Aragon OSx 1.x plugin docs); whether FiduWork's specific deployment follows that standard OSx permission pattern unmodified is not independently confirmed by Phase-0 disclosed facts and should be checked against the deployed instance.

Settle. The disclosed split pays 30% to the jurors who voted and 70% to the side the panel ruled for.

An illustrative dispute-pool pattern (not FiduWork's deployed code)

The exact struct and event layout FiduWork's deployed dispute contract uses is not publicly disclosed beyond the mechanics above, so treat the block below as a conceptual pattern only, not as FiduWork's actual source.

// ILLUSTRATIVE DESIGN PATTERN ONLY. No compiler version implied.
// Not FiduWork's deployed contract code; conceptual pseudocode only.
// pragma solidity ^0.8.x; (illustrative target range, not a confirmed version)
struct DisputeStake {
    bytes32 milestoneId;   // ties the pool to one escrow milestone
    address challenger;    // wallet that opened the dispute
    address respondent;    // wallet defending the milestone
    uint256 challengerBond; // 5% of milestone value
    uint256 respondentBond; // 5% of milestone value
    uint8   status;        // 0 open, 1 staked, 2 voted, 3 settled
}

event DisputeStaked(bytes32 indexed milestoneId, uint256 challengerBond, uint256 respondentBond);
event DisputeSettled(bytes32 indexed milestoneId, address indexed winner, uint256 jurorShare);

Why size the stake at a percentage of the milestone instead of a flat fee?

A percentage stake scales the deterrent with the value at risk, so a $500 dispute and a $50,000 dispute both cost each side the same proportional 5%, keeping the incentive to file frivolously roughly constant across sizes. A published two-sided reporting mechanism instead uses a fine that can be arbitrarily small and still yield truthful revelation (Solomonic dispute mechanism, arxiv.org); a percentage stake trades that property for deterrence that tracks disputed value. A flat fee would over-deter small disputes.

Deriving the breakeven win probability from the disclosed parameters

Take a disputed milestone of value M. Each side posts a stake of 0.05M, for a combined pool of 0.10M. The settlement splits 30% of that pool, 0.03M, to the jurors, leaving 0.07M for the winning side. A winner recovers more than their own 0.05M stake, netting a gain of 0.02M on the stake itself; a loser forfeits the full 0.05M. For a rational actor filing a claim they know is weak, the expected value of that gamble is p(0.02M) - (1-p)(0.05M), where p is their true probability of winning. Setting that expression to zero and solving gives p = 0.05 / 0.07, or roughly 71.4%. Below that win probability, filing a bad-faith dispute is a losing bet in expectation, purely on the stake mechanics, before counting the time cost of a 72-hour wait or any dispute-history reputational effect. This is a derived result from the 5% and 30/70 parameters, not a disclosed platform statistic, and it holds regardless of panel size since the pool split does not vary with the number of jurors on the disclosed facts.

What is a griefing attack against this stake, and does the design resist it?

A griefing attack succeeds when an attacker can impose a cost on a victim without bearing a matching cost themselves, and the closest published analogue is a payment-channel penalty scheme found to hold under honest-or-malicious assumptions but fail once participants are modeled as rational: a griefing-penalty countermeasure for Lightning Network HTLCs was shown to work against honest or malicious actors but fail against rational ones (arxiv.org/pdf/2203.10533).

Why the rational-griefer failure mode from payment channels does not transfer directly

The HTLC finding matters here because it is a cautionary result about bonded-penalty designs in general, not because the two systems are the same. In the Lightning Network case, the griefing attacker locks up a victim's capital and can walk away paying only a small, separately-priced penalty, so a rational attacker can still profit if the penalty rate is set too low relative to the damage inflicted on the other side. A bilateral dispute stake changes the shape of that asymmetry: filing itself, not just losing, requires posting 5% of the milestone. An attacker cannot force a review cycle onto the other party for free, which is precisely the gap a rational griefer exploits in a design where only the victim's funds, not the attacker's own capital, are locked. The mitigation is structural rather than a matter of tuning a single penalty rate: both sides paying the same percentage removes the free half of the attack.

Where griefing pressure still exists

A bilateral stake does not make stalling free, but it does not make it impossible either. A party willing to lose 5% purely to delay a competitor's cash flow, or to force a counterparty into a 72-hour wait for reasons unrelated to the merits of the case, can still do so once, and the design's only defense against repeat abuse is whatever pattern-level monitoring sits above the base contract, which is outside the Phase-0 disclosed mechanics and should be confirmed against the deployed system rather than assumed.

Can the two disputing parties collude against the jurors, or can jurors collude against them?

Two parties who trust each other can stage a dispute to move funds through the panel, and jurors can be bribed, both of which the stake raises the cost of without eliminating. A published payoff model shows even an arbitrarily small fine on a false report can make honesty weakly dominant for a single accused party (fine-based payoff analysis, arxiv.org); a 3, 5, or 7-seat panel adds a collusion layer that result alone does not cover.

Disputant collusion: staged disputes as a laundering path

If a client and a freelancer already control both wallets, or coordinate off-chain, they can fund a real milestone, stage a dispute over it, and let the panel's 70/30 split move money between them under the appearance of an adjudicated outcome. The bilateral stake does not stop this pattern; it only guarantees that 30% of whatever the two colluding parties put into the pool leaves their control permanently, since that share always goes to the jurors regardless of who wins. That fixed leakage is a real cost, and it scales with the size of the staged dispute, but it does not scale to zero-tolerance the way an escrow-gated attestation design does for a similar self-dealing pattern in reputation scoring, covered in the companion piece on wash-rating and reputation attack vectors.

Juror bribery: the cost floor scales with panel size

Bribing a panel to rule a specific way means paying enough jurors to control the vote, and the disclosed 3, 5, or 7 seat sizing sets the number of individuals a briber has to reach: a majority of 3 requires 2 votes, a majority of 5 requires 3, and a majority of 7 requires 4. Splitting the 30% juror share across more seats lowers each individual juror's take from an honest ruling, which in isolation could weaken the incentive to vote carefully, but it simultaneously raises the number of separate people a briber has to corrupt without detection, which is the trade-off a panel-size choice is actually making. A revelation mechanism built on staking can, under the right incentive design, produce a unique equilibrium where the honest strategy is also the profit-maximizing one for participants who hold a stake in the outcome (arxiv.org/abs/2206.10065); whether FiduWork's specific juror-selection and reward function achieves that property for this exact panel size and pool split is a question for the deployed contract, not something this piece can confirm from disclosed facts alone.

What is the free-rider problem in the juror pool, and how does the 30% share address it?

The free-rider problem is that a juror who skips diligent review and votes with the apparent consensus still collects a share of the fixed 30% pool if that guess matches the outcome, which weakens the incentive to actually read the evidence. A staking-based revelation mechanism can align individual and group incentives toward truthful reporting under the right design (staking revelation mechanism, arxiv.org), but splitting one fixed share across 3, 5, or 7 seats thins the reward for real diligence either way.

Why this is not fully solved by disclosed facts alone

Larger panels raise the bribery cost floor, as shown above, but they also thin out the per-juror payoff for genuine diligence, a tension the disclosed 3/5/7 sizing does not resolve on its own. Whether FiduWork's deployed contract adds any diligence-specific incentive, penalizing jurors whose votes are consistently a minority outlier, for instance, sits outside the Phase-0 disclosed mechanics. An evaluator should treat the free-rider question as open and confirm it against the deployed juror-selection and reward logic rather than assume the 30% split alone fully solves it, the same caution applied throughout this piece to any claim beyond the disclosed parameters.

How does a bilateral percentage stake compare with a free-to-file process and a one-sided bond?

Lining up 3 designs side by side shows why symmetry matters more than size: a free-to-file process costs 0 to abuse, a one-sided bond deters only 1 party, and a bilateral 5% stake prices both sides of the same accusation, closing the specific rational-griefer gap documented in bonded payment-channel research (HTLC griefing-penalty finding, arxiv.org).

• Cost to file a bad-faith claim · Free-to-file dispute: 0 · One-sided bond (respondent only): 0 for the filer · Bilateral 5% stake: 5% of the disputed milestone
• Cost to defend a bad-faith claim · Free-to-file dispute: Full value of the milestone at risk · One-sided bond (respondent only): 5%+ of milestone as a bond · Bilateral 5% stake: 5% of the disputed milestone
• Rational-griefer exposure · Free-to-file dispute: High, filing is free · One-sided bond (respondent only): Asymmetric, only the respondent is deterred · Bilateral 5% stake: Structurally reduced on both sides ([arxiv.org/pdf/2203.10533](https://arxiv.org/pdf/2203.10533))
• Breakeven win probability to file in bad faith · Free-to-file dispute: 0%, filing never costs the filer · One-sided bond (respondent only): Undefined for the filer, who risks nothing · Bilateral 5% stake: Roughly 71%, derived above from the 30/70 split
• Juror bribery cost floor · Free-to-file dispute: No juror layer exists · One-sided bond (respondent only): No juror layer exists · Bilateral 5% stake: Scales with panel size, 2 of 3, 3 of 5, or 4 of 7 votes

Platform Signal. On the Sepolia beta, a disputed milestone routes to an Aragon-OSx panel of 3, 5, or 7 jurors inside a 72-hour vote window. Both sides post a 5% USDC stake, and the outcome settles 30% to the jurors who ruled and 70% to the winning side, the exact structure this piece audits from an attacker's perspective rather than a defender's.

Compliance corner. A stake-and-slash dispute mechanism moves USDC between two private parties and a rotating juror set, not between a regulated provider and a retail customer in a custodial sense, but any platform layering new settlement technology onto a payment-adjacent flow should still weigh it against the same lens regulators apply to new technologies in virtual-asset services. FATF Recommendation 15 addresses how jurisdictions apply anti-money-laundering obligations to virtual asset service providers as they adopt new technologies, including for transaction monitoring (FATF). A non-custodial dispute-stake pool that only ever moves value between the milestone's own two counterparties and a juror set, without ever pooling third-party customer funds, generally sits outside VASP scope, but a platform should keep the mechanism scoped to those two roles rather than let it drift into a broader payment-services function.

Where to go next on FiduWork

Go deeper on the juror-selection state machine, quorum rules, and slashing conditions in the Aragon-OSx juror panel deep dive, and read the freelancer-facing worked example of the defend-or-settle decision in 5% Freelancer Stake: Why Skin-in-the-Game Gigs Pay More. The companion piece on wash-rating and Sybil attack resistance covers the reputation-layer attack surface this piece deliberately left out. Full technical detail lives in the protocol documentation.

Audit Our Escrow Architecture. Read the dispute-pool contract source before trusting any breakeven number in this piece, including the 71% threshold derived above. Open the app.

Sources

1. Strategic Analysis of Griefing Attack in Lightning Network, arxiv.org
2. A Solomonic Solution to Ownership Disputes: An Application to Blockchain Front-Running, arxiv.org
3. Mechanism Design Approaches to Blockchain Consensus, arxiv.org
4. OpenZeppelin Security Audits Archive
5. Trail of Bits Public Audit Reports Repository, github.com
6. Immunefi Reports on Crypto Exploit Losses
7. Aragon OSx Plugin Architecture Documentation
8. Chainalysis, Crypto Market Manipulation: Wash Trading and Pump-and-Dump 2025
9. Circle USDC Developer Documentation

Update Log

• 2026-09-16: Published.