Aragon-OSx Juror Panels for On-Chain Freelance Disputes

TL;DR

• FiduWork routes freelance disputes to Aragon-OSx juror panels of 3, 5, or 7 members drawn from a staked pool.
• Voting runs on-chain for a fixed 72 hour window using an Aragon-OSx MajorityVoting plugin instance.
• Both parties post a 5% USDC stake; the settlement pays 30% of the pooled stake to jurors and 70% to the winning side.
• Every action is a signed transaction, so the full dispute trail is a verifiable event log rather than a support ticket thread.

Traditional freelance platforms resolve disputes through opaque support queues. FiduWork moves the resolution into a DAO framework so evidence, votes, and payouts share one auditable trail. The mechanism sits on top of Aragon-OSx, the modular DAO stack that separates governance logic into plugins around a permission-managed core, as described in the Aragon documentation.

This deep dive covers the panel state machine, juror selection, voting window mechanics, stake economics, failure modes, and how the design compares to alternative arbitration systems. It is written for engineers, auditors, and platform evaluators who need enough substance to judge the trade-offs before recommending the system for real budget.

What is an Aragon-OSx panel and how does it settle disputes?

An Aragon-OSx panel is a DAO instance whose only role is to vote on a single freelance dispute. Panels use the Aragon-OSx framework modular plugin model, which lets one DAO run governance through pluggable voting logic. FiduWork spawns 1 panel per open dispute with 3, 5, or 7 seats depending on escrow value, then destroys it after settlement.

Roles the panel contract knows

• Client wallet: posted the escrow and disputes a milestone.
• Freelancer wallet: submitted the deliverable and contests the client's veto.
• Juror wallets: selected from the staked pool for this specific case.
• Escrow contract: the on-chain contract holding the disputed USDC milestone.

States a panel moves through

The panel follows a linear lifecycle: it is created after a milestone is disputed on the escrow, the juror roster is drawn, voting opens for the 72 hour window, the tally is computed after the deadline, and the escrow reads the ruling and moves USDC. Every step is expected to emit an event so an external observer can reconstruct the case without querying a platform database. The exact event names, function selectors, and state labels should be read from the deployed contract source rather than trusted from prose.

That event-driven observability property mirrors the auditability guarantee described in the Ethereum whitepaper: state is public, transitions are signed, and anyone can replay the sequence.

How are jurors selected for a dispute?

Juror selection draws 3, 5, or 7 wallets from a staked juror pool for each dispute. Panel size is chosen at dispute open. The exact size rule and the on-chain randomness source are configured in the deployed contract; readers should verify the current parameters against the Sepolia deployment rather than treating them as fixed forever. Aragon's permission-managed governance model is what makes the selection call gated to the escrow contract in the first place.

Eligibility filters applied before the draw

A juror pool typically filters candidates before drawing a panel. Common filter categories include: a staked bond on the juror wallet, absence of recent counterparty overlap with either side of the dispute, some minimum track record inside the pool, and no active seat on another open panel. The exact thresholds are set in the deployed contract and should be read from source before any evaluator quotes them as guarantees.

Why an odd panel size

Odd sizes rule out ties in a binary ruling. Small seat counts keep coordination cost per case low. Larger seat counts give the system Schelling-point resistance under adversarial pressure, an approach explored in the wider literature on decentralized crowd-sourced adjudication. The 3, 5, or 7 seat sizing is a public product parameter; the mapping of size to dispute value is a deploy-time choice.

Anti-Sybil at the pool level

Juror participation is expected to be tied to a DID-anchored verifiable credential so that a single human identity cannot spam the pool with fresh wallets. The DID and reputation binding is discussed in the wider FiduWork escrow architecture deep dive. The exact credential schema and verification flow are contract-side details the evaluator should confirm before signing off.

How does the 72-hour voting window operate on-chain?

