Fireblocks now supports 15-minute (and longer) signing windows for institutional Solana transactions. This article explains why that matters for your protocol and the small change your team needs to make to support it.

Why this matters for your protocol

Institutional users, including funds, market makers, exchanges, and prime brokers, represent a significant and growing share of Solana volume. Many of them use Fireblocks as their wallet infrastructure. Until recently, one limitation kept institutions from operating smoothly with Solana protocols: transactions had to be signed and broadcast within roughly 60 seconds.

For a retail user, that is more than enough time. For an institution with a multi-signer approval group, it is often impossible. Every signer in the quorum has to review and sign within that window, or the transaction will expire.

The fix is a small, one-time change on your side. Once implemented, your protocol becomes accessible to Fireblocks' institutional customer base, joining a growing list of Solana protocols already on board:

Jupiter
Kamino
Orca
Jito
Marinade

Fireblocks customers using these protocols now operate with 15-minute signing windows instead of the previous 60 seconds. Fireblocks is rolling out support for additional protocols on an ongoing basis.

The problem: Solana's 60-second signing window

Every Solana transaction includes a reference to a recent blockhash. The blockchain rejects transactions whose reference blockhash is older than 150 blocks, or about 60 seconds on average. This is a core Solana design choice for replay protection, and it works well for most use cases.

For institutional workflows, it creates a hard ceiling:

Institutions use approval groups, among other security guardrails, to sign transactions. Approval groups can involve three or more signers, often across time zones.
Each signer needs time to review the transaction and apply governance controls.
If all quorum members do not sign within roughly 60 seconds, the blockchain rejects the transaction, regardless of how legitimate it is.

As a result, institutions on Fireblocks cannot use Solana protocols effectively. They end up working around governance controls, stitching together point-solution vendors, or leaving Solana volume on the table entirely.

The solution: durable nonce and a small protocol-side change

Durable nonce is a Solana-native mechanism designed for exactly this problem. Instead of anchoring the transaction to a recent blockhash, it anchors it to a nonce account that does not expire on a 60-second clock. Transactions using a durable nonce remain valid for as long as the wallet controlling the nonce allows.

Fireblocks automatically adds a durable nonce to Solana transactions that our customers initiate over WalletConnect on a select group of protocols. Fireblocks controls the effective expiration on our side, currently 15 minutes by default (facilitated by the WalletConnect relay), and extendable to two hours for specific workflows. This means the transaction does not remain valid indefinitely.

Important: For this to work end-to-end, protocols need to make a small adjustment. Many protocols today either reject modifications like the durable nonce instruction, treating them as suspicious mutations, or enforce their own short expiration period on top of Solana's. Both behaviors cause Fireblocks transactions to fail even when they would have otherwise been valid.

What you need to change

When a transaction comes from Fireblocks over WalletConnect, do not reject or invalidate it because it includes a durable nonce.
Extend any protocol-side timeout logic for these transactions, or remove it. Fireblocks handles the expiration on its side.

Everything else about your integration remains the same.

Step-by-step implementation

Identify the Fireblocks transaction

During the session proposal, the WalletConnect session exposes a session data structure that includes peer information. For Fireblocks, that data looks like this:

{

"peer": {

"metadata": {

"name": "Fireblocks",

"description": "...",

"url": "...",

"icons": "..."

}

For transactions associated with this session:

Do not invalidate the transaction because of alterations made by the wallet, particularly the addition of the AdvanceNonceAccount instruction.
Do not enforce your own expiry on these transactions. The WalletConnect session and Fireblocks' nonce account management handle expiration for you.

Get listed as a supported protocol

Once your changes are in place, contact the Fireblocks team so we can add your protocol to the supported dApps list for testing.

Typical implementation time ranges between a few hours and a few days, from zero to production, depending on how your transaction validation logic is structured. Fireblocks can support you during implementation and testing; reach out to Daniel Allon, Senior Product Manager at Fireblocks.

Frequently asked questions

Why is this beneficial for our protocol?

Direct access to Fireblocks' institutional customer base: funds, exchanges, market makers, and prime brokers who route substantial fund volumes through the platform. Several of these customers have specifically asked for protocols that support this solution. Implementing it signals to institutional users that your protocol is set up for their workflows, alongside protocols like Jupiter, Kamino, Orca, Jito, and Marinade.

Does this affect all the transactions our protocol handles, or just a subset?

It affects just Fireblocks transactions coming through WalletConnect. Your protocol can identify these using the WalletConnect session metadata combined with the Fireblocks wallet identifier. All other transactions, including retail wallets, other providers, and direct integrations, continue to behave exactly as they have until now.

Why 15 minutes? Can the window be longer?

15 minutes is Fireblocks' default expiration for durable-nonce Solana transactions, chosen to balance institutional signing workflows against limiting how long any transaction can remain valid. Fireblocks can extend this for specific workflows. In all cases, the expiration is enforced on Fireblocks' side, so protocols do not need to configure or manage it.

Who else is doing this, and where is it going?

Jupiter, Kamino, Orca, Jito, and Marinade are live. Additional Solana protocols are joining, and Fireblocks is working with the Solana Foundation to make this a broader ecosystem standard. Other providers may adopt a similar approach over time, so the integration work you do now is likely to serve future partnerships too.

Does durable nonce increase our risk?

Durable nonce is a Solana-native primitive, the same way transactions, accounts, and programs are Solana-native primitives. It has been used by malicious actors in the same sense that any part of the blockchain stack has, but the mechanism itself does not represent any vulnerability.

For transactions Fireblocks originates, invalidation logic happens on the Fireblocks side, not your protocol. Fireblocks defaults to a 15-minute expiration period, extendable to two hours for specific institutional workflows. Transactions do not remain valid indefinitely, and protocols do not take on additional risk by allowing them through.

Additionally, Fireblocks transactions go through our policy engine. Governance rules, approval quorums, address allowlisting, and transaction inspection all happen before the signature is even generated. By the time a Fireblocks transaction reaches your protocol, it has already been through significantly more scrutiny than a typical retail transaction.

Who creates and funds the nonce accounts?

Fireblocks does. Allocation, funding (rent-exemption), locking, advancing, recycling, and starvation prevention are all owned by Fireblocks. Neither your protocol nor the end user ever creates, funds, or tracks a nonce account.

Get in touch

For implementation, reach out to Daniel Allon, Senior Product Manager at Fireblocks. We will connect you with the Fireblocks team for a technical walkthrough, a testing environment, and support through rollout.