Exact Message Review

Review the exact transaction message

EdgeORE's central transaction property is that the user reviews the exact message the wallet will sign. A friendly summary is useful only if it is derived from those bytes and bound to them. The candidate supports a devnet System Program SOL transfer; it does not approve every Solana instruction or arbitrary transaction assembled by another service. Unsupported content should disable approval rather than receive a reassuring generic label.

Inspect the supported action

The review should expose sender, recipient, lamports or exact SOL amount, cluster, program, account roles, message digest and available fee information. Recent blockhash and validity also matter because they affect whether signing is still appropriate. Unknown fee and unknown validity are different issues: the UI must label missing information, and an unknown blockhash-validity state must block signing under the candidate's policy.

Amounts need exact parsing. Reject negative values, excess precision, overflow, empty input and malformed decimal strings. Do not use a floating-point value as the source of lamports. A displayed amount that rounds differently from the message can deceive the user even when no code intends fraud. Tests should compare the decoded message amount with the reviewed input at the integer level.

Bind the review to bytes

The message digest identifies the reviewed byte sequence. After the wallet returns a signed transaction, decode or extract its message and compare it byte for byte with the reviewed message. A changed recipient, blockhash or account ordering changes what was signed. Do not accept it simply because a few fields look similar. Verify the wallet's Ed25519 signature against the actual message and signer as well.

Signing and submission remain separate. A quickstart that calls signAndSendTransactions inside the wallet callback bypasses this product's explicit submit boundary. That may be valid for another dApp, but it does not satisfy EdgeORE's reviewed workflow. Use the existing sign-only integration and verify its result before enabling Send. A signature is evidence of authorization over bytes, not evidence of network delivery.

Re-check time-sensitive validity

A prepared review can become stale while the user reads it or switches apps. The merged fix re-checks block height before opening the wallet and blocks signing when the blockhash is within twenty blocks of expiry. This is a conservative gate tied to lastValidBlockHeight, not a wall-clock countdown guessed from a typical block time. If the height read is unavailable, the app must fail closed.

A fresh blockhash requires a fresh review because the message bytes change. Do not silently replace it after the user approves the earlier digest. If the operation expires without submission, explain that the user needs a new reviewed operation. If submission was already attempted, expiry alone cannot safely establish that the transfer failed; the recovery chapter explains why its outcome stays uncertain.

Evaluate the gate

Prepare a valid small transfer and inspect all fields without signing. Try a bad recipient, excessive decimal precision and unavailable validity. Confirm Sign is disabled with a specific reason. In a supported wallet runtime, sign and verify the returned bytes before Send appears. Preserve the review screenshot and operation identity. This proves more than a success toast because the evidence identifies the exact action the user authorized.

---

Wiki home · Qualification updates · Sources and credits