Extend voucher settlement functionality#20
Open
yongqjn wants to merge 8 commits into
Open
Conversation
… storage
Unified submitClaim entry point for both fast (immediate) and slow (pending
approval) settlement paths. Provider-only caller; deliverable.length selects
path; both paths verify a client-signed EIP-712 ClaimVoucher.
- deliverable.length == 0 → fast path: unconditional voucher, immediate
delta release, supersedes any pending slow claim.
- deliverable.length > 0 → slow path: deliverable is the condition the
evaluator/client must vet. Stored as a single-slot binding hash
keccak256(abi.encode(cumulativeAmount, keccak256(deliverable))).
approveClaim and rejectClaim accept the preimage components and recompute
the hash, so approvers cannot release funds for a claim other than the
one the provider committed to. Both are restricted to client OR evaluator;
provider self-approve and self-reject revert Unauthorized.
Storage:
- mapping(uint256 => bytes32) public pendingClaimHash (single slot per job)
- bytes32(0) means no pending claim
- Adds CLAIM_VOUCHER_TYPEHASH and _verifyClaimVoucher (binds deliverable
into the EIP-712 digest so the client's signature attests to the work,
not just the amount).
Events: ClaimSubmitted (carries full deliverable bytes for indexers),
ClaimApproved (carries deliverableHash), ClaimRejected.
Tests cover both paths, auth model (provider-only submit, client/evaluator-
only approve/reject), preimage-mismatch revert, monotonic enforcement,
ClaimAlreadyPending, fast-path supersedes slow-path, invalid-signature revert.
Note: combined diff is 484 LOC. Kept as a single commit because contracts
and tests are tightly coupled — splitting would leave one commit with
unvalidated code or orphan tests.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Restrict the claim workflow to Funded jobs so submitClaim, approveClaim, and rejectClaim are not processed after a job enters Submitted. Refactor claim deliverables to bytes32 to match submit(), including ClaimVoucher signing, pending claim hashing, claim events, hook payloads, tests, and docs.
Evolve settle into submitClaim See merge request web3-wallet/community/base-contracts!1
# Conflicts: # test/ERC8183.test.js
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
settle(jobId, cumulativeAmount, voucherSig, optParams)for client-authorized partial settlementsettledAmountas the cumulative gross amount released from escrowVoucher(jobId, cumulativeAmount, optParams)signatures against the job clientcomplete,reject, andclaimRefundto operate onbudget - settledAmountDesign Reference
This follows the Partial Settlement: Vouchers design described in HackMD:
https://hackmd.io/@nicholas-okx/rkiZgYtRZx
The design goal is to standardize the release and accounting primitive for long-running or milestone-based jobs. The provider submits a client-signed cumulative voucher, and ACP releases only the newly authorized delta without completing the job.
Settlement Semantics
settleFundedorSubmittedand not expiredcumulativeAmountmust strictly increase oversettledAmountcumulativeAmountcannot exceedbudgetsettledAmount = cumulativeAmountFee Policy Chosen
The HackMD lists multiple fee handling options. This PR intentionally implements the option where both platform and evaluator fees are charged pro rata against each settlement delta.
Concretely:
settlecomputes fees fromdelta = cumulativeAmount - settledAmountcompletecharges fees only on the remaining escrow amountThis means fees are not reserved upfront and are not deferred entirely until final completion.
Testing
npm test