> ## Documentation Index
> Fetch the complete documentation index at: https://yieldxyz.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Shield

> Validate every unsigned transaction from the Yield API against verified patterns before it reaches your signing flow.

Shield is a zero-trust validation layer for yield.xyz integrations. It verifies every unsigned transaction returned by the Yield API before you present it for signing: a small modification to a transaction can redirect funds to an attacker's address, trigger unintended contract calls, or drain token approvals.

Shield sits between transaction construction and signing: the Yield API builds an unsigned transaction, Shield validates it against the yield's expected pattern, and only then do you sign. It decodes each transaction into a typed structure (ABI decoding for EVM, instruction parsing for Solana, TronWeb decoding for Tron), validates each decoded field against a verified template for the specified yield integration, and re-encodes EVM calldata to detect byte-level tampering. Anything that deviates from the expected pattern is flagged immediately.

<CardGroup cols={2}>
  <Card title="GitHub repository" icon="github" href="https://github.com/stakekit/shield">
    Source code, issues, and release artifacts at stakekit/shield
  </Card>

  <Card title="npm package" icon="npm" href="https://www.npmjs.com/package/@yieldxyz/shield">
    TypeScript library: @yieldxyz/shield
  </Card>
</CardGroup>

## What Shield checks

| Check | What it verifies |
| - | - |
| Transaction type | Detects deposit, withdrawal, approval, wrap, unwrap, stake, swap or claim from the function selector and target contract |
| Target contract | `to` must be a whitelisted address: an embedded vault registry for ERC-4626 vaults, fixed addresses for Lido and Rocket Pool |
| Parameters | Receiver, owner and spender must match the user's address, or an explicitly declared `args.receiverAddress` for custodial flows |
| Tampering | Decoded EVM calldata is re-encoded and compared byte for byte, so appended or altered bytes are flagged |
| Chain scope | Vaults are keyed by `chainId:address`, so an address valid on one chain is not accepted on another |

Shield covers EVM, Solana and Tron transactions for the yields it has validators for. Check coverage per yield with `isSupported(yieldId)` or list it with `getSupportedYieldIds()`; see [Shield features](/documentation/platform/shield/features) for the validator matrix. In the client library, unsupported or unrecognized transactions fail validation rather than passing; server-side, yields without a validator are currently skipped.

## Where it runs

| Where | How | Page |
| - | - | - |
| Your client or backend | The `@yieldxyz/shield` TypeScript library, or standalone binaries that take the same request as JSON over stdin (Go, Python and Rust guides) | [Integration](/documentation/platform/shield/integration) |
| Inside the Yield API | Defense Mode: server-side validation before the transaction is returned. Runs in Monitor (validate and log) by default; a project can be set to Block, which rejects failed transactions with an error | [Defense Mode](/documentation/platform/shield/defense-mode) |

Client-side and server-side Shield check different things: client-side validation covers the path from the API to your signing flow, server-side validation covers the API itself. They can run together.

## The call

```typescript theme={null}
import { Shield } from '@yieldxyz/shield';

const result = new Shield().validate({ unsignedTransaction, yieldId, userAddress });
if (!result.isValid) throw new Error(result.reason);
```

`validate` returns `isValid`, a human-readable `reason` when it fails, optional `details`, and the `detectedType` it identified. Your integration decides what to do with a failure: block signing, warn the user, or log it for review.

## Why validate before signing

Every layer between transaction construction and signing is a place a transaction can be altered. In a past infrastructure compromise, an attacker modified API responses so deposit transactions sent funds to the attacker's address; the transactions were structurally valid ERC-4626 calls and executed on-chain. Shield checks the transaction independently of whatever produced it. It narrows this class of risk; it does not remove every risk, and it only validates the patterns it has validators for.

## Next steps

<CardGroup cols={2}>
  <Card title="Security overview" icon="shield" href="/documentation/platform/shield/security-overview">
    How Shield fits into the wider security suite
  </Card>

  <Card title="Shield features" icon="list-check" href="/documentation/platform/shield/features">
    Coverage matrix, validators, decoding, and validation errors
  </Card>

  <Card title="Shield integration" icon="plug" href="/documentation/platform/shield/integration">
    TypeScript library, standalone binaries, and Go/Python/Rust guides
  </Card>

  <Card title="Defense Mode" icon="shield-halved" href="/documentation/platform/shield/defense-mode">
    Server-side enforcement inside the Yield API
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.