The verification layer between your Ledger and a stale RPC
Defimec intercepts the signing request before your Ledger sees it — probing the RPC for a live chain-ID response and decoding the calldata. If the RPC returns the wrong chain, the session halts. Nothing reaches the network.
Platform Architecture
How the routing layer works
Every signing request passes through three verification gates before your Ledger is asked to sign anything.
Step by Step
The full signing flow
Connect Ledger to Defimec
Open Defimec and connect your Ledger via WebUSB or Bluetooth. One session registers all three chain paths — you don't connect separately per chain.
Configure chain RPC endpoints
Add your preferred RPC endpoints for each chain. Defimec stores these with per-chain chain-ID assertions — mainnet-beta (Solana), 0x2105 (Base), 0xa4b1 (Arbitrum One) — locked at config time.
Initiate a transaction
Trigger your swap, approval or transfer from your dApp as normal. Defimec intercepts the signing request via its browser extension or desktop relay.
RPC health probe fires
Before passing anything to Ledger, Defimec calls eth_chainId (or Solana getVersion) on the configured RPC and compares to the locked assertion. Mismatch = hard stop.
Calldata decoded for display
The transaction calldata is decoded against the ABI (ERC-20, common DEX interfaces, EIP-712 typed data). You see function name, parameters, and amounts — not raw hex.
Sign on Ledger, broadcast confirmed
Your Ledger signs the verified, decoded transaction. Only after your physical confirmation does Defimec forward the signed payload to the RPC endpoint.
0000000000000000000000004a3f2b...
0000000000000000000000007f21c9...
0000000000000000000000000000000000001388
from: 0x4a3f…2b
to: 0x7f21…c9
value: 5,000 USDC
)
chain-ID: 8453 (Base) ✓
RPC health: OK ✓
RPC Health Verification
A wrong chain ID is a hard stop, not a warning
A stale or poisoned RPC returning the wrong chain ID is the most direct path to a mismatch drain. Defimec does not surface it as a dismissable alert — it halts the signing request before the Ledger prompt fires.
The probe runs per signing request, not only at session start. An RPC that was healthy when you connected can degrade mid-session. Defimec catches that on the next transaction — before your hardware signs anything.
eth_chainId called on configured RPC
Defimec calls the chain ID method on your configured endpoint. Expected response: 0x2105 for Base mainnet.
Response: 0x38 (BSC) — mismatch
RPC has drifted or been poisoned. Returned chain ID doesn't match the locked assertion. Signing request halted immediately.
User alerted — no transaction broadcast
Defimec surfaces the mismatch to you before any signing prompt appears. You fix the RPC config, retry. Nothing has reached the network.
Calldata Decoding
See what you're signing before you sign it
Raw calldata is unreadable to a human. Defimec decodes the function selector and parameters so you can verify intent before your Ledger confirms.
ERC-20 transfers & approvals
transfer, transferFrom, approve — decoded to token symbol, from/to addresses, and amounts. No more signing blind approvals to unknown spenders.
DEX swap calldata
Uniswap v2/v3, Curve, and common DEX router selectors decoded to human-readable swap parameters: token pair, amounts, slippage tolerance, deadline.
EIP-712 typed data
Structured signing requests decoded to readable field names and values. chainId field verified against your locked chain assertion before display.
Get started
One Ledger. Three chains. No guesswork.
Early access is open. Connect your Ledger, configure RPC endpoints for your chains, and every signing request goes through chain-ID verification and calldata decode before you approve.