# Policy Packs \[Use Newton policy packs to enforce risk, compliance, and oracle checks before vault actions execute.] Newton vault policy packs combine Rego policy logic with policy data oracles. The oracle gathers the external data needed for a decision, then the Rego policy evaluates that data against the vault's configured parameters. In VaultKit 3.0, each published pack implements the `PolicyPack` contract from `@newton-xyz/policy-core`. Declare packs with `definePolicy(...).with(pack)`; use `defineOracle(...)` when authoring your own compatible oracle. Each pack runs as its own `NewtonPolicy` in the Shield's policy set, which allows a call only if every policy allows. ```typescript import { definePolicy } from '@newton-xyz/vaultkit' import { vaultsfyi } from '@newton-xyz/policy-pack-vaultsfyi' const policy = definePolicy({ chainId: '8453', env: 'prod' }) .with(vaultsfyi) ``` In the Newton dashboard, use **Explore Data Oracles** to browse available data oracles, inspect the data they provide, and add the relevant oracle to a policy. Vault policy packs can combine multiple oracles, so a single vault action can be checked against risk, compliance, and market data before it is approved. The open-source policy packs live in [newt-foundation/newton-policy-packs](https://github.com/newt-foundation/newton-policy-packs). Data providers can follow the repo's [CONTRIBUTING guide](https://github.com/newt-foundation/newton-policy-packs/blob/main/CONTRIBUTING.md) to add a pack that other developers can reuse in Newton-powered applications. For more detail on how packs work, how they are implemented, and how to build policies from them, see [Policy Packs](/developers/guides/policy-packs). :::note The canonical deployment source is [`newton-policy-packs/deployments.json`](https://github.com/newt-foundation/newton-policy-packs/blob/main/deployments.json). Look up a pack's policy address with `newton-cli policy packs`, which reads that file, instead of copying it from a snapshot. See [Pack Policy Addresses](#pack-policy-addresses). ::: ## Available Packs Grouped by data provider. | Provider | Policy pack | Use it for | | --- | --- | --- | | [Arkham](https://arkm.com/api) | [Entity-Aware Spending Gate](/developers/vaults/policies/arkham-entity) | Tiering a spending limit by who the destination actually is | | [Arkham](https://arkm.com/api) | [Adaptive Counterparty Gate](/developers/vaults/policies/arkham-counterparty) | Judging a payment against the sending wallet's own history and outflow baseline | | [Arkham](https://arkm.com/api) | [Explainable Risk Exposure](/developers/vaults/policies/arkham-risk) | Denying exposure you can trace to a specific transaction route | | [Balancer](https://balancer.fi) | Data Checks | Adding keyless Balancer pool or market data | | [Blockaid](https://www.blockaid.io) | Transaction Screening | Screening transaction and address risk | | [Chainalysis](https://www.chainalysis.com) | [Address Screening](/developers/vaults/policies/chainalysis) | Screening addresses for sanctions, high-risk categories, and configured blocklists | | [Guardrail](https://guardrail.so) | Risk Checks | Adding a Guardrail risk signal | | [Persona](https://withpersona.com) | Identity Checks | Adding identity and verification checks | | [Pharos](https://pharos.watch) | [Risk-Adjusted Treasury Gate](/developers/vaults/policies/pharos-treasury) | Admitting a stablecoin only when peg, stress, redemption, and exit capacity are all healthy | | [Pharos](https://pharos.watch) | [Stablecoin Safe Mode](/developers/vaults/policies/pharos-safe-mode) | Blocking exposure-increasing actions under stress while leaving withdrawals open | | [Pharos](https://pharos.watch) | [Redemption-Backed Asset Gate](/developers/vaults/policies/pharos-redemption) | Admitting a stablecoin only when it can actually be redeemed at par | | [RedStone](https://redstone.finance) | [Oracle Divergence](/developers/vaults/policies/redstone) | Stopping actions when market data is stale, divergent, or persistently outside thresholds | | [Sumsub](https://sumsub.com) | Verification Checks | Adding KYC and verification checks | | [Vaults.fyi](https://vaults.fyi) | [Vault Risk Rating](/developers/vaults/policies/vaultsfyi) | Gating actions on APY, TVL, risk score, allocation changes, critical flags, and corruption status | | [Webacy](https://developers.webacy.co/) | [Depeg Risk](/developers/vaults/policies/webacy) | Monitoring pegged-token depeg risk for manager-action gates | | [Xerberus](https://xerberus.io) | [Liquidity Exit](/developers/vaults/policies/xerberus-liquidity-exit) | Denying a position that can't be unwound quickly at a bounded market impact | | [Xerberus](https://xerberus.io) | [Portfolio What-If](/developers/vaults/policies/xerberus-what-if) | Denying a trade that concentrates the book or makes it harder to exit | | [Xerberus](https://xerberus.io) | [Common Cause](/developers/vaults/policies/xerberus-common-cause) | Denying false diversification across venues that share one upstream token, protocol, oracle or governance contract | ## Pack Policy Addresses Each published pack is a factory-deployed `NewtonPolicy` that serves the pack's published WASM and reference Rego. Resolve its address for your chain and environment with `newton-cli`, which reads [`deployments.json`](https://github.com/newt-foundation/newton-policy-packs/blob/main/deployments.json), then pass it to `createShield({ policies })` under the module's short ID: ```bash # Every pack published on Base newton-cli --chain-id 8453 policy packs list # One pack, machine-readable newton-cli --chain-id 8453 policy packs show --pack vaultsfyi --format json ``` Use the `policy` value from the JSON output. The commands use the `prod` environment unless `DEPLOYMENT_ENV` is set. Pass `--env stagef` for staging, or `--catalog ` to read a different catalog. When a pack is not published for your chain and environment, `policy packs show` exits with `no published policy for pack`, or with `unknown pack` when the catalog has no entry for that pack at all. A Shield binds its whole set with `shield.setParams(...)`, so skip the `policy-client set-policies` step that the CLI suggests. ### Deploying Your Own Pack Policy To run a pack on a chain or environment where it is not published, or to own the policy contract, deploy it yourself from the pack's reference Rego and published WASM CID. You never build or upload a pack WASM. The `@newton-xyz/policy-pack-*` npm packages ship only JavaScript. Take the byte-exact reference directory (`policy.rego`, `params_schema.json`, `secrets_schema.json`, `policy_metadata.json`) from the pack's `/dist/` directory in [newton-policy-packs](https://github.com/newt-foundation/newton-policy-packs), at the commit matching your installed pack release. With `newton-cli` 0.7.0 or later, deploy each module's policy. Build the CLI from a newton-prover-avs `unified/main` checkout; the published releases report a 0.5.x version without the policy-set commands. ```bash # 1. Upload the reference Rego, params schema, metadata, and secrets schema # to this environment's gateway object store. newton-cli policy-files upload-cids -d policies/vaultsfyi --entrypoint vault_risk_rating.allow \ --secrets-schema-file policies/vaultsfyi/secrets_schema.json \ --gateway-url "$GATEWAY_URL" --api-key "$NEWTON_API_KEY" -o policies/vaultsfyi/policy_cids.json # 2. Set "wasmCid" in policy_cids.json to the pack's deployments[chainId][env].wasmCid. # 3. Deploy the NewtonPolicy. newton-cli policy deploy --policy-cids policies/vaultsfyi/policy_cids.json \ --policy-file policies/vaultsfyi/policy.rego --skip-cids ``` Each gateway has its own object store, so upload per environment. The pack's WASM must already be in that environment's store. A pure-Rego `_policy` gate is deployed the same way without step 2 and without a secrets schema; its `wasmCid` stays `""`. Keep the pack's Rego byte-for-byte. `classifyProvenance` reports a module as `audited` only if its policy serves the pack's audited WASM and its `policyCodeHash` matches the pack's reference Rego. To check something the pack does not, add another policy to the set instead of editing the pack's Rego. ## Composing Policy Packs Vault policy packs are most useful when combined. For example, a regulated yield vault might require: * Webacy depeg-risk checks for pegged-token exposure * Chainalysis sanctions screening for the depositor address * Vaults.fyi risk checks before accepting additional capital * RedStone oracle divergence checks before curator reallocations The result is a vault whose rules are explicit, inspectable, and enforced before execution. The three Xerberus packs are built to run together as one gate for exposure-increasing actions: an exit quote for the asset, a what-if for the portfolio, and a common-cause check across venues. Pass the same `window` to all three so every result comes from one Xerberus snapshot. For custom oracles, policy-level `_policy` params, bare policies, policy-set introspection, and provenance classification, see [Policies](/developers/vaults/sdk/policies) and [Custom Oracles](/developers/vaults/sdk/custom-oracles). Learn how policy packs are structured, implemented, and used in Newton policies. Check vault APY, TVL drawdown, risk score, allocation changes, flags, and corruption status. Screen addresses against sanctions and risk categories. Monitor pegged-token depeg risk before manager actions execute. Compare RedStone price data against onchain oracle data before allowing actions. Tier a spending limit by the destination's real-world entity attribution. Judge a payment against the sending wallet's own counterparty history. Deny risk exposure traced to a specific transaction route. Admit a stablecoin only when peg, stress, redemption, and exit capacity all hold. Block exposure-increasing actions under stress while leaving the exits open. Admit a stablecoin only when it can actually be redeemed at par. Deny a position that can't be unwound quickly at a bounded market impact. Deny a trade that concentrates the book or makes it harder to exit. Deny false diversification across venues that share a failure mechanism.