Transaction verifier
Setting up, delegating, or revoking an account changes on-chain permissions, so it has to be exact. Signalhouse builds the unsigned transaction and stores a fingerprint of it as an intent. After you sign and submit, the verifier proves the transaction that landed is byte-identical to the one that was built, before it trusts the confirmation. It is fail-closed.
Why this exists
Between the moment Signalhouse builds a transaction and the moment it lands, the bytes pass through your wallet and the network. The verifier closes that gap: a confirmation is only trusted once the landed transaction has been proven identical to what was built. That means a tampered or substituted transaction can never be recorded as a successful setup, delegation, or revoke.
What it proves
Against the stored intent, the verifier confirms the on-chain transaction matches on every one of these points. A mismatch on any single one is a rejection.
- Fee payer
- The first account key equals the intended payer. This pins who pays for and anchors the transaction.
- Blockhash
- Matches the recent blockhash recorded in the intent, so an old or swapped transaction cannot be passed off as this one.
- Message fingerprint
- A hash of the full transaction message is unchanged, so the overall shape of the transaction is exactly as built.
- Instruction fingerprint
- A hash of the instruction set is unchanged, so no instruction was added, removed, or altered.
- Required signer
- Your wallet is among the required signers, confirming the transaction is the one you authorized.
- Program whitelist
- Only Drift and ComputeBudget may run, with the System program allowed during account setup. Any other program causes a rejection.
- No address lookup tables
- Address lookup tables are rejected outright, because an ALT can hide a program behind an indirect key and defeat the whitelist.
For a delegate or revoke, an optional post-state check then reads the resulting on-chain account and confirms the delegate field matches the intent: set to the Signalhouse delegate for a delegation, and cleared for a revoke.
Fail-closed confirmation
The confirm step marks an intent confirmed only on a fully clean pass. Every other path records an outcome and refuses the confirmation.
- Unknown or foreign intent
- An intent id that does not exist, or does not belong to the authenticated user, is treated as not found.
- Already resolved
- An intent that was already confirmed or rejected returns its previous outcome instead of being re-evaluated.
- Failure or mismatch
- An on-chain failure, a fingerprint mismatch, a disallowed program, or an expired intent is rejected and the reason is recorded.
No runtime SDK
The verifier is built on pure Solana web3 primitives plus the stored intent, with no Drift SDK at runtime. That keeps it small and independently auditable: its verdict cannot be steered by SDK behavior, only by the bytes on chain and the fingerprint that was committed up front.