Voting runs on an Aragon-OSx majority-voting plugin instance configured for a fixed 72 hour duration. Each juror wallet gets 1 vote, cast as a signed on-chain transaction. The Aragon-OSx plugin architecture is the framework layer that enforces the voting window contract-side, so the deadline is not something the platform can override off-chain.

Vote options

The vote itself is a ruling on the disputed milestone: release funds to the freelancer, or refund the client. Whether the plugin instance also accepts an abstain option, and how abstention interacts with juror payout, is a deploy-time configuration on the plugin. Read the deployed instance rather than assuming a fixed option set.

What happens if quorum fails

Aragon-OSx voting plugins carry a configurable quorum threshold. If not enough of the panel votes inside the 72 hour window, the plugin does not tally a ruling and the escrow needs a documented fallback path. The exact quorum number, the re-draw policy, and any governance escalation route are contract-side parameters that an evaluator should read from source before quoting to a stakeholder.

Evidence handling during the window

Evidence is expected to live off-chain and be referenced from the on-chain panel by a content hash so the chain footprint stays small while the evidence itself stays verifiable. IPFS and similar content-addressed stores are common vehicles for this pattern. The exact evidence-submission flow, storage backend, and hash format are product-side choices to confirm against the deployed system, following the general logic for verifiable off-chain data described in the Ethereum whitepaper.

Gas budget per vote

A juror vote is a lightweight state transition: 1 signed transaction per juror per case. On Sepolia this cost is negligible; on any mainnet promotion the total gas cost per dispute stays bounded by the panel size, because the plugin only records a small counter and event per vote rather than persisting per-vote metadata. How gas is ultimately reimbursed to jurors is a payout-policy detail on the platform side.

Deadline handling and time source

Aragon-OSx voting plugins expose a start and end timestamp at instantiation, so any third-party observer can independently compute when the panel closes without querying the platform. Whether the plugin variant chosen for FiduWork uses block timestamps, block numbers, or an alternate source is a deploy-time configuration to verify against the deployed contract.

What jurors see on their side

Jurors read the panel address, the escrow reference, and the evidence hash from chain data, pull the evidence off-chain, review, and sign a vote. There is no shared workspace and no cross-juror chat surface exposed to attackers. Silence between jurors is a feature, since it protects Schelling-point convergence, which requires jurors to guess the focal point rather than negotiate to it.

Why require a 5% USDC stake from both parties?

The 5% stake is a bilateral filter against frivolous disputes. Both parties lock 5% of the disputed milestone in USDC before the panel is drawn. That pooled 10% becomes the settlement pot, distributed 30% to jurors and 70% to the winning side, using the on-chain accounting pattern documented for stablecoin flows by Circle's USDC developer docs.

Why 5% and not a flat fee

A percentage stake scales the cost of raising a dispute with the value at risk. Small milestones get cheap access to arbitration. Large milestones automatically raise the bar so a losing party cannot use disputes as a delay tactic without material cost.

Why 30% to jurors, 70% to the winner

The 30% share compensates jurors for the time, gas, and coordination effort of reading evidence and voting. Splitting it across 3, 5, or 7 seats keeps per-juror rewards modest, which raises the bribery bar because a would-be briber has to beat every seat, not just one. The 70% winner share offsets the friction the honest party absorbs proving the case, an incentive shape common to Schelling-scheme designs across decentralized jury systems.

Slashing conditions

A stake-and-slash Schelling scheme is the standard pattern for on-chain juror systems: minority voters against a coherent case forfeit some portion of their bond, and honest jurors converge on the focal point. Where the slashed value goes, and how repeated slashing affects pool eligibility, are contract-side parameters to read from source. What the platform commits to publicly is the 5% bilateral stake and the 30/70 split; anything more specific about the slashing math belongs in the deployed contract, not in a blog post. Isolating that logic from any platform admin surface is the OpenZeppelin security audit corpus style of design worth confirming on review.

What are the failure modes and how does the design mitigate them?

