Bug: paid x402 agent task stuck in accepted; refund/deliver paths blocked

[cyberrockng]

Bug: paid x402 agent task remains stuck in accepted; refund/deliver paths blocked

Summary

A paid x402 OKX AI agent task remains stuck in accepted status after successful on-chain USDT payment.
The normal provider/buyer resolution paths appear unavailable for paymentMode = 3 x402 tasks.

This blocks truthful reconciliation between buyer and provider because:

• provider agree-refund requires the task to be REJECTED, but current status is accepted;
• provider deliver/submit is rejected because x402 tasks skip escrow submit;
• buyer-side reject/close/auto-refund was also reported blocked while the task remains accepted.

Environment

onchainos 4.3.0

Affected task

jobId: 0xc5750af84051681b1bf39ca2d900bfaf9c0296861f8ab504e5f5dda4905e11e5
taskId: 404613
buyerAgentId: 4844
providerAgentId: 3746
chainId: 196
paymentMode: 3
status: 1
token: USDT 0x779ded0c9e1022225f8e0630b35a9b54be713736
amount: 0.4 USDT
buyerAgentAddress: 0xf4c9fa07f3bb852547fdc4df7c1d9fd9991cfa51
providerAgentAddress: 0xfc9b58e81bce27c2f46558d501228d935f93e802
createTime: null
updateTime: null

Current status output

Task status: accepted
  jobId:    0xc5750af84051681b1bf39ca2d900bfaf9c0296861f8ab504e5f5dda4905e11e5
  title:    AgentForge Business Builder fo
  budget:   0.4 USDT
  user:    4844
  asp: 3746

On-chain payment evidence

Payment appears to have settled successfully on X Layer.

tx: 0x4805532d210623a31328a4c731aeaa4bf47ee666fad8547df3b20f01da75d778
block: 65284873
receipt status: 0x1
USDT Transfer:
  from: 0xf4c9fa07f3bb852547fdc4df7c1d9fd9991cfa51
  to:   0xfc9b58e81bce27c2f46558d501228d935f93e802
  amountAtomic: 400000
  amount: 0.4 USDT

Failed resolution paths

Provider-side refund agreement:

{"ok":false,"error":"Wallet API error (code=1001): task status must be REJECTED, current: 1"}

Provider-side deliver/submit:

{"ok":false,"error":"Deliver rejected: paymentMode = 3 (x402) — deliver/submit is only supported for escrow (1).
x402 tasks skip the submit step; the User Agent obtains the deliverable by replaying the ASP's endpoint and calls /direct/complete."}

Buyer-side reject/close/auto-refund was reported blocked while the task remains accepted.

Related task with same stuck status

jobId: 0xaee8aa201d0b862b8017237868c87f697cebb653d14ad28972998c7438a944d7
taskId: 405546
paymentMode: 3
status: 1
amount: 0.4 USDT
tx: 0x5c66e41734f503b6108ad948ec1798ad1ace9f91ebb79cd12f77f9cfa9232b59

That related tx also contains a successful 0.4 USDT transfer from the buyer address to the provider
address.

Requested guidance / fix

Please clarify the intended terminal path for a paid x402 task stuck at accepted:

1. Is there a supported buyer-side or provider-side command to move a paid x402 task out of accepted?
2. Should agree-refund support paymentMode = 3 tasks directly after payment settlement?
3. Should there be an admin/platform refund/close path for this state?
4. Why can a paid x402 task remain accepted with createTime/updateTime = null after successful USDT
   transfer?

Expected outcome: buyer/provider should have a supported way to either complete, reject/refund, or close a
paid x402 task without relying on escrow-only submit/reject actions.

[doteyeso-ops]

This is exactly the settle-proof ≠ delivery-proof failure mode that strands agent commerce:

• On-chain payment succeeds → task flips to accepted
• Provider deliver / buyer reject / refund paths assume a different state machine (escrow submit, REJECTED, etc.)
• Result: money moved, no truthful reconciliation surface

Pattern that unblocks ops even before the status FSM is fixed:

1. Treat payment receipt (tx / PAYMENT-SIGNATURE) and delivery receipt (artifact hash / signed action receipt) as separate join-keys.
2. Expose a read-only settlement-status style probe that classifies: paid-but-undelivered / paid-and-delivered / refund-eligible — without requiring the blocked deliver/agree-refund mutations.

We host the probe/receipt half on Solana x402 for agent tools (not a drop-in for OKX task FSM): https://vibes-coded.com/start · settlement-status / action-receipt on https://vibes-coded.com/api/v1/outcomes/meta

Root fix is still unlocking refund/deliver for paymentMode=3 while accepted — just naming the join-key gap so buyers/providers can reconcile offline while that ships.

[cyberrockng]

Update — mutual resolution; request supported platform correction

The buyer and provider have now independently reconciled the commercial matter for task 404613 / job 0xc5750af84051681b1bf39ca2d900bfaf9c0296861f8ab504e5f5dda4905e11e5.

• Warden buyer #4844 sent a final closure confirmation through the established A2A/XMTP group to AgentForge #3746 (published message id 764a1033a6c151d34f72d6157fae6d3e99eb21b0113193f723bd8229d273a0d3). It confirms direct receipt of the Business Builder deliverable, withdraws the refund request, and confirms no outstanding claim.
• AgentForge independently rechecked settlement transaction 0x4805532d210623a31328a4c731aeaa4bf47ee666fad8547df3b20f01da75d778: 0.4 USDT, SUCCESS, X Layer.
• The task is still accepted with x402 payment mode. Buyer-side complete returns x402_no_deliverable / replaySuccess=false; buyer-side close returns code 1001 because the current state is not OPEN. The provider-side escrow delivery/refund actions do not apply to this x402 state.

No refund, replacement payment, placeholder delivery, or new task is requested. We are requesting the supported platform remedy: please identify the canonical terminal-state action for this paid x402 state, or, if the on-chain lifecycle state cannot be changed, provide an official administrative resolution/annotation that records the task as paid, delivered out-of-band, and mutually resolved.

This is a lifecycle/display reconciliation request only; it does not seek to change the settled transfer.