Server-side transaction enforcement for the Yield API.

Overview

Defense Mode is Shield running server-side — validating every outbound transaction inside the Yield API's pipeline. Transactions that fail validation are rejected before they reach the client.

Today, Shield Defense runs as an in-process library inside the Yield API. This gives the API an independently-versioned, hardened validation layer that catches tampering inside the API's own transaction construction — but it does not yet provide infrastructure-level isolation: a compromise of the Yield API process can in principle also reach Shield. Full isolation via a separate deployment is on the roadmap (see "Planned: Infrastructure Isolation" below).

Defense Mode is complementary to client-side Shield. Running Shield on the client validates that nothing was tampered with between the API and the signing flow. Running Shield server-side in Defense Mode validates that nothing was tampered with inside the API itself. For maximum security, run both.

How it works

In the standard Yield API flow, a client requests a transaction (e.g., deposit ETH into a Lido staking position), and the API constructs an unsigned transaction and returns it. The client then presents this transaction for signing.

With Defense Mode enabled, Shield intercepts every constructed transaction just before it's returned to the client:

Client Request
    ↓
Yield API constructs unsigned transaction
    ↓
┌─────────────────────────────────────┐
│  Shield (Defense Mode)              │
│                                     │
│  1. Decode calldata                 │
│  2. Validate against known pattern  │
│  3. Check receiver, owner, spender  │
│  4. Detect tampering                │
│  5. ALLOW or BLOCK                  │
└─────────────────────────────────────┘
    ↓                    ↓
  ALLOW               BLOCK
    ↓                    ↓
Transaction         Transaction rejected.
returned to         Client receives error.
client

Shield validates the transaction using the same pattern-matching engine as the client-side library — same validators, same vault registry, same calldata tamper detection. The difference is enforcement: in Defense Mode, a failed validation means the transaction is never sent.

Deployment architecture

Current architecture (in-process library)

Shield Defense today runs as the @yieldxyz/shield npm package embedded inside the Yield API:

• ShieldValidationService wraps shield.validate() calls within the API's transaction pipeline.
• Validation runs in the same process, in the same call stack, as transaction construction.
• No network hop, no separate deployment — validation adds single-digit milliseconds of overhead.
• Versioning is via the npm package; updates ship through the standard API deploy process.