Docs
Glossary
secp256r1
A standard elliptic curve for digital signatures, also called P-256 or prime256v1. Defined by NIST. Used by WebAuthn, FIDO2, Apple Secure Enclave, and most hardware security keys. The equation is y² = x³ - 3x + b (mod p) over a 256-bit prime field.
Solana's native transaction signatures use secp256k1 (Bitcoin/Ethereum's curve) and Ed25519. Secp256r1 requires the dedicated SIMD-0075 precompile to verify onchain.
P-256
An alias for secp256r1. The "256" refers to the 256-bit key length. P-256 is the curve used by COSE algorithm ES256 (ECDSA with SHA-256), which is the default signature algorithm for FIDO2/WebAuthn authenticators.
SIMD-0075
A Solana Improvement and Modification Document that added a native secp256r1 signature verification instruction to the Solana validator. Deployed on mainnet in February 2025.
Before SIMD-0075, verifying a P-256 signature onchain required a custom program implementing the math in software — slow and expensive. SIMD-0075 adds it as a native precompile at the same cost as Ed25519 verification. This is what makes Trana possible: a passkey signature can now be verified inside any Solana program without a server.
FIDO2
An authentication standard from the FIDO Alliance that combines two components: WebAuthn (the browser/app API) and CTAP2 (the protocol for communicating with hardware devices). FIDO2 authenticators generate P-256 key pairs where the private key never leaves the device.
Any FIDO2 authenticator using ES256 works with Trana: passkeys, YubiKey 5 series, Google Titan, SoloKey, Windows Hello (P-256 mode), Android biometric.
WebAuthn
The Web Authentication API — a W3C standard that lets browsers and apps interact with FIDO2 authenticators. When you use Touch ID on a website, that is WebAuthn. It exposes two operations: navigator.credentials.create() (registration) and navigator.credentials.get() (assertion/approval).
A WebAuthn assertion produces: a signature, authenticatorData (device metadata + counter), and clientDataJSON (origin, challenge, type). Trana bundles all three into the transaction as the record_proof instruction.
Passkey
A specific type of FIDO2 credential that is synced across devices via the platform's cloud service (iCloud Keychain for Apple, Google Password Manager for Android). Passkeys are generated by the device's secure enclave and can be used on any of the user's signed-in devices.
Passkeys are the consumer-friendly deployment of WebAuthn. Enterprise deployments often prefer hardware-bound keys (YubiKey) that are not synced and cannot be extracted. Both work with Trana.
Hardware security key
A physical USB or NFC device (YubiKey, Google Titan, SoloKey) that stores a FIDO2 private key. Unlike passkeys, hardware security keys are not synced — the private key is bound to the physical device and cannot be exported. Used in enterprise deployments where cloud sync is not acceptable. All FIDO2 hardware security keys using ES256 work with Trana.
ES256 / COSE algorithm -7
The COSE (CBOR Object Signing and Encryption) identifier for ECDSA with P-256 and SHA-256. COSE algorithm -7 is the default signature algorithm for most FIDO2 authenticators and is what Trana registers and verifies.
Execution-time authorization
A security model where protected actions require an explicit approval at the moment they execute — not just at the time a transaction is signed. The key distinction from traditional signing-time authorization: a pre-signed transaction or a replayed signature cannot bypass execution-time enforcement, because the approval is evaluated inside the program at runtime.
Intent hash
A 32-byte SHA-256 hash that cryptographically binds a passkey signature to a specific authorized action. Trana's intent hash is computed from: version, domain, cluster, wallet pubkey, guard program ID, target program ID, policy ID, instruction discriminator, accounts hash, params hash, nonce, and expiry timestamp.
The intent hash becomes the WebAuthn challenge — the value the device's secure enclave signs. Because the challenge is fully determined before the device is prompted, the device approval is cryptographically bound to exactly the action described.
Accounts hash
A 32-byte SHA-256 of all account public keys in the protected instruction, concatenated in order. Included in the intent hash. The guard recomputes this from the live transaction at execution time — any account substitution between approval and execution changes the hash and causes PayloadMismatch.
Params hash
A 32-byte SHA-256 of the raw instruction parameter bytes (bytes 8 onward, skipping the 8-byte Anchor discriminator). Included in the intent hash. Any change to instruction parameters — amount, destination, configuration — invalidates the proof.
TwoFactorRegistry
The on-chain PDA (Program Derived Address) that stores a user's registered P-256 public key and the enforcement nonce. Seeds: ["2fa", wallet_pubkey] on the guard program.
Fields: owner (wallet), pubkey_bytes (compressed P-256 key, 33 bytes), credential_id (WebAuthn credential ID, up to 128 bytes), enabled (bool), nonce (u64).
Enforcement nonce
A u64 counter stored in the TwoFactorRegistry, incremented by the guard program after every successful enforce() call. Included in the intent hash. Prevents replay: a captured proof becomes invalid after the next enforcement because the nonce no longer matches.
enforce CPI
The onchain entry point into the guard program. Other Anchor programs call guard::cpi::enforce(ctx, policy) inside their own instructions. The guard evaluates the policy, verifies the proof, increments the nonce, and emits a ProofVerified event. If verification fails for any reason, the entire transaction is rejected.
record_proof instruction
A guard program instruction that acts as a data carrier. It carries the WebAuthn authenticator_data, client_data_json, expiry timestamp, cluster, and policy ID. It must be at ix[N-1] in the transaction — one position before the protected instruction. The protected instruction reads this data via the Instructions sysvar when enforce() is called.
Pre-signed transaction attack
An attack where a valid Solana transaction is constructed and signed days or weeks before it is submitted. Because the wallet signed the transaction legitimately, UI-level checks and confirmation prompts were bypassed at signing time. The transaction is held and submitted at the moment most advantageous to the attacker.
Trana defeats this: the proof is bound to a specific nonce and expires within 120 seconds. A pre-signed transaction without a fresh proof fails with MissingProof or ProofExpired.
Durable nonce
A Solana mechanism that replaces the recent blockhash with a nonce account value, allowing transactions to remain valid indefinitely (there is no 150-block expiry). Used by custodians and offline signing workflows. Combines badly with pre-signed transactions in adversarial contexts.
Trana defeats durable nonce replay via proof expiry (120-second default) and the registry nonce.
ProofVerified event
An Anchor event emitted by the guard program after every successful enforce() call. Contains: owner (wallet pubkey), policy (string), target_program (pubkey), nonce (u64). Permanently recorded on-chain as part of the transaction log. Used for compliance auditing and monitoring.
SIMD
Solana Improvement and Modification Document — the Solana equivalent of an Ethereum EIP. SIMD proposals are discussed publicly, go through a review process, and are merged into the validator source code when accepted. SIMD-0075 is the secp256r1 precompile.