Onchain Authorization · Solana
Execution requires approval.
A valid signature is not enough.
Trana enforces second-factor authorization at execution time. High-risk actions do not execute without explicit approval.
Problem
Signing is treated as authorization.
That assumption is broken.
Transactions can be pre-signed, socially engineered, or executed later using durable nonces. Once signed, execution is automatic.
Multisig does not fix this. It only increases the number of signatures required.
Pre-signed transactions
Valid signatures are gathered in advance, days or weeks before they are used. The chain has no way to object when they finally land.
Social engineering
Signers are convinced to authorize transactions they do not fully understand. The signature is genuine. The intent is not.
Durable nonce replay
Attackers pre-sign with a valid durable nonce, wait for the right moment, then execute without further interaction from the signer.
Automatic execution
Once a valid signature exists, no mechanism on the execution path can object. The transaction runs.
Solution
Second-factor authorization
at execution.
Trana blocks execution unless a second approval is present. Even if an attacker obtains valid signatures, the transaction still fails.
01
Signature alone is not sufficient
A valid wallet signature no longer guarantees execution. A second cryptographic approval is required.
02
Approval is required at execution
The proof must be generated for this exact transaction at the moment it runs. Pre-collected approvals do not work.
03
Enforced directly onchain
There is no client-side component to bypass. The guard runs inside the Anchor program. No proof means no execution.
How it works
Every step verified
onchain.
Approval is provided using a passkey or second-factor key and verified onchain. The secp256r1 precompile checks the cryptographic proof at the moment the transaction executes.
- 01
User signs transaction with their wallet.
- 02
Trana checks if the instruction requires authorization based on the configured policy.
- 03
If required, a second-factor approval must be present, bound to this exact transaction.
- 04
Without a valid approval, execution fails. The transaction is rejected atomically.
Interactive demo
The key is compromised.
Watch the guard reject a raw withdrawal. Then approve it with a passkey.
Attack simulation
See what happens when a key is compromised
The attacker has the private key. Watch the guard reject execution. Then approve with a passkey to see authorized execution.
What Trana protects
Any instruction where execution
must be explicitly approved.
If a single leaked key would be catastrophic, Trana belongs in that path.
Protocol upgrades
Upgrade authority and migration instructions require explicit passkey approval at execution time. A stolen admin key alone cannot trigger them.
DAO treasury transfers
Large disbursements and budget allocations are blocked without a second-factor approval bound to the exact amount and recipient.
Vault withdrawals
Collateral unlocks and high-value transfers require explicit approval at the moment the instruction executes.
High-value actions
Any irreversible onchain action where a single compromised signer would cause unrecoverable damage.
For developers
One call.
Any Anchor program.
Add one guard to your instruction. Execution will fail unless a valid second-factor approval is included in the transaction.
No custody change. No vault. No new infrastructure. Your program keeps full control. Trana enforces that a valid proof existed at the moment the transaction executed.
Cargo.toml
guard = { git = "github.com/beharefe/trana-guard",
features = ["cpi"] }In your Anchor instruction
pub fn your_protected_ix(ctx: Context<...>, expiry: i64) -> Result<()> {
guard::cpi::enforce(
CpiContext::new(ctx.accounts.trana_program, Enforce {
registry: ctx.accounts.trana_registry,
instructions: ctx.accounts.instructions,
}),
Policy::AdminAction,
payload_hash,
expiry,
)?;
// Only reached if second-factor approval was valid.
Ok(())
}Security model
Only valid cryptographic proof
allows execution.
The second-factor key is registered onchain. Approvals are verified onchain. There is no trusted backend and no offchain enforcement component that can be compromised or bypassed.
Second-factor key registered onchain
The P-256 public key is stored in a PDA. Registration requires a wallet signature. The key cannot be changed without authorization.
Approval verified onchain
The secp256r1 precompile verifies the proof at execution time. The verification runs inside the program, not in a backend.
No trusted backend
Trana does not rely on any offchain service to make enforcement decisions. The full trust chain is onchain.
No offchain enforcement
There is no middleware, no API gateway, and no SDK check that can be bypassed. The guard runs inside the Anchor instruction.
“Signatures can be collected early.
Execution must be approved late.”