Transaction Integrity: How Figment Secures the Transactions You Sign

A signed blockchain transaction is final. There is no chargeback, no clearing window, no counterparty to call. Whatever your signer approved is what settles, which means the security of a staking operation is decided before the signature, not after it.

That makes the integrity of the unsigned transaction data your key signs (the “payload”) one of the most important controls in the whole flow. A transaction generated by an API, passed through a network, read by an operator, and approved in a custody platform crosses several trust boundaries on its way to a key. Every one of those boundaries is a place where the bytes could be swapped for bytes that look similar and behave very differently.

In September 2025, another staking provider was compromised in a way that turned this from a theoretical concern into an industry one. Figment’s infrastructure was not affected, and our non-custodial model means we never hold or move client assets. But “we were not affected” is not a control. The lesson we took from the incident was narrower and more useful: any system that generates transactions on a customer’s behalf has to be treated as a potential source of malicious transactions, including our own.

So we rebuilt that part of our stack on the assumption that it is hostile.

Observability On Every Transaction We Create

The design goal was to stop relying on process and people to guarantee that a transaction Figment produced is the transaction Figment intended to produce, and to make that guarantee cryptographic and observable instead.

Every protocol transaction our systems generate is now attested. A dedicated signing service produces a signature over the complete transaction data, byte for byte, and the values derivable from it, such as the source and destination addresses, the amount, and any other inputs. The signature covers the whole transaction, not a summary of it, so a single flipped byte anywhere in the transaction invalidates the attestation.

The controls around that signing key matter as much as the signature itself:

• The key lives in secure, auditable key management infrastructure. No engineer can read it in plaintext, and no one can use it to sign a transaction of their choosing.
• Signing happens in an isolated environment that employees cannot operate on directly. Changes are made in code and deployed through a controlled pipeline, not by hand on a running system.
• Every change to the code that generates or signs transactions requires multiple reviewers, plus automated security checks, before it can ship.
• Every use of the signing key is logged in the infrastructure we audit.

Consolidating transaction generation into a single hardened environment cost us some convenience. Delivering support for a new protocol transaction takes more effort than it used to, but that tradeoff was deliberate. Operational friction for us is a much better outcome than an unverifiable transaction for you. This holds true to Figment’s entire operating ethos: safety over liveness.

An attestation is only useful if someone checks it and something happens when the check fails.

We do not verify once at the point of generation and assume the transaction survives the rest of its journey intact. A transaction moves through several of our own services between the moment it is built and the moment it reaches a customer, and each of those hops is a place where tampering could be introduced by a compromised internal component. So the attestation is re-checked at multiple points along that internal supply chain, and each check compares the transaction in front of it against the signature produced at generation. Tampering anywhere inside our network has to survive every one of those checks, not just the first.

The systems are designed to fail closed and loud. A transaction whose attestation does not verify stops moving and pages our 24/7 security operations center, and the SOC triages it within minutes.

This is internal assurance. It is our verification of our own pipeline, running continuously, on the assumption that the pipeline could be compromised without anyone noticing operationally.

What Customers Can Verify Today 

Internal controls like transaction attestation are half the picture. The other half is what a customer can check independently, without taking our word for anything. Two mechanisms are available to every customer right now.

Transaction decoding before you sign

The Figment API returns encoded transaction data. Encoded data is exactly the kind of thing that gets approved without being read, and an operator comparing two hex strings by eye is not a control.

Our Transaction Decoder (docs) translates that data back into the instructions it contains: the operations being performed, the accounts involved, and the amounts. Ethereum, Solana, Cardano, and Sui are supported today, with more networks added based on customer demand. The decoder is also open source so you can run it inside your own environment and read the code that does the decoding.

Validator data verification on Ethereum

For Ethereum validators, the API returns a figment_signature alongside each validator’s public key. It is a signature over that pubkey by a key held inside Figment’s infrastructure, and it exists to answer a specific question: did this validator really come from Figment, or from something sitting between you and our API?

The question matters because a validator’s own BLS signature can be perfectly valid while the validator belongs to someone else entirely. Depositing 32 ETH against an attacker’s pubkey means rewards you never receive and withdrawal credentials you do not control.

Verification is a few lines with OpenSSL against Figment’s published public key, documented in Verifying Validator Data. If the result is not “Verified OK”, do not deposit.

Actions Customers Should Take Before Signing

Most of the remaining risk in a staking transaction sits in the last few steps, inside your environment. The practices below are what we recommend to institutional teams, and what the strongest integrations we see already do.

Check the transaction against your own intent. You know what you asked for: the amount, the destination, the validator, the account. Compare those values to what the decoded transaction says, and treat any difference as a stop condition rather than a formatting quirk.

Sign the right field. The field depends on the blockchain and the transaction type. Refer to the Figment docs for the field to sign for each network.

Ensure your custody platform enforces policy. Most institutional custody solutions can interpret a transaction before they sign it, presenting the contract call or program instruction, the destination, and the amount to an approver. Where that structured signing path exists, prefer it over raw signing, which reduces the platform to a signature over opaque bytes and gives your approvers nothing to review. Layer policy on top of it: destination allowlists, per-transaction limits, and multi-approver rules, so that no single compromised operator, or single compromised laptop, can move a transaction to signature. Figment publishes the API response fields each approach needs in our signing documentation.

Confirm addresses out of band. Validator addresses, withdrawal credentials, and staking contract addresses should be confirmed through a channel separate from the one that delivered the transaction. An attacker who controls one path rarely controls two.

Be suspicious of repetition. A request to re-sign a transaction that should already have settled, an unexpected retry, or a transaction that arrives slightly changed from the one you reviewed are all worth stopping for. Legitimate operational hiccups survive a five-minute pause. Attacks often do not.

The Standard We Hold Ourselves To

Non-custodial architecture means we cannot move your assets, and separation of duties means no Figment employee can either. Transaction attestation extends that principle one step further: not only can we not move your funds, we do not ask you to trust that the transactions we hand you are unmodified. We verify that continuously ourselves, we keep the evidence, and we page a human within minutes when something does not verify.

If you want to walk through these controls in detail, or talk about how they map to your own signing and approval workflow, your Figment account team can set that up. The decoder and the validator verification steps are documented and available today.

The post Transaction Integrity: How Figment Secures the Transactions You Sign appeared first on Figment.