Submit Observe

Submit once and observe confirmation

Submission is a network operation with uncertainty. A timeout may occur after the RPC accepted a transaction, and an app can die before it records the response. Therefore a send button cannot equate a missing reply with Not sent. EdgeORE stores a durable operation and writes SUBMIT_ATTEMPTED before the network send. That pre-send state is a key part of its duplicate-prevention design.

Start from a verified signed operation

Only submit bytes whose message matches the reviewed message and whose wallet signature verifies. Keep the operation's signer, recipient, amount, cluster, blockhash and signature together. Confirm the user's explicit Send action. A reviewer should be able to see that wallet signing and RPC submission were two separate decisions. Avoid combining them in a background task that hides when the user became committed.

The send coordinator enforces single flight. Repeated taps should not create multiple operations or submissions. This property should be tested in code and observed carefully in runtime, with operation identifiers and logs. Disabling a button cosmetically is helpful, but it is not a replacement for durable state and coordinator-level protection against duplicate invocation.

Interpret the response

An RPC signature response is not yet confirmed success. Observe signature status on the same cluster and examine both confirmation status and the transaction error. A response with confirmationStatus confirmed or finalized and a non-null err is a confirmed failure, not a successful transfer. A null status is not a zero balance or proof the transaction was never sent. An RPC error is unavailable observation, not Not found.

SIG='<signature from EdgeORE Review>'
curl --fail-with-body --max-time 30 https://api.devnet.solana.com \
  -H 'Content-Type: application/json' \
  --data "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"getSignatureStatuses\",\"params\":[[\"$SIG\"],{\"searchTransactionHistory\":true}]}"

The signature should come from the operation in EdgeORE, not an assumed wallet history entry. A sign-only wallet may not record the app's later submission in its history. Historical search helps when a transaction is no longer in the recent status cache. Preserve the JSON response with the operation and time. An explorer URL is a convenient independent view, but it does not replace the captured status and error fields.

Handle uncertainty conservatively

Timeout, cancellation, signature mismatch or ambiguous transport failure moves the operation to OUTCOME_UNKNOWN. Do not tell the user to press Send again. The next action is read-only observation and reconciliation. This is especially important if the transaction's validity has expired after a submission attempt: it could have landed before expiry even though the app missed the reply.

Spend reservations remain held for an unknown sent outcome. Releasing them because a clock expired can permit another action before the first outcome is known. Conversely, a wallet refusal or an abandoned unsent draft can release a reservation under the operation policy. State-specific treatment protects users without pretending uncertainty can be resolved by a generic retry button.

Close the transfer gate

A successful gate contains the reviewed operation, wallet verification, explicit submit, signature, devnet RPC observation with err null and a confirmed or finalized status, plus the explorer link. The actual amount and recipient must be approved by the user before signing. No such real-transfer evidence is established merely by this handbook, so the website keeps that row unqualified until the session artifacts exist.

---

Wiki home · Qualification updates · Sources and credits