nexus CLI: no way to resolve TAP payment receipt / reclaim unconsumed payment-coin balance

[tuky191]

Summary

After running nexus dag execute without --payment-budget, the entire --payment-coin balance is transferred into a TAP payment object. Only the actual execution cost (a small fraction) is consumed; the remainder sits locked in that payment object with an unresolved receipt. The CLI exposes no way to claim the refund — nexus tap payments only has a list subcommand.

Reproduction (on v2.0.0-rc.1 contracts)

# Coin 0xc46ed2ef… had 1.288 SUI
nexus dag execute \
  --dag-id 0xbcb04dba67f862d25b90926c81a661eb43973404ea15825ceb81e43f985656db \
  --input-json '{"add_input_and_default": {"a": 10}}' \
  --payment-coin 0xc46ed2ef8e1885a534d6058ecb7750baca330bbcb52298b8acaae9619759eb14 \
  --sui-gas-coin 0x070abef00046448d38e028f1bd63cc25ea04aa4b3da567bc706f4f333fc4124c \
  --inspect
# → success, DAG ran end-to-end (simple math DAG, 3 vertices)

nexus dag execution-cost --dag-execution-id 0x7772f97a1b2b5fed575d9a7e2fde83ae8729917b50800b04548b8ec1636764d8
# Consumed: 23,966,696 MIST
# Budget: 1,288,200,065 MIST locked from max 1,288,200,065 MIST
# Outstanding tool locks: 0

# The original coin is deleted:
curl -s -X POST <rpc> -d '{"jsonrpc":"2.0","method":"sui_getObject","params":["0xc46ed2ef…",{}]}' | jq
# → {"error":{"code":"deleted",…}}

nexus tap payments list --json
# → wallet_receipts: [ { execution_id, payment_id, max_budget: 1288200065, resolved: false } ]

Practical impact: the wallet had 2 coins (~1.288 + ~1.255 SUI). After one math DAG execute (~0.024 SUI actual cost), only 1 coin is spendable. The other 1.264 SUI is locked in the payment object with no exposed way to recover. The default --payment-budget = full coin balance amplifies this drastically — a 100 SUI payment coin would lock 100 SUI for a 0.024 SUI execution.

Expected behavior

One of:

1. nexus tap payments resolve --receipt-id <…> (or --execution-id <…>) — closes the receipt and refunds the unconsumed balance to the payer's wallet. Most discoverable, mirrors the list subcommand pattern.
2. Auto-resolve on execution finalization — the scheduler/leader resolves the receipt as part of settling the execution, so users never see locked-but-unused funds. (If this already exists but didn't fire for this execution, the bug is elsewhere — execution status was "finished successfully" per inspect.)
3. Tighter default --payment-budget — instead of "full coin balance," default to a small standard cap (or require --payment-budget explicitly), so accidental over-locking doesn't happen.

I'd suggest (1) + (3) as a minimum: expose the resolve operation in the CLI, and tighten the default budget so users don't accidentally orphan SUI in the first place.

Workaround for now

Always pass --payment-budget <small-mist> (e.g. --payment-budget 50000000 for 0.05 SUI cap on math-class DAGs). The leftover coin balance stays spendable.

Context

Hit during validation of the v2.0.0-rc.1 side-by-side rollout (nexus-testnet-v2-0-rc-1 env). DAG executed correctly end-to-end — this is purely a payment-flow ergonomics issue, not an execution bug.

[LKY-stephen]

For this particular case, we can run

sui client call --package 0x6a7daf5ff5c63dc6f22b2d9b23785917081f80dea91df10bdcbde68fec601b49 --module dag --function accomplish_tap_execution_payment --args 0x7772f97a1b2b5fed575d9a7e2fde83ae8729917b50800b04548b8ec1636764d8 

to resolve it, and we should wrap it into a Nexus cli command @kouks

[davidrotari19]

Solved by https://github.com/Talus-Network/nexus/issues/797