Overview
The new Program Calls capability replaces the older Typed Message flow for Solana dApp interactions, giving you clearer transaction decoding, stronger governance, and improved tracking.
This capability presents a new set of improvements. Decoded transactions are significantly improved, so you can clearly view and approve their contents before they are broadcasted.
Program calls are now fully supported for both API and dApp flows.
When connecting to a Solana dApp (e.g. Jupiter) through WalletConnect, Fireblocks decodes the program call, applies the relevant policies, and displays the transaction details clearly in the Console and Mobile App.
With this feature, you can:
- Submit Solana transactions for signing via dApps in a secure and clear way
- Have clarity on transaction contents on both mobile and Console
- Gain improved governance over Solana dApp interactions
- Benefit from full status tracking, including state changes:
- SIGNED → COMPLETED / FAILED
Main advantages
Sign-only transactions provide developers and dApps with the ability to:
- Integrate with dApps: Solana dApps operate through program calls. Fireblocks now decodes these program calls, applies program-call policies, and displays the decoded transaction details to end users in the Mobile App and Console.
- Maintain visibility: Regardless of transaction finality status, you still get full lifecycle visibility within Fireblocks.
- Improved status tracking: Signed transactions now move to SIGNED status once the signing flow finishes, instead of automatically moving to COMPLETED like they used to. This provides clearer lifecycle visibility compared to previous raw-signing flows.
Nonces
Durable nonce support depends on the flow:
- For API-based Solana transactions, you can use durable nonces to extend transaction validity.
- For dApp-based transactions (via WalletConnect), Solana’s default validity applies: ~150 blocks (about 90 seconds). Transactions must be signed by all approvers within that time, or they will expire.
The Solana blockchain architecture and the standards established within the Solana dApps ecosystem dictate that the broadcasting to the Solana blockchain would not be done by Fireblocks but by the dApps themselves, following the transaction signing.
A typical flow looks like that:
Transaction initiation → signing on Fireblocks → Broadcast to Blockchain by the dApp
A possible scenario in that flow is the transaction is signed but never broadcasted by the dApp. In these cases the transaction would also become invalid after 90 seconds and would have to be created again by the user.
Policies
Solana dApp transactions on Fireblocks use Program Calls and therefore they utilize the Program call policy type (rather than the Typed message policy type).
To have the correct policy rules in place and execute Solana dApp transactions securely, users have to create new Solana Program call rules tailored to their workflows. Note that old Typed Message policy rules originally set up for Solana dApp interactions could be deleted going forward.
dApp interactions blocked by policy?
Make sure to create Solana Program call policy rules that suit your operations; otherwise, your dApp interactions will be blocked by the policy engine.