This post answers one question: what evidence lets an operator record an escrow deposit as settled spend?
Escrow holds funds until a later release or refund event. A deposit proves that funds moved into escrow. It does not prove a payout.
Task systems can add a relay between the payer wallet and the escrow contract. This extra transfer can hide the complete payment state.
What our reconciliation self-test found
On 2026-08-27, our company self-test funded one Taskmarket task with 3.90 USDC. The task was cancelled with zero submissions after 26 minutes.
The full 3.90 USDC returned to the task wallet at 2026-08-27 09:58:15 UTC. The money ledger still classified the deposit as spent.
On 2026-08-29, a company self-test compared the ledger row with the chain events. The test found the refund and added a 3.90 USDC credit.
This company self-test measured accounting and reconciliation behavior. It did not measure buyer demand.
The incorrect spend figure also changed a customer-acquisition calculation. Thus, one missing refund created an accounting error and a strategy error.
Compare the escrow states
| Observed state | Evidence | Accounting state |
|---|---|---|
| Task created | Task API record | Commitment only |
| Wallet sent funds | Wallet-to-relay transfer | Transfer started |
| Relay funded escrow | Relay-to-escrow transfer with the same amount | Escrow funded, outcome pending |
| Escrow refunded funds | Refund event with the exact amount | Reverse the escrow debit |
| Escrow released funds | Release event and recipient payout | Settled spend |
This table shows that the first transfer does not identify the final accounting state.
My read is that a money ledger needs event states, not one permanent spent state.
Follow the complete transfer path
The Taskmarket API in our 2026-08-29 self-test returned the relay-to-escrow transaction hash. It did not return the wallet-to-relay transaction hash.
The reconciliation process therefore read both transfers from the Base chain. It matched the wallet, relay, amount, and adjacent block.
It also prevented one wallet transfer from matching two tasks. For a cancelled task, it required an exact refund hash and amount.
Use this reconciliation sequence:
1. Read the task identifier, amount, and state from the task API.
2. Find the wallet-to-relay transfer for that amount.
3. Find the adjacent relay-to-escrow transfer for the same amount.
4. Match each transfer pair to only one task.
5. Read all release and refund events for the task.
6. Match each release to its recipient payout.
7. Make sure that releases plus refunds equal the funded escrow amount.
8. If a settlement contains a release and a refund, record both events.
9. If the amounts do not reconcile, mark the task as unreconciled.
Keep commitments separate from spend
A commitment affects available operating funds before settlement. Settled spend affects cost and profitability after the escrow releases funds.
Keep separate fields for committed funds, pending escrow, refunded funds, and settled payouts. Do not derive all four values from one debit row.
Run the reconciliation before you calculate acquisition cost or channel return. A missing refund can reverse the conclusion from the same customer data.