Documentation / Decisions

Payments & Memory

Edith makes a payment decision before the wallet signs, then checks what actually happened after a transfer is sent. The record of that outcome shapes the next decision.

From request to outcome

  1. Recall. Edith reads earlier outcomes in the wallet's Walrus Memory namespace. A previous paid failure for the same request can stop a repeat before the provider is contacted.
  2. Quote. Edith requests the resource. A paid provider returns HTTP 402 with payment terms. Edith checks the URL, price, payee, network, memory decision, and limits before showing an approval.
  3. Approve. The wallet owner reviews the amount and recipient, then signs the exact SUI transfer. Edith simulates and checks the signed transfer before sending it to the provider. The agent cannot do this step.
  4. Settle and verify. The provider submits the transfer and responds. Edith independently checks the Sui transaction through Tatum's Sui gateway, including what reached the provider.
  5. Judge and remember. Edith classifies the paid response and writes the outcome to Walrus Memory. Activity shows the Sui digest and memory reference when available.

Spending limits

The owner sets Most per payment and Most in 24 hours on the Limits screen. Edith checks both before offering a payment and again when reserving a signed payment. The rolling daily total includes payments still settling or uncertain. A hard 0.01 SUI per-call ceiling also applies.

Memory may refuse a purchase, but it cannot raise a limit. If historical payments for a wallet have not been reconciled, new payments remain on hold until evidence-backed reconciliation is complete.

What memory changes

A paid empty or malformed response, or a rejected response, can cause Edith to refuse the same request later. A temporary HTTP 408, 429, or selected 5xx error causes a 15-minute cooldown before a retry is allowed. Edith can also refuse an endpoint after at least three distinct paid failures make up more than half of its remembered requests, or refuse a price more than twice a previous successful price.

These decisions use recorded outcomes, not a guarantee of provider quality. A provider may change, a response may be useful to one person but not another, and a request can fail after payment. Review the specific URL and quote before signing.

Failed, refused, and uncertain

SituationWhat Edith does
Refused before paymentReturns a reason. No wallet signature or provider payment is requested.
Wallet decline or pre-send failureDoes not send the transfer. A new request may need a new quote.
Confirmed chain failureMarks the provider payment refused. Sui gas may still have been charged.
Uncertain after signingHolds the spending reservation and offers Check Sui again. Edith does not treat silence as a failed payment.
Paid but memory save failedKeeps the verified payment record. The Walrus blob may be missing, so the next decision may not have that outcome in memory.

When a signed transfer remains uncertain, wait for verifiable Sui evidence. Edith can clear it after a confirmed failure or proof that the exact signed transfer can no longer execute. Do not send another payment for the same request just because the provider timed out. Sui transfers that settle are final; Edith cannot refund them.

What each system does

Edith is the decision and approval layer. Sui is the public blockchain where wallet-signed transfers settle. Tatum supplies the Sui gateway Edith uses to verify transfers. Walrus Memory stores wallet-scoped outcome records for future decisions. Vercel runs the site and API; Neon holds application state and the payment ledger.

Inspect a real Mainnet run

The Mainnet evidence record documents a useful paid quote, an empty paid response, and a repeat request refused without another wallet prompt. It links the Sui transactions and Walrus blobs and explains the independent verification. Public transaction data cannot be deleted from Sui.

Review the Agent API