Budget Reservations

Understand budgets and spend reservations

A daily budget is a policy boundary, while the wallet balance is an account observation. EdgeORE's durable reservations account for reviewed operations by signer, cluster and UTC review day. This prevents one pending or unknown transfer from being forgotten when the app restarts. It also prevents a repeated tap from counting as unrelated work if the coordinator correctly keeps one operation identity.

Read the accounting model

Each eligible operation counts once. A refusal, abandonment, expiry of an unsent operation or chain-confirmed failure can release a reservation according to its state. A submitted transfer with an unknown outcome continues to hold it. Historical receipts from earlier versions also matter to the migration policy. Do not replace this model with an in-memory counter because a demonstration only lasts a few minutes.

A per-signer budget means reconnecting to another wallet account does not erase the first account's pending obligations. A per-cluster budget means development and any future production policies cannot be mixed casually. A UTC review day is a precise accounting convention; it is not the user's local midnight unless those happen to coincide. The UI should explain the convention when it affects available budget.

Consider an example

Suppose the user reviews a tiny transfer and signing succeeds. Before submission, that operation reserves its amount under the review day's budget. If the user discards signed bytes that were never sent, the operation can be abandoned and the reservation released under the supported policy. If Send was attempted and the RPC timed out, releasing the reservation would be unsafe because the chain outcome is not yet known.

Now suppose the app restarts the next morning. The pending operation remains tied to its original review day and signer. A naive daily reset could forget the obligation or double-count it under the new day. Durable records and explicit state transitions let the budget calculation handle the operation consistently. Tests should include this boundary because user-visible dates often hide accounting bugs.

Explain refusals to users

An exceeded budget, unknown blockhash validity, unsupported instruction and unavailable RPC are different gates. Show the actual reason that blocks signing rather than a generic unavailable toast. A failed balance read should not clear a wallet connection, and a declined wallet prompt should not be logged as a confirmed chain failure. Clear distinctions help the user decide whether to change input, wait, reconnect or observe a previous operation.

Settings labels should distinguish enforced controls from saved preferences. A slider persisting its value does not prove it limits another process's CPU usage. A budget implemented in the transfer review path has a specific enforcement point. Document that path, and do not advertise it as a system-wide spending restriction on every wallet or every dApp installed on the phone.

Validate the policy

Test duplicate operation identity, refusal release, unsent abandonment, unknown sent outcome, restart persistence and day/account boundaries. Preserve the actual test results at the source revision. Runtime testing should verify that the UI's available budget and pending operations agree with the persisted model. The acceptance target is understandable, consistent accounting, not an earnings number or a promise that EdgeORE can reverse a signed blockchain action.

---

Wiki home · Qualification updates · Sources and credits