​

How SecureSign Prevents Malicious Transactions

The Refract SecureSign protocol is a defense-in-depth security environment designed to protect users from a wide range of common Web3 attacks, including phishing, transaction tampering, and dApp impersonation. It achieves this by creating a trusted, sandboxed path between the user’s intent and the final signed transaction.

​

The Core Problem: Blind Signing

In many wallet systems, users are presented with a hexadecimal string or a raw contract interaction and asked to sign it. This is “blind signing,” and it’s dangerous. A malicious dApp can present a UI that says “Claim Airdrop” while crafting a transaction that actually drains the user’s wallet.

SecureSign solves this by ensuring what you see is what you sign (WYSIWYS).

​

Key Security Mechanisms

​

1. Application Identity Verification

• Problem: A malicious site could clone a popular dApp’s frontend to trick users into connecting their wallet.
• Solution: Every dApp that integrates with Refract must register and receive a unique appId. When a transaction is requested, the appId and the human-readable dappName are passed along with the payload. The Refract Passport signing UI always displays the verified application name and logo, so the user can be confident about which dApp is requesting the signature. Cross-application transaction injection is impossible due to this strict binding.

// A transaction request is always bound to an app
const requestBody: AuthBody = {
  // ...
  appId: "your-dapp-identifier", // Verified on Refract's backend
  dappName: "Your DApp Name",    // Displayed to the user
};

​

2. Transaction Simulation and Human-Readable Previews

• Problem: A transaction payload can be complex and opaque, hiding malicious operations.
• Solution: Before the signing prompt is ever shown, Refract’s backend and the Passport client simulate the transaction. The results of this simulation are then presented to the user in a clear, easy-to-understand format.

This preview makes it immediately obvious if a transaction is not what the user intended, such as a wallet-draining request disguised as a simple airdrop claim.

​

3. Single-Use Nonces to Prevent Replay Attacks

• Problem: An attacker could capture a signed transaction request and “replay” it later to repeat the action without the user’s consent.
• Solution: Every signing request is associated with a unique, single-use identifier called a nonce.

The nonce is generated by our backend, has a short time-to-live (typically 2 minutes), and is deleted from our cache immediately after the transaction is either approved or rejected. Any subsequent request using the same nonce will fail.

​

4. Payload Integrity

• Problem: A man-in-the-middle attacker could modify a transaction payload after it leaves the dApp but before it’s signed by the user.
• Solution: The transaction payload is sent to our backend for storage against the nonce. The Refract Passport fetches this payload directly. The dApp does not have write access to this storage. When the user approves, the signing engine reconstructs the transaction from this securely stored, immutable payload, guaranteeing that what the user saw in the preview is exactly what gets signed.