Every dispute system faces adversarial jurors, low turnout, and coordinated attacks. FiduWork mitigates these with quorum requirements, stake slashing, odd panel sizes, and the option to escalate to a governance vote. Crypto exploit losses tracked by Immunefi's reports crossed the $1.7B mark in 2025 year-to-date across the wider DeFi surface, which is the baseline scale of adversarial creativity any on-chain dispute system must plan for.

Sybil attacks on the juror pool

Attacker spins up many wallets to game the draw. Standard mitigation categories are DID-anchored credentials, a track-record requirement inside the pool, and a real capital lock per juror seat. The strength of each of those depends on the specific thresholds set contract-side, which is why an evaluator should read those values from the deployed juror-pool contract rather than trusting a summary.

Bribery of a live panel

Attacker tries to buy a majority of seats on a small panel. The general defense is that a briber must beat both the juror's expected settlement share and the loss from slashing on every seat, and both terms grow with the value at stake because the stake is a percentage of the milestone. On a small milestone the absolute defense is small; the 3-seat option exists for cases where that trade-off is acceptable.

Coordinated abstention

Attacker convinces jurors to no-show and force a quorum failure. The general defense is a payout structure that penalises abstention and a re-draw or governance escalation route on quorum failure. Whether the escalation path is a re-draw, a size increase, or a governance-only fallback is a product decision to confirm against the deployed system.

Contract-level bugs

Dispute logic itself is a smart contract. Mitigation path: independent audits before mainnet promotion, following the review discipline documented across Trail of Bits' public audit reports and the OpenZeppelin security audit archive. Sepolia beta status exists precisely so mechanism issues surface before real value is at risk.

Front-running the vote tally

An attacker could try to observe pending vote transactions in the mempool and time a settlement to favor a specific outcome. General defense: the tally is a pure function of on-chain state read after the deadline, and settlement should be callable by any wallet, not just the parties, so timing the settlement transaction has no value once the deadline passes.

Panel wallet compromise mid-vote

If a juror wallet is compromised while the panel is open, the attacker can cast that wallet's single vote. Blast radius is capped at 1 seat per compromise, and a compromised seat rarely swings a 5 or 7 member majority. On 3 seat panels the smaller size is a conscious trade-off for lower-value milestones.

Chain congestion delaying settlement

Congestion can push a settlement call several blocks past the deadline. Mitigation: settlement is idempotent and stateless with respect to timing beyond the deadline check, so late execution still produces the same payout, following the deterministic execution property described in the Ethereum whitepaper.

How do FiduWork panels compare to alternative dispute mechanisms?

FiduWork's design sits in a specific corner of the design space: task-scoped panels, small odd sizes, short window, bilateral stake. That combination differs from platform arbitration, single-arbitrator escrow, and large-panel decentralized courts, all of which trade time-to-ruling for depth of appeal. The trade-offs matter for anyone budgeting for arbitration cost or predictability.

• Ruling body · Web2 Platform Arbitration: Platform employee · Single-Arbitrator Escrow: 1 chosen arbitrator · Large On-Chain Court: Hundreds of jurors · FiduWork Panels: 3, 5, or 7 jurors
• Time to ruling · Web2 Platform Arbitration: 7 to 30 days · Single-Arbitrator Escrow: 3 to 7 days · Large On-Chain Court: 7 to 21 days · FiduWork Panels: 72 hours fixed
• Cost basis · Web2 Platform Arbitration: Bundled into platform fee · Single-Arbitrator Escrow: Flat arbitrator fee · Large On-Chain Court: Per-round juror fee · FiduWork Panels: 10% pooled stake
• Transparency · Web2 Platform Arbitration: Private ticket · Single-Arbitrator Escrow: Off-chain email trail · Large On-Chain Court: Full on-chain trail · FiduWork Panels: Full on-chain trail
• Reversibility · Web2 Platform Arbitration: Platform override · Single-Arbitrator Escrow: Legal appeal · Large On-Chain Court: Multi-round appeal · FiduWork Panels: On-chain governance escalation
• Custody during dispute · Web2 Platform Arbitration: Platform holds funds · Single-Arbitrator Escrow: Arbitrator or platform · Large On-Chain Court: Contract holds funds · FiduWork Panels: Contract holds funds

The clearest trade-off is speed versus depth of appeal. Larger courts allow multiple appeal rounds at the cost of weeks per case. FiduWork's fixed 72 hour window optimizes for cash flow, which matters for freelancers whose payment cycles are otherwise measured in weeks. Predictable settlement time is the point of choosing a small odd panel with a hard-coded deadline in the first place.

Platform Signal. On our Sepolia beta, 1,200+ freelancer profiles moved $2.4M+ in on-chain payments with response times averaging under 2 hours, and the panel design is being stress-tested against that flow before mainnet promotion.

What regulations govern on-chain dispute resolution?

The regulatory frame for on-chain dispute mechanisms in the EU sits inside the crypto-asset service provider rules. MiCA Regulation (EU) 2023/1114 Article 60 governs authorisation of any crypto-asset service provider (CASP) offering custody, exchange, or transfer services inside the EU, and its authorisation regime shapes how a platform can design its arbitration surface without triggering CASP registration for the panel itself.Source

Compliance corner. Because the FiduWork panel is non-custodial and its jurors act on wallet-level permissions rather than holding funds, the panel operator does not itself provide a crypto-asset service under MiCA Article 60. The escrow contract holds USDC; the panel signs a ruling. Where the platform interfaces with fiat rails, additional CASP authorisation analysis applies under the same authorisation regime, and the wider MiCA text at eur-lex.europa.eu is the primary reference.

Data handling around evidence

IPFS-stored evidence is a public record. Both parties should redact personal data before submission to stay inside GDPR practice. Contract addresses, milestone amounts, and rulings are already public via chain data, so the sensitive surface is the evidence content itself.

Enforcement of on-chain rulings off-chain

An on-chain ruling settles the USDC. It does not, on its own, resolve contract-law questions about IP transfer, warranties, or indemnities. Parties who need those enforced still need a written services agreement pointing at the on-chain settlement as the payment settlement mechanism, an approach compatible with the platform's FiduWork pricing and documentation structure.

What an evaluator should verify before recommending the system

1. Read the panel contract source directly and confirm the lifecycle matches the flow described above.
2. Pull a Sepolia dispute transaction and trace the full event sequence end to end from dispute open through settlement.
3. Confirm the juror pool contract enforces DID and stake preconditions before the draw executes.
4. Check that the voting plugin instance uses the 72 hour duration and read the quorum threshold from the deployed configuration.
5. Simulate a quorum failure in a fork and confirm the escalation path matches whatever the platform documents.
6. Verify the slashing and 30/70 payout math against the deployed contract, not against prose.
7. Review the escrow contract's dependency on the panel address to confirm no privileged bypass exists on the platform side.
8. Cross-check the plugin permission grants against the Aragon-OSx documented pattern for isolated DAO instances.
9. Trace a settlement transaction on Sepolia and confirm the USDC transfer amounts follow the 5% stake and 30/70 split rules.

The point of the checklist is that every substantive claim about the mechanism should be testable on-chain. Anything in this piece that reads like a specific contract parameter should be treated as descriptive of the design intent, not as a guarantee, until the deployed source confirms it.

Where to go next on FiduWork

If you want to see the full mechanism, review the FiduWork escrow architecture deep dive or read the protocol documentation. The wider blog archive has related pieces on reputation and payment rails.

Audit Our Escrow Architecture. Read the escrow and panel contracts, then verify the Sepolia transactions yourself. Open the app.

Sources

1. Aragon documentation, OSx framework overview
2. Ethereum whitepaper, ethereum.org
3. Circle USDC developer documentation
4. Immunefi reports on crypto exploit losses
5. OpenZeppelin security audits archive
6. Trail of Bits public audit reports repository
7. MiCA Regulation (EU) 2023/1114, eur-lex.europa.eu

Update Log

• 2026-07-29: Published.