Trust signals in web3 interfaces

People using a dApp are asked to hand over control of real money to code they can't read, through an interface built by people they've never met. Badges, shields and a confident tone don't change that. What changes it is giving people claims they can check, and keeping every claim the interface makes accurate.

This guide covers the signals that hold up under scrutiny, how to present them, and the patterns that quietly erode trust even when nothing is technically wrong.

Trust comes from checkable claims

A useful test for any trust signal: could a skeptical user verify it in a few minutes? "Secure and audited" fails. "Audited by a named firm, report linked, covering this commit" passes. "Non-custodial" fails on its own. "You can withdraw at any time directly from the contract at this address" passes, if it's true.

The rest of this guide applies that test to the most common signals.

Contract addresses people can find

Every contract the app asks people to interact with should be listed somewhere public and easy to find, such as a security or developer page, with:

• The contract name as used in your docs and code.
• The address, in full, per chain, with a link to the block explorer.
• Whether the source code is verified on that explorer.
• Whether the contract is upgradeable, and who controls upgrades.

Then make the interface consistent with that list. When a transaction is about to call a contract, the review screen can show its name and a short address that matches the page. People who check will find the same address in three places: your docs, your interface and their wallet.

Audits, linked properly

An audit is a review of specific code at a specific time. It's a useful signal when presented that way, and misleading when it becomes a logo in the footer.

Say what wasn't covered. If a new contract went live after the last audit, the security page should say so. People who read audits notice gaps, and a gap you disclosed costs far less trust than one they discovered.

Every fee, before the confirmation

Hidden or late-appearing fees are one of the fastest ways to lose trust. Show every cost on the review screen, before the wallet opens, each with its own label: the network fee, any app or protocol fee, and price effects like price impact and minimum received. If a fee goes to you, say so.

Then make sure the wallet shows the same thing. If your interface says "Fee 0.25%" and the transaction actually sends a different amount, people who compare will find it, and the difference reads as deception even when it's a bug. Fee presentation is covered in showing gas fees people understand.

Consistent identity everywhere

Phishing sites copy your interface. What they can't copy easily is your consistency. Keep the same name, logo and domain across the app, docs, social profiles and, importantly, the places your app's identity appears in the wallet:

• Wallet connection prompts show your domain, and often your site's icon or title, so keep those accurate.
• The name in your EIP-712 signing domain appears in signature prompts.
• Sign-In with Ethereum messages include your domain, which wallets can compare with the site making the request.

If these all say the same thing, a mismatch becomes a visible warning sign for anyone on a lookalike domain. Use one canonical domain and avoid sending people to many different subdomains for core actions.

Readable signatures

Every signature request is a moment where the person decides whether to trust you. An opaque hex string asks for blind trust. A structured EIP-712 request with readable field names, explained in your interface first, asks for informed consent. Approvals and permits in particular should state the token, the amount and the spender in words before the wallet opens. Making signature requests readable covers the details.

Honest disclosure of control

Many protocols have admin keys, upgradeable contracts, pause functions or a multisig that can change parameters. That's often reasonable. Hiding it isn't. A short plain-language section answers the questions careful users ask:

Who can change this protocol?

The contracts are upgradeable by a 4-of-7 multisig. Upgrades go through a 48-hour timelock, so changes are visible on-chain before they take effect. Signers are listed on this page.

The numbers here are an example. The point is that the answer is specific and can be checked against the chain.

What erodes trust

Some patterns hurt even when they're common. Most of them are pressure or ambiguity:

• Urgency and countdowns on financial actions. Real deadlines exist, but invented ones push people to skip the checking you want them to do.
• Unlimited approvals by default. Request exact amounts, and offer unlimited as an informed choice.
• "Verified" badges with no defined meaning, including check marks on tokens you never reviewed. See fake tokens and spoofed logos.
• Partner logo walls that overstate relationships. Showing a project's logo implies a relationship; make sure it's real and described accurately, as covered in partner and integration logo walls.
• Broken or dead links on the security page. A 404 where the audit should be is worse than no link.
• Any request for a recovery phrase, anywhere, for any reason. Say clearly and often that you will never ask for it.
• Inconsistent numbers between your interface, the wallet and the explorer.

A short review

Before a launch, go through the app as a skeptic would. Find the contract addresses from the homepage in under a minute. Open the audit link and check it covers what's deployed. Compare every number on the review screen with the wallet prompt. Read each signature request as if you'd never seen the app before. Anything that takes too long to find, or doesn't match, is a trust problem waiting to be noticed.