Note

The Website Is Not the Contract: Who You Trust Before You Sign

Between a click and a signature sit a domain, a host, an RPC node and a wallet preview. Each can be swapped or can mislead on its own; the contract only enforces what you sign.

2026-11-13 · dex, frontend, ipfs, dnslink, rpc, json-rpc, transaction-simulation, token-approval, phishing, verify-before-trust

Listen · 7 min · AI voice

Dark CryptoDecentral hex mesh with a vertical stack of hexagonal panes: a small bronze cell at the bottom, a solid teal cell at the top, and three translucent panes between them, one of which glows bronze instead of teal, as if swapped; no text.

"Using a protocol" usually means opening a website, clicking a button and signing something in a wallet. The contract was only the last stop. Before it sat a domain name, a hosting setup, a node answering questions about the chain, and a wallet predicting the outcome.

Thesis, stated once: each layer between the user and the contract (website, hosting, RPC node, the wallet's preview) can be swapped out or can lie independently. Knowing which one you are trusting at each step is a core safety skill.

The contract is the rules; the website is a form

A frontend is the website or app that reads on-chain data and builds transactions for your wallet to sign; the protocol is the deployed contracts that actually enforce the rules, so the two are trusted separately.

Ethereum's documentation describes a smart contract as code that is "not controlled by a user" and that runs as programmed. A frontend has no such property. Whoever controls its code, hosting or domain can change what transaction it prepares at any time, without touching the contract, which enforces whatever you sign. If a hijacked page prepares a transfer to an attacker, the contract executes it faithfully.

A phishing domain is a lookalike web address, often a typosquat that differs from the real one by a character or two, that serves a copied frontend built to get your signature on the attacker's transaction.

Ethereum's security page puts it plainly: "Always check that you are on the right domain." The real domain is not automatically safe either. Whoever controls its DNS records decides where it points. A US CISA directive on DNS tampering describes attackers who obtained the login for an account that can change DNS records, then replaced a service's address with one they controlled: the wrong site under the right name.

IPFS: unchanged is not the same as honest

An IPFS-hosted frontend is a website published as content-addressed files on IPFS and fetched by a CID derived from a hash of its content, so anyone can check the files are unchanged, though not that the code is honest.

IPFS documentation explains that a CID is created by "computing a cryptographic hash of the block's data" and combining it with format information. Altered files produce a different CID; that is integrity, not intent. A malicious build has a perfectly valid CID of its own, so the question "which CID is the real release?" still has to be answered by a source you already trust.

Two convenience layers bring trust back in. Browsers and tools without native IPFS support reach it through an HTTP gateway, and by default, the gateway reference says, "all validation happens on the gateway, and clients trust that the gateway is correctly validating." Only clients that request verifiable response types can check the bytes themselves. And DNSLink maps a readable domain to a CID through a DNS TXT record; "because you can edit your DNS records," the name can point to new content. Useful for updates, it makes DNS the point of trust again.

RPC endpoint: the node you see the chain through

An RPC endpoint is the node address a wallet or website queries over JSON-RPC to read balances and contract state and to broadcast signed transactions; it sees those requests, and it can refuse them or misreport the answers.

Every Ethereum client implements one JSON-RPC specification, because an application "must connect to an Ethereum node" to read data or send transactions. Methods such as eth_getBalance and eth_call read state; eth_sendRawTransaction broadcasts. Ethereum's run-a-node page states the costs of using someone else's node: personal information "such as your IP address and which Ethereum addresses you own" can leak to it, and it "could choose to refuse transactions from specific IP addresses, or transactions that involve specific accounts." Its answers about state are taken on trust. The network-privacy note covers the same issue for Bitcoin and Monero nodes.

Transaction simulation: a preview, not a promise

Transaction simulation is a dry run of a transaction against the chain's current state that shows the likely result before you sign; it is a preview rather than a guarantee, because state can change before the transaction is included.

The building block is a call like eth_call, which "executes a new message call immediately without creating a transaction on the blockchain," against a chosen block such as "latest" or "pending". After you sign, the transaction waits in a pool of pending transactions until a validator includes it, and block producers can include, exclude and reorder transactions. Other transactions can land first and change the state the preview assumed. A contract whose result depends on that state, or on details of the block it finally lands in, can then produce a different outcome from the preview. And the simulation runs on some node, often the same RPC endpoint, so it is only as honest as that node.

Token approvals: what you sign beyond the trade

A token approval is an on-chain permission, set through an ERC-20 approve call, that lets another address spend your tokens up to an allowance; it stays in force after the trade that prompted it, until changed.

EIP-20 defines approve as allowing a spender "to withdraw from your account multiple times, up to the _value amount," with transferFrom "allowing contracts to transfer tokens on your behalf." Ethereum's guide on revoking access warns that an unlimited allowance can be used "even if you have withdrawn your funds from their platform." Approvals are not inherently suspect; the Autonomi pay-once note describes a client that documents granting its payment vault an unlimited allowance. They are standing permissions that belong in any reckoning of what a key has authorised.

Layer by layer

Layer	What it can do wrong	What checking it looks like
Domain and DNS	A lookalike or hijacked name serves a copied site	A saved address, spelling compared character by character, announcements cross-checked on channels the project already uses
Frontend code	Builds a different transaction from the one you meant	Reading what the wallet shows rather than the page; contract addresses compared with independently published ones
IPFS hosting and gateway	Serves altered files, or a DNSLink points elsewhere	The CID compared with one the project publishes; verifiable retrieval where available
RPC endpoint	Logs IP and addresses, refuses broadcasts, misreports state	Knowing whose node it is; your own node, or one chosen deliberately
Wallet preview	Outdated by inclusion time; state- or block-dependent results differ	Treated as an estimate; recipient, amount and spender still read
Token approval	Leaves a standing permission to spend	The spender and amount read before signing; old allowances reviewed with tools you verify yourself

What this is not

This is not a review or ranking of wallets, websites, node providers or simulation tools, and it names none to use. It is not a guide to swapping or trading, and says nothing about prices, fees or returns. It does not call any layer safe or unsafe in general; each can fail on its own. CryptoDecentral has not tested any product described here; mechanisms are as documented on 13 November 2026. It is not legal advice.

The one-line takeaway: the contract only enforces what you sign; every layer that helped you decide what to sign is a separate thing you chose to trust.