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.

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.

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)

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

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 for the implications.

Check coverage programmatically

// 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', ...]

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.

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, 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 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 for downloads, checksum verification, and per-language guides.

Validation errors

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.

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.

Release history

See Shield releases for the current changelog.

Next steps

Shield integration

Library, binaries, and language guides

Defense Mode

Server-side enforcement inside the Yield API

HyperNative

Pre-signing simulation, as a separate partner integration

Security deployment options

Choose the right deployment model