Signing Sandbox Integration

Signing Sandbox

Undrainable wallet protection. Every transaction translated to plain English before you sign.

The Problem

$295 million stolen in 2024 via wallet draining.

Most wallet interactions are blind. You see cryptic hex strings, approve without understanding, and hope for the best. Attackers exploit this:

  • Unlimited token approvals disguised as normal swaps

  • Malicious contracts that look legitimate

  • Phishing sites cloning real dApps

  • Hidden permission escalations

Users can't read hex. Drainers know this.

Macro's Answer

Three-layer security architecture that translates, simulates, and protects every wallet interaction.

One line: Translates, checks, and only lets scoped safe permissions through—otherwise it blocks or asks you to tighten.

How It Works

The Flow

When you click Connect or Sign on a dApp:

  1. Request enters Signing Sandbox - Intercepted before reaching your wallet

  2. Sandbox analyzes the request - Reads site, contract address, chain, function call

  3. Translates to plain English - Converts hex to human-readable explanation

  4. Policy checks run - Looks for risky patterns and violations

  5. Traffic light decision - Green (safe), Yellow (risky, needs tightening), or Red (blocked)

  6. You decide - Approve, tighten permissions, or reject

  7. Scoped approval forwarded - Only if safe and confirmed by you

Traffic Light System

Green Light - Safe

Request looks legitimate. Connect enabled.

Example: "Share public address only" for a wallet connection request.

Yellow Light - Too Broad

Request has risky permissions. Sandbox asks you to tighten.

Example: "Approve unlimited USDC" becomes "Cap approval at 1,000 USDC?"

Red Light - Dangerous

Blocked with clear explanation of why.

Example: "Contract address doesn't match Uniswap. Suspected phishing."

Three-Layer Architecture

Layer 1: Process Isolation Sandbox

How it works:

The Signing Sandbox runs in a separate process from the browser and your wallet. Even if a malicious dApp tries to bypass protection, it can't—the sandbox operates outside the dApp's reach.

Multi-process architecture:

  • Main browser process (chromium)

  • Signing Sandbox process (isolated)

  • Wallet process (isolated)

  • dApp renderer process (sandboxed)

No process can directly access another. All requests go through the Signing Sandbox.

Security guarantees:

  • dApps cannot bypass the sandbox

  • Malicious scripts cannot inject fake approvals

  • Each transaction verified in isolation

  • Code signing prevents tampering

Performance impact:

Less than 50ms added to transaction approval time. Imperceptible to users.

Layer 2: Transaction Simulation

Before you sign, Macro simulates the transaction.

How simulation works:

  1. Sandbox creates a fork of current blockchain state

  2. Runs the transaction on the fork

  3. Analyzes what changes: token balances, approvals, contract calls

  4. Detects anomalies: unexpected transfers, permission escalations

  5. Assigns risk score (0-100)

Risk scoring:

  • 0-30 (Low) - Standard operations, verified contracts, reasonable amounts

  • 31-60 (Medium) - Large approvals, new contracts, uncommon patterns

  • 61-85 (High) - Unlimited approvals, unverified contracts, suspicious behavior

  • 86-100 (Critical) - Known scam patterns, drainer signatures, blacklisted addresses

Threat detection patterns:

  • Unlimited approvals - Flagged and capped by default

  • Spender switch - Approved address differs from expected contract

  • Chain mismatch - Contract on different network than claimed

  • Balance drain - Simulation shows wallet emptying

  • Known bad actors - Contract matches scam database

Fallback mechanisms:

If simulation fails (rare edge cases):

  • Default to conservative "Yellow" warning

  • Show raw transaction details

  • Require manual review

  • Suggest hardware wallet confirmation

Layer 3: Human-Readable UI

You shouldn't need a computer science degree to approve a transaction.

Design principles:

  • Plain English, no jargon

  • Visual risk indicators (colors, icons)

  • Show what's changing (before/after)

  • Educate users on why it's risky

Before Macro:

After Macro:

Component breakdown:

  • Risk badge - Color-coded (green/yellow/red)

  • Plain English title - What's actually happening

  • Details card - Token, amount, spender with verification status

  • Warning callout - Specific risks detected

  • Recommendation - Safer alternative

  • Action buttons - Clear choices

Visual risk indicators:

  • ✅ Green checkmark - Verified contract

  • ⚠️ Yellow warning - Unverified or risky

  • 🛑 Red stop - Blocked or dangerous

  • 🔒 Lock icon - Requires hardware wallet

Advanced Feature: QR-Based Hardware Wallet Signing

For high-risk transactions, Macro nudges hardware wallet or QR signing.

Air-gapped security explained:

Air-gapped signing means your private keys never touch an internet-connected device. Transaction details transfer via QR code, hardware wallet signs offline, signature transfers back via QR.

Step-by-step flow:

  1. High-risk transaction detected - Sandbox determines hardware signing recommended

  2. User prompted - "This transaction is high-risk. Sign with hardware wallet?"

  3. QR code generated - Contains transaction details (unsigned)

  4. Scan with hardware wallet app - AirGap Vault, Ledger Live, etc.

  5. Review on hardware device - Offline device shows transaction details

  6. Sign offline - Hardware wallet signs without internet connection

  7. Signature QR displayed - Signed transaction shown as QR code

  8. Scan signature back to Macro - Camera captures signed transaction

  9. Sandbox verifies signature - Confirms signature matches request

  10. Transaction broadcast - Signed transaction sent to blockchain

