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.

GitHub repository

Source code, issues, and release artifacts at stakekit/shield

npm package

TypeScript library: @yieldxyz/shield

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

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

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

Security overview

How Shield fits into the wider security suite

Shield features

Coverage matrix, validators, decoding, and validation errors

Shield integration

TypeScript library, standalone binaries, and Go/Python/Rust guides

Defense Mode

Server-side enforcement inside the Yield API