Compare
Trana vs Multisig
The most common question when developers first see Trana: "Isn't this just multisig?"
It is not. Multisig and Trana solve different problems, operate at different layers, and are better used together than treated as alternatives.
What Multisig Does
Multisig (Squads, on Solana) answers the question: who is allowed to initiate this action?
A multisig vault requires M signatures from a set of N designated wallets before a transaction can be submitted. This is a coordination mechanism for shared ownership:
- A DAO requires 3-of-5 council members to approve a treasury disbursement
- A protocol requires 2-of-3 team wallets to push an upgrade
- A fund requires all partners to sign off on a withdrawal
Multisig enforces governance — an agreed-upon set of actors must authorize an action through a coordination flow before it can proceed.
The limitation of multisig alone: each of the N signers is a single wallet key. If any one of those keys is stolen, the attacker can participate in the M-of-N quorum as a legitimate signer. If M is 2 and one of the 5 keys is compromised, the attacker needs only one more compromised key to reach quorum.
What Trana Does
Trana answers the question: is the person signing currently present at their device?
Trana enforces that the wallet performing an action must also provide a live second-factor approval from a registered FIDO2 device (passkey, YubiKey, etc.) at the moment the instruction executes. This happens onchain, inside the program, verified by the Solana secp256r1 precompile.
There is no coordination with other parties. There is no async approval flow. The user taps their Touch ID or presses their YubiKey, and the proof is bundled into the transaction.
The limitation of Trana alone: Trana does not address shared ownership or governance. A single wallet with Trana protection can still act unilaterally on any instruction it is authorized to call.
Side-by-Side Comparison
| Trana | Squads Multisig | |
|---|---|---|
| Core question | Is this person present at their device? | Did the required signers approve this? |
| Layer | Execution-time (inside the program) | Governance (before tx submission) |
| Signers | 1 — the acting wallet + their FIDO2 device | M-of-N designated wallets |
| FIDO2 device support | Passkey, YubiKey, Windows Hello | Any Ed25519 wallet key |
| Coordination required | Zero | Async — all required signers must act |
| Latency | Instant (one device tap) | Minutes to days |
| Protects against | Stolen wallet key acting alone | Unilateral action by one party |
| Best for | Per-action user 2FA | Shared treasury, team governance |
How They Compose
The pattern for high-security protocol operations:
Layer 1 — Squads multisig: Controls which wallets are authorized to call a protected instruction. Requires M-of-N approval before a transaction is constructed. This is the governance layer.
Layer 2 — Trana: Each wallet that participates in the Squads quorum has Trana enabled. When their wallet signs the Squads execution transaction, Trana requires a live device approval from that wallet's registered FIDO2 device.
An attacker needs to compromise M wallet keys AND have physical access to M FIDO2 devices at the same time. That's the realistic attack model for high-value operations.
For example, a Jito-style admin action:
- Squads vault: 3-of-5 council members must approve
- Each council member's wallet has Trana enabled
- A stolen council key can participate in the vote but cannot execute without a live device tap from that council member
The same model enterprise security has used for years — YubiKey + SSO — now applied to onchain execution.
Choosing Between Them
Use multisig when:
- Multiple parties share ownership or decision-making authority
- You need a governance trail with designated signers
- The action involves shared treasury or shared upgrade authority
- You want to distribute the risk across multiple independent actors
Use Trana when:
- A single wallet needs to prove live presence at execution time
- You want to protect against stolen/compromised keys acting without the owner's knowledge
- You need per-action enforcement without coordination overhead
- You want a second factor that is instant and device-bound
Use both when:
- High-value protocol operations (treasury, upgrades, admin actions)
- Enterprise security requirements
- You want governance + execution-time enforcement as independent defense layers