Defense Mode

Server-side Shield validation inside the Yield API, in Monitor or Block mode per project.

Defense Mode is Shield running server-side, inside the Yield API’s transaction pipeline. Every unsigned transaction the API constructs is validated before it is returned. In Monitor mode a failed validation is logged and the transaction is still returned; in Block mode it is rejected before it reaches the client.

Defense Mode complements client-side Shield rather than replacing it. Server-side validation checks what the API constructed; client-side Shield checks what you received, after it left the API. Running both covers both paths.

How it works

Defense Mode uses the same engine as the client-side library: the same validators, vault registry and calldata tamper detection (see What Shield checks). It runs in the same process as transaction construction.

Mode	On a failed validation	Default
Monitor	Logged server-side; the transaction is returned as normal	Yes
Block	Rejected; the client receives an error instead of the transaction	Enabled per project by yield.xyz

yield.xyz enables Block for a project after a Monitor period on live traffic, and can switch a project back to Monitor through configuration. Every validation, allowed or failed, is logged server-side.

Yields without a registered Shield validator are currently skipped server-side rather than blocked. Check coverage with isSupported(yieldId) (see Shield features).

Threat model

Threat	Covered by Defense Mode	Notes
Transaction construction altered inside the API (compromised code or dependency)	Yes, in Block mode	Shield validates the constructed transaction independently of the code that built it. Shield currently runs in-process, so a full compromise of the API runtime is not covered; isolating Shield in a separate deployment is planned but not scheduled
Response altered between the API and your client	No	Covered by client-side Shield
Client modifies a transaction after receiving it	No	Client-side Shield and wallet confirmation
Protocol-level exploit in a contract Shield approves	No	Shield checks transaction structure, not the safety of the underlying protocol
Gas parameters (maxFeePerGas, gasLimit)	No	Not validated today
Amount changed from what the user intended	Only when an intended amount is declared	Declare args.amount or args.shareAmount when calling Shield client-side
Phishing or a user approving an unwanted transaction	No	Wallet-level confirmation

For high-value or sensitive flows, ask yield.xyz for the current list of known coverage gaps.

For integrators

When Defense Mode is enabled for your project, nothing changes in your integration code. In Block mode, a rejected transaction returns HTTP 500 with the message Transaction blocked by security validation. The detailed reason is logged server-side and not returned, so Shield’s logic can’t be probed through error messages. If you believe a block is incorrect, contact yield.xyz with the request timestamp and your project so the reason can be looked up.

Keep validating client-side as well: see Shield integration.

Next steps

Shield overview

What Shield checks and where it runs.

Shield features

Coverage matrix and validation errors.

Shield integration

Library, binaries, and language guides.

Security deployment options

Client-side, server-side, or both.