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

> Shield's validation coverage, tamper detection, local decoding, runtime support, and the validation errors you can expect.

This page covers what Shield validates and how: the yields it has validators for, the checks it runs on each transaction type, local decoding, runtime options, and the error messages it returns. For installation and the core API, start with the [Shield overview](/documentation/platform/shield).

## Validation coverage

Shield ships two kinds of validators: dedicated validators for specific yield integrations, and a generic ERC-4626 validator backed by an embedded vault whitelist.

### Dedicated validators

| Chain | Yield ID | Description | Transaction types |
| - | - | - | - |
| Ethereum | `ethereum-eth-lido-staking` | Lido ETH staking | STAKE, UNSTAKE, CLAIM\_UNSTAKED |
| Ethereum | `ethereum-eth-reth-staking` | Rocket Pool ETH staking | STAKE, APPROVAL, SWAP |
| Solana | `solana-sol-native-multivalidator-staking` | Native SOL staking | STAKE, UNSTAKE, WITHDRAW, WITHDRAW\_ALL, SPLIT |
| Tron | `tron-trx-native-staking` | TRX staking, resource management, and voting | See the Tron accordion below |

### Generic ERC-4626 validator

The ERC-4626 validator covers a whitelist of vaults across these protocols: Angle, Curve, Euler, Fluid, Gearbox, Idle Finance, Lista, Morpho, Sky, SummerFi, Venus-Flux, Yearn, and YO Protocol. The vault registry is embedded in the Shield package, so validation needs no network calls, and it grows as new vaults are added.

Vault and chain counts change as coverage grows, so this page doesn't freeze them. Query the current coverage live:

* `shield.getSupportedYieldIds()` (or the CLI's `getSupportedYieldIds` operation) returns every yield ID Shield can validate.

<AccordionGroup>
  <Accordion title="ERC-4626 transaction types (all 5 operations)">
    | Type | What's validated |
    | - | - |
    | APPROVAL | `approve()` spender must be a whitelisted vault; token must be the vault's input token |
    | SUPPLY | `deposit()` / `mint()` into a whitelisted vault; receiver must be the user |
    | WITHDRAW | `withdraw()` / `redeem()` from a whitelisted vault; owner must be the user |
    | WRAP | `WETH.deposit()` / `WBNB.deposit()` for native-token vaults |
    | UNWRAP | `WETH.withdraw()` / `WBNB.withdraw()` post-withdrawal |

    Additional checks applied to all types:

    * Calldata tamper detection (re-encode and byte-compare)
    * Receiver/owner must equal `userAddress` (or a declared `args.receiverAddress`)
    * Chain-scoped vault whitelist (`chainId:address` composite key)
    * Allocator vault (OAV) address whitelisting, additive on top of the base vault registry (see [Shield integration](/documentation/platform/shield/integration))
  </Accordion>

  <Accordion title="Tron transaction types">
    | Category | Types |
    | - | - |
    | Resource management | FREEZE\_BANDWIDTH, FREEZE\_ENERGY, UNFREEZE\_BANDWIDTH, UNFREEZE\_ENERGY, UNDELEGATE\_BANDWIDTH, UNDELEGATE\_ENERGY |
    | Legacy resource | UNFREEZE\_LEGACY\_BANDWIDTH, UNFREEZE\_LEGACY\_ENERGY |
    | Governance | VOTE |
    | Lifecycle | WITHDRAW, CLAIM\_REWARDS |
  </Accordion>

  <Accordion title="What's not covered yet">
    These protocols require dedicated validators due to non-standard transaction flows:

    | Protocol | Reason | Status |
    | - | - | - |
    | Aave | Non-standard ERC-4626 implementation | Planned |
    | Spark | Overrides `deposit()` with referral-code variant | Planned |
    | Maple | Completely non-standard ABI (`SyrupRouter`, queue-based withdrawals) | Planned |
    | Morpho claim rewards | Uses separate Merkle-proof-based distributor contract | Planned |

    When you use the Shield library directly, these yields return `{ isValid: false }`: fail-safe by default. When Shield runs server-side via the Yield API, unsupported yields are currently skipped (not blocked) to avoid disrupting yields that don't yet have validators. See [Defense Mode](/documentation/platform/shield/defense-mode) for the implications.
  </Accordion>

  <Accordion title="Check coverage programmatically">
    ```typescript theme={null}
    // Check if a specific yield is supported
    shield.isSupported('ethereum-eth-lido-staking'); // true

    // Get all supported yield IDs
    shield.getSupportedYieldIds();
    // ['ethereum-eth-lido-staking', 'solana-sol-native-multivalidator-staking', ...]
    ```
  </Accordion>
</AccordionGroup>

<Note>
  Solana DeFi protocol validators, Perps API transaction coverage, and additional EVM protocol support are in development. `shield.getSupportedYieldIds()` always returns the canonical list for your installed version.
</Note>

## Risk detection and tamper protection

Shield's structural checks catch the attack classes that matter most in a transaction pipeline:

* **Fund redirection**: the decoded receiver or owner in calldata must match the user's address (or a declared custodial receiver).
* **Approval hijacking**: an `approve()` spender must be a whitelisted vault; arbitrary spenders are rejected.
* **Calldata tampering**: Shield re-encodes decoded EVM calldata and compares it byte-for-byte against the original, catching appended bytes, modified parameters, and corrupted data.
* **Contract impersonation**: `tx.to` must be a whitelisted address, scoped to the correct chain ID.
* **Ambiguous patterns**: a legitimate transaction must match exactly one known-safe pattern; multiple matches are rejected as a potential manipulation signal.

Structural validation checks that a transaction matches an expected pattern; it doesn't execute or simulate the transaction. For that layer, see [HyperNative](/documentation/platform/shield/hypernative), a separate partner integration in the yield.xyz security stack.

## Local decoding and visualization

Shield decodes every transaction locally as part of validation: ABI decoding for EVM, instruction parsing for Solana, and TronWeb decoding for Tron. Decoding happens entirely on your own systems, with no external API calls.

Each decoded transaction yields a typed view of what's on the wire: the target contract or program address, the function being called, parameter and argument values, and the auto-detected transaction type (returned as `detectedType` in the validation result).

This matters for more than security:

* **Transparency**: confirm every on-chain call before a user signs.
* **Compliance**: institutions can log decoded transaction details for audit trails or regulator review.
* **Zero trust**: because decoding is local, you can verify transactions built by yield.xyz or by any external system without trusting the builder.

## Transaction simulation

Shield validates structure and intent; it does not execute or simulate transactions. See [HyperNative](/documentation/platform/shield/hypernative) for what yield.xyz's separate simulation partner integration covers.

## Runtime support

Shield is implemented in TypeScript and distributed two ways: as the `@yieldxyz/shield` npm library, and as standalone binaries for Linux, macOS (ARM and Intel), and Windows that require no Node.js installation. The binary speaks a JSON protocol over stdin/stdout, which makes it embeddable from Go, Python, Rust, or any language that can spawn a subprocess, including restricted, compiled, and air-gapped environments where a Node.js runtime is unavailable.

| Capability | TypeScript library | Standalone binary |
| - | - | - |
| Transaction validation | ✅ | ✅ |
| Local transaction decoding (as part of validation) | ✅ | ✅ |
| Multi-chain support (EVM, Solana, Tron) | ✅ | ✅ |
| Requires Node.js | Yes | No |
| Embeddable from Go / Python / Rust | ❌ | ✅ (subprocess + JSON protocol) |
| Restricted and air-gapped environments | Limited | ✅ |

See [Shield integration](/documentation/platform/shield/integration) for downloads, checksum verification, and per-language guides.

## Validation errors

<AccordionGroup>
  <Accordion title="Common validation errors">
    | Context | Error | Meaning |
    | - | - | - |
    | **Any EVM** | `Transaction validation failed: No matching operation pattern found` | The transaction doesn't match any known-safe pattern. Likely malicious or corrupted. |
    | **ERC-4626** | `Vault address not whitelisted` | The transaction targets a contract address not in Shield's embedded registry. |
    | **ERC-4626** | `Owner address does not match user address` | A `redeem()` or `withdraw()` call has an owner that isn't the user: potential fund redirection. |
    | **ERC-4626** | `Approval spender is not a whitelisted vault` | An `approve()` call targets a spender that isn't a known vault address. |
    | **ERC-4626** | `Transaction calldata has been tampered with` | Re-encoded calldata doesn't match the original bytes: the transaction was modified. |
    | **Lido** | `Transaction not to Lido stETH contract` | The transaction targets an address that isn't the verified Lido contract. |
    | **Rocket Pool** | `Transaction not to RocketPool SwapRouter contract` | The STAKE transaction targets a contract that isn't the verified Rocket Pool swap router. |
    | **Rocket Pool** | `SWAP receiver does not match user address` | The rETH swap routes output to a different address: potential fund redirection. |
    | **Solana** | `Transfer recipient does not match new stake account` | SOL is being sent to a different wallet instead of the intended stake account. |
    | **Solana** | `Delegate authority is not user address` | Someone else would gain control over the user's staked SOL. |
  </Accordion>

  <Accordion title="Zero amounts and declared amounts">
    A `deposit()`, `mint()`, `withdraw()` or `redeem()` call whose decoded amount is zero still validates (`isValid: true`) and carries a `ZERO_AMOUNT` flag in `details`, so your integration can warn the user separately. A zero amount usually means the requested amount rounded down to zero.

    To check amounts, pass the intended amount in `args.amount` (underlying, as a base-unit integer string) or `args.shareAmount` (shares). When declared, deposit, withdraw, approval and wrap amounts must match it; declaring both, or a non-integer value, fails validation. When neither is declared, amount checks are skipped.
  </Accordion>

  <Accordion title="Release history">
    See [Shield releases](https://github.com/stakekit/shield/releases) for the current changelog.
  </Accordion>
</AccordionGroup>

## Next steps

<CardGroup cols={2}>
  <Card title="Shield integration" icon="plug" href="/documentation/platform/shield/integration">
    Library, binaries, and language guides
  </Card>

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

  <Card title="HyperNative" icon="bolt" href="/documentation/platform/shield/hypernative">
    Pre-signing simulation, as a separate partner integration
  </Card>

  <Card title="Security deployment options" icon="layer-group" href="/documentation/platform/shield/security-tiers">
    Choose the right deployment model
  </Card>
</CardGroup>


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