# Signing Sandbox Integration

## <mark style="color:purple;">Signing Sandbox</mark>

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.

### <mark style="color:purple;">How It Works</mark>

#### 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."

### <mark style="color:purple;">Three-Layer Architecture</mark>

#### 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:**

```
Function: approve(address,uint256)
Parameters: 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D, 115792089237316195423570985008687907853269984665640564039457584007913129639935
```

**After Macro:**

```
🟡 MEDIUM RISK

Uniswap Router wants to spend your DAI

What's being approved:
• Token: DAI
• Amount: Unlimited
• Spender: Uniswap V2 Router (verified)

⚠️ Warning: Unlimited approval detected

Macro recommends:
Cap this approval at 1,000 DAI

[Cap to 1,000] [Keep Unlimited] [Reject]
```

**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

#### <mark style="color:purple;">Advanced Feature: QR-Based Hardware Wallet Signing</mark>

**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):**

```javascript
// High-risk transaction detected
if (riskScore > 85 || amount > userThreshold) {
  // Generate QR code with transaction details
  const qrData = {
    to: contractAddress,
    value: amount,
    data: encodedFunction,
    chainId: networkId
  };
  
  showQRCode(qrData);
  
  // Wait for signed transaction from hardware wallet
  const signedTx = await scanQRSignature();
  
  // Verify signature matches request
  if (verifySignature(signedTx, qrData)) {
    broadcastTransaction(signedTx);
  }
}
```

### <mark style="color:purple;">What Gets Protected</mark>

#### 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."

### <mark style="color:purple;">Policy Configuration</mark>

**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).

### <mark style="color:purple;">Competitive Advantage</mark>

#### 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

### <mark style="color:purple;">Real-World Examples</mark>

#### Example 1: Unlimited Approval Attack

**User action:** Click "Swap 100 USDC for ETH"

**Malicious request:** Approve unlimited USDC to fake contract

**Macro response:**

```
🛑 CRITICAL RISK - BLOCKED

Contract wants unlimited access to your USDC

What's wrong:
• Contract address: 0x1234... (UNVERIFIED)
• This is NOT Uniswap
• Unlimited approval detected
• Known scam pattern

This transaction has been blocked.

[Learn Why] [Report Scam]
```

**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:**

```
🛑 DANGER - Suspected Phishing

This site is NOT the real Uniswap

Warning signs:
• Domain: uniswaap.com (typo)
• Real Uniswap: app.uniswap.org
• Contract address doesn't match known Uniswap
• Site reported by 47 users

Do NOT connect your wallet.

[Block Site] [Report Phishing]
```

**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:**

```
✅ LOW RISK - Safe to Approve

Aave Protocol wants to use your DAI

What's being approved:
• Token: DAI
• Amount: 50 DAI ($50)
• Spender: Aave V3 (✅ Verified)
• Purpose: Lending deposit

This looks safe. Standard Aave operation.

[Approve] [Review Details]
```

**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.