Dispute — arbiter resolves for the operator
The same power, exercised the other way: the disputed slot is credited back to the Operator as a refund.
Engineering assessment, not a legal opinion
What follows describes what the contract mechanically permits. Whether it satisfies a given regulator is for counsel. Residual questions are listed rather than resolved.
What happens
resolveDispute(escrowId, forCreator = false) marks the slot refundable to the Operator's allocation. The Operator then collects with withdrawRefund(escrowId).
The two-step split is deliberate: resolution only credits, and collection is a separate permissionless-to-the-owner call, so settlement itself cannot fail on a token transfer.
Non-custody evaluation
Same power, same three constraints as the for-creator case — Disputed slots only, two pre-committed destinations, cannot freeze.
One asymmetry worth noting: this direction returns funds to the party who put them in. That is the less alarming direction for a custody analysis, since VF is not directing money away from its source.
VF cannot call withdrawRefund on the Operator's behalf; the credit sits until the Operator collects it.
No-service evaluation
Same as the for-creator case. VF originates the state change; the destinations were fixed by the parties. Because the funds return to their source, there is no third-party transfer at all — arguably the weakest service-exposure of any dispute outcome.
Residual questions for counsel
- An arbiter that consistently resolves for Operators would be a marketplace favouring the paying side. That is a governance and reputational question rather than a legal one, but the resolution record is on-chain and will be read that way.
- Same open question as the for-creator page: whether VF should hold this role at all.