An intent is a predefined action that a user specifies. It abstracts a multi-step operation into a single declarative request. In blockchain, wallets, staking providers, and DeFi platforms resolve intents into chain‑specific transactions. Examples include:

‍

• Wallets: transfer
• Staking providers: stake, delegate, claim rewards
• DeFi APIs: swap, add/remove liquidity
• Governance: vote, delegate, propose

‍

Intents can be submitted through an API, a browser, or mobile application. Before submitting an intent, users should be authenticated and authorized. In an institutional setting, intents should also pass policy checks and multi‑stage approvals to enforce a strict “what you see is what you sign” principle.

‍

From Intent to Raw Transaction

An intent is transformed into a chain-specific transaction that ultimately gets signed. Between intent creation and raw-transaction building, an attacker may try to alter the intent’s data - changing the amount, destination address, fee parameters, or the methods/operations invoked (especially with smart contracts).

‍

That’s why controls have to be in place to ensure that the risk of the intent being altered is reduced. Those include:

‍

• Intent confirmation: The initiator confirms, preferably through a different trusted device, that the displayed intent matches the original one.
• Multi-stage approvals: Additional users sign off per policy. This protects against both dynamic tampering and a rogue initial intent.
• Policy engine: Enforces defined rules and governance (e.g. spending limits, allow/deny lists, approvers, velocity).

‍

Once built, the transaction is ready to be signed. For example, in a staking flow the API returns an unsigned raw transaction, with the necessary smart contract call data, after the user submits an intent. The user then signs and broadcasts it. Here too, an attacker could attempt to modify raw transaction data so that, even if the users approved and validated the intent, the signed data no longer matches.

‍

Several major hacks, including the recent one, exploited exactly this gap between intent and signing. Therefore, right up to the moment of signing, the transaction must still reflect the original intent.

‍

That’s the role of transaction validation: decode the raw transaction, compare it with the intent, and block signing if they diverge.

‍

Trusting Transaction Data

There are several options to validate transactions. In a staking flow, a user can call the API to decode a raw transaction, retrieve the fields, and perform the check. Or submit the raw transaction with the intent data to the API for verification and matching. Finally, the user might verify the transaction locally using an open source SDK or program. Server‑side options face similar threats as the transaction‑crafting module, but you can mitigate them by isolating validation and decoding components - ideally in attested secure‑enclave environments. With industry starting to pay much more attention to transaction validation standards start to be developed such as ERC-7730.

‍

In custody-tech solutions, intent and transaction crafting are often part of the same application. The solution here is to reduce the trusted computing base (TCB) and perform multiple validations in a quorum-like setup. A natural fit is multi-party computation (MPC). In such a scenario, MPC nodes (players) would validate the transaction against the intent before performing its part of the protocol. If all players agree on validity, the transaction is signed following the MPC protocol.

‍

An ultimate step is transaction simulation, which previews the onchain state change. If the state change does not correspond to the intent, the signing should be refused. Once a signed transaction is broadcast, there is no way back.

‍