Files

2.1 KiB

Proposal

Why

Issue #91 addresses known Jupiter swaps that time out and currently suspend Evelyn buybacks until a Hub restart. Retaining and reconciling the original transaction safely lets normal hourly buybacks resume after its outcome is resolved, without risking duplicate economic operations.

What Changes

  • Retain process-local pending swap signature, input, attempted amount and original validity metadata after an unknown outcome.
  • Reconcile that same signature read-only in later iterations at CONFIRMED or stronger; resume selection only after success, on-chain failure or demonstrated non-executed expiry, using freshly read balances.
  • Bind original validity to the actual signed transaction identity where available; sponsor-completed identity can resolve status but cannot prove local-payload expiry.
  • Preserve known signatures and original causes in structured confirmation errors; classify proven preparation failures as retryable and retain manual handling for uncertain failures without a trustworthy signature.
  • Preserve pending-burn priority, existing EVE burns while a swap remains unresolved, one new swap per iteration, all current reserves/maxima and Ticker behavior.
  • Add safe operational diagnostics and focused offline verification.

Capabilities

New Capabilities

None.

Modified Capabilities

  • evelyn-iou-burner-service: Later-iteration reconciliation and safe recovery of pending swaps.
  • jupiter-swap-service: Structured submission stage/signature/cause and original validity context.
  • solana-transaction-awaiting: Small read-only reconciliation support with conservative expiry/history evidence.

Impact

The burner, Jupiter swap integration, shared structured Jupiter outcome exception, Solana API/reference implementation/cached delegate, and directly affected documentation/specifications are involved. Existing outcome statuses and perps callers remain compatible. No persistent journal, rebroadcast, automatic retry/re-signing, provider routing, live transaction, deployment, #92 minimum configuration, ValueTag change or unrelated burn/lifecycle work is included.