By Sebastian Higgs, Co-Founder and COO of Cordial Systems
Why ‘Trustless’ Blockchain Use Isn’t Truly Trustless
Blockchains like Ethereum are often praised for their trustless, decentralized architecture — and rightly so. But here’s the uncomfortable truth: Most users and systems don’t interact with the blockchain in a trustless way. Instead, they trust centralized infrastructure to relay blockchain information, introducing risks like third-party dependencies, trust assumptions, and information security vulnerabilities. Everyone has seen how this can go wrong: a standard operating procedure followed, "sign transaction" clicked, and wallets drained for millions or billions of dollars.
How Wallets Rely on Unverified Third-Party Data
Consider a typical interaction with DeFi through MetaMask Institutional.
Here’s what usually happens:
- The dApp asks the wallet to connect to the blockchain.
- The wallet queries a remote RPC provider (usually Infura or Alchemy).
- That RPC provider responds with JSON data like: your balance, smart contract state, nonce and gas price, chain ID
- The dApp or wallet constructs a transaction using this data.
- You sign the transaction based on the information displayed.
Here’s the catch: None of this data is cryptographically verified by your browser or wallet! You could be signing a completely different, and malicious, transaction. Or, the node could be lagging the lead block and producing stale data that impacts your transaction outcome. At Cordial Systems, we've responded to numerous RFIs and RFPs from significant traditional and digital asset finance players. Alarmingly, pre-engagement vendor due diligence rarely explores this risk, implying institutions are largely unaware of their exposure.
What Could Go Wrong?
The wallet is essentially acting as just a signature engine. So while institutions are asking about:
- “Does your wallet use multi-party computation (MPC) or multi-sig?”
- “How is the key created securely?”
They are looking to understand a bit about the key management security and signing modality however this just scratches the surface. It doesn’t address the risks we have been describing - Transaction Construction & Intent Integrity. Which is absolutely critical. Your typical browser wallet, and even MPC wallet, doesn’t understand the intent behind a transaction — only its bytes. Even with “simple” transactions like sending ETH or staking to a validator, your wallet provider is trusting 3rd parties to make critical decisions about what input data goes into a transaction. Either by trusting the RPC, dAPP, or validator provider to return truthful state and craft the transaction message without any assurances around transaction correctness or preservation of intent integrity.
When you click “Sign,” you may think you’re signing “Send 2 ETH to Alice.” However, what you’re actually signing is: “This is a 200-byte blob that we hope does what the UI says.”
This leap of faith and the critical severity of this risk cannot be emphasized enough. If your wallet provider operates this way today, it's not an oversight—it is a fundamental failure of your own risk management around understanding your wallet provider. Therefore, read this section again, do your research, and treat this risk as seriously as private key security, because it absolutely is.
Further examples and explanations on this risk were highlighted last year in my Unchained Crypto op-ed, emphasizing the urgent need for institutions to transition from blind signing to clear, intent-verified signing.
Why Patchwork Fixes Don’t Solve Transaction Integrity
There are incremental improvements which can patch up parts of a combined wallet and RPC operating in this way. A lot of them are in their infancy or prevent only partial improvements. Nonetheless, it is good to be aware of areas of active development and what is out there today:
- Use a light client like Helios to verify headers and state. Giving you some assurances on the JSON-RPC response.
- Similarly, zkRPC projects aim to provide cryptographic proofs for RPC responses.
- Tenderly can simulate transactions for safety checks. Transaction simulation is emerging as a strong control check and best practice.
- Some wallets allow custom RPCs or use your own provider. You can even host your own RPC to validate against the wallet providers RPC and monitor for divergences.
However, these are patchwork solutions — and they still fail to enforce intent. Even with verified data, a dApp could trick you into signing something you didn’t mean to.
How Cordial Systems Solves Transaction Integrity at the Root
Cordial Systems fundamentally shifts the paradigm from "trust then sign" to "verify, construct, then sign." Here's how:
1. Transaction Payloads Are Built Internally.
Cordial constructs the full transaction internally (e.g. “to”, “from”, “amount”, “chain ID”,
“asset”) without external dApp or RPC input. These are instead taken from internal resources, not unstructured input which is what most other wallets will do.This eliminates the risk of malicious dApps or spoofed calldata.
2. Policy Engine Enforces Intent
Cordial introduces a policy engine that defines exactly what a transaction is allowed to do. A policy might say:
“You can only send ≤ 2 ETH to address 0xValidatorA on Ethereum mainnet.”
“You can’t send USDC to any address unless it’s in your approved list.”
If a transaction doesn’t match a policy, it is blocked before it can be signed. This enforces intent integrity — only transactions that match explicitly approved behavior can be created and signed. Providing the highest assurances of transaction payload correctness.
3. RPC Use Is Isolated and Minimal
Cordial still uses external RPCs for some transaction inputs (e.g. fetching the nonce and gas price), none of which are security critical. These fields do not affect transaction intent or business logic — they are economic or operational. It is also possible to cross check these values, or in the case of the nonce increment deterministically (e.g. from prior transactions in the system). Users can also choose from preset gas strategies—such as average, fast, or very fast—based on their urgency to settle on-chain. The core meaning of the transaction—its actual effect—is never dependent on an RPC, a staking validator provider, or a dApp to build the transaction correctly.
4. Signing Is Local, Secure, and Policy-Bound
Signing is only permitted after the transaction message is built from known, controlled data. All of this data must pass through Cordial’s policy engine in order for the transaction to be created.
There is also a preceding step, not directly related to transaction construction, but equally important. The user who initiates the transaction intent—e.g., “Stake 32 ETH to my validator provider’s address”—must also be checked against the policy engine. This includes verifying their permissions and authentication, confirming they are who they say they are, and that they are authorized to perform this action.
At that point, the user signs the message request to their Cordial Treasury deployment using their credential (YubiKey, passkey, or another secure method). Any pre-defined approvers in the workflow see the exact same message, and—after undergoing the same access and permission checks—apply their signature to the request as well.
Only after all of this, and once the transaction message is verified for correctness, is it passed to the server level of the Cordial Treasury deployment for MPC signing. The servers, not mobile devices, hold the MPC key shares, exactly as recommended by NIST.
The outcome: you only sign what you meant to sign, and you can prove it.
Does Cordial Systems Solve the Problem? Yes—Here’s Why
Yes - Cordial Systems solves the risks identified around transaction construction and intent integrity.
- You no longer need to blindly trust a 3rd party to create transactions correctly
- You sign transactions that defined and validated by your system
- It’s trust-minimized with strong policy guardrails
Institutional Wallets Need Policy-Bound, Intent-Aware Signing
Transaction correctness and intent integrity are critical hidden risks which are usually not known to institutions when using their primary wallet provider. Instead unverified transaction data is blindly signed and you hope what you see on the screen is what you are in fact performing.
With Cordial Systems, the transaction is explicitly constructed inside the system, not by 3rd parties. These elements are modelled as “resources” in the policy engine. You cannot even reach the signing step unless the transaction matches a predefined policy rule - so you’re always signing what you meant to sign. On the other hand, other MPC wallets have their transactions created by 3rd party providers. They can configure workflow approvals (e.g. 2 of 3 signers must approve) but the intent of the transaction is not natively modeled or validated. Leaving them to be flying blind and focussed on governance of workflows rather than transaction semantics.
Is the Policy Engine a Risk? Only If You Centralize It
You might be thinking the policy engine is now a potential single point of compromise. Which is exactly the right thought process since, once again, all wallet providers have a centralised database with your policy rules. Typically, this is hosted by the vendor as well. Making them de facto your policy administrator and outsourcing that is another screaming failure of risk management which is completely avoidable. Read our piece about Cordial ‘s distributed control plane and thresholded policy enforcement point to learn more about another hidden risk in wallets and how to mitigate them.