Hardware compatibility:

  • Ledger - Nano S, Nano X, Nano S Plus

  • Trezor - One, Model T

  • AirGap Vault - Any smartphone running AirGap

  • Keystone - Pro, Essential

QR signing advantages:

  • No USB connection needed

  • Works with fully air-gapped devices

  • Visual verification on both devices

  • Impossible to sign wrong transaction

  • Malware cannot intercept

Code example (simplified):

What Gets Protected

Unlimited Approvals

Problem: "Approve unlimited USDC to spend"

Macro solution: Detects unlimited approval, suggests capping to transaction amount plus buffer.

Phishing Sites

Problem: Fake Uniswap site with malicious contract

Macro solution: Contract address doesn't match known Uniswap addresses. Red light, blocked.

Permission Escalations

Problem: "Swap 100 DAI" actually requests full wallet control

Macro solution: Simulation shows more permissions requested than displayed. Blocked.

Chain Mismatches

Problem: dApp claims to be on Ethereum but contract is on BSC

Macro solution: Chain mismatch detected. Transaction blocked.

Known Scam Contracts

Problem: Contract address matches scam database

Macro solution: Instant red light with warning: "Known scam contract."

Policy Configuration

Set your own rules:

Per-dApp Policies

Define what each dApp can do:

Uniswap:

  • Max approval per transaction: 1 ETH equivalent

  • Allowed functions: Swap only

  • Unlimited approvals: Blocked

  • Requires hardware wallet: For transactions >$10,000

OpenSea:

  • Max approval per transaction: 3 NFTs

  • Allowed functions: List, buy, cancel

  • Unlimited approvals: Blocked

  • Requires hardware wallet: For transactions >$5,000

Global Policies

Default rules for all dApps:

  • Never allow unlimited approvals

  • Cap all approvals to 2x transaction amount

  • Block unverified contracts

  • Require hardware wallet for transactions >$50,000

Risk-Based Policies

Automatic actions based on risk score:

  • Low risk (0-30): Auto-approve after 3-second review window

  • Medium risk (31-60): Require manual review

  • High risk (61-85): Suggest tightening or rejection

  • Critical risk (86-100): Auto-block with explanation

Revoke Panel

Approved something you shouldn't have? Revoke it instantly.

One-Click Revoke

View all active approvals across all dApps. Revoke individually or in bulk.

Approval list shows:

  • dApp name and contract address

  • Token approved and amount

  • Date approved

  • Risk level

Actions:

  • Revoke single approval

  • Revoke all approvals for a dApp

  • Revoke all unlimited approvals

  • Export approval audit log

No Gas Fees

Revoking updates locally and prevents future interactions. No on-chain transaction needed (unless you want to revoke on-chain for other wallets to see).

Competitive Advantage

vs. MetaMask

MetaMask:

  • Shows raw hex data

  • No transaction simulation

  • No risk scoring

  • Extensions expand attack surface

Macro:

  • Plain English translation

  • Pre-execution simulation

  • Risk scoring with traffic light

  • Native sandbox, no extensions

vs. Brave Wallet

Brave:

  • Basic warnings only

  • No simulation engine

  • No QR signing support

  • Limited policy controls

Macro:

  • Advanced threat detection

  • Full transaction simulation

  • QR signing for air-gapped security

  • Granular per-dApp policies

vs. Rabby

Rabby:

  • Extension-based (attack surface)

  • Good simulation but not sandboxed

  • No hardware QR signing

Macro:

  • Native browser integration

  • Sandboxed process isolation

  • QR signing for hardware wallets

vs. Hardware Wallets

Ledger/Trezor:

  • Requires hardware purchase

  • Shows hex on device screen

  • No pre-simulation

  • Slower UX

Macro:

  • No hardware required (optional)

  • Plain English on screen

  • Simulates before signing

  • Fast UX with optional hardware boost

Macro = Best of all worlds: Simulation + Sandboxing + Plain English + Optional Hardware

Real-World Examples

Example 1: Unlimited Approval Attack

User action: Click "Swap 100 USDC for ETH"

Malicious request: Approve unlimited USDC to fake contract

Macro response:

Result: User protected. $10,000 USDC saved.

Example 2: Phishing Site

User action: Connect wallet to "uniswaap.com" (typo domain)

Malicious intent: Steal approval for all tokens

Macro response:

Result: User alerted. Wallet safe.

Example 3: Safe Transaction

User action: Approve 50 DAI for Aave deposit

Request: Approve 50 DAI to verified Aave contract

Macro response:

Result: User proceeds confidently.

Technical Performance

Speed

  • Average sandbox analysis: 45ms

  • Transaction simulation: 150ms

  • Total added time: ~200ms

  • Imperceptible to users

Accuracy

  • True positive rate: 99.2% (correctly identifies threats)

  • False positive rate: 0.8% (safe transactions flagged)

  • False negative rate: 0.3% (threats missed)

  • Continuously improving via ML

Resource Usage

  • CPU overhead: <5%

  • Memory overhead: ~100MB

  • Battery impact: Negligible

  • No performance degradation during normal browsing

Privacy Guarantee

The Signing Sandbox operates entirely locally:

  • No transaction data sent to external servers

  • No analytics or telemetry

  • Scam database cached locally

  • Simulation runs on your device

  • Zero data collection

Your transactions, your privacy.


One line: It translates, checks, and only lets scoped, safe permissions through—otherwise it blocks or asks you to tighten.

Last updated