Policy Packs

A policy pack is a prebuilt data oracle published for Newton policies. Instead of writing and deploying your own WASM oracle, you can reference a pack’s deployed NewtonPolicyData contract, configure its params, and upload any API secrets the pack requires. Each pack ships:

A deployed WASM oracle.
A reference Rego template.
JSON schemas for params, secrets, and per-call wasmArgs.
A typed npm package such as @newton-xyz/policy-pack-vaultsfyi.
Canonical deployment metadata in newton-policy-packs/deployments.json.

Policy packs can be composed. Each pack namespaces its output under its pack id, so Rego can safely read values such as data.wasm.vaultsfyi.risk_score and data.params.chainalysis.deny_on_sanctioned in the same policy. See Chaining Multiple Data Oracles for the merge model.

Pack Catalog

The detailed pack catalog lives in the VaultKit docs:

VaultKit Policy Packs

Browse all supported packs, production PolicyData addresses, and provider links.

Canonical deployments.json

Source of truth for every pack, chain, environment, PolicyData address, and WASM CID.

Available Packs

Pack	Detail page
Vaults.fyi Vault Risk Rating	VaultKit: Vaults.fyi
Chainalysis Address Screening	VaultKit: Chainalysis
RedStone Oracle Divergence	VaultKit: RedStone
Webacy Depeg Risk	VaultKit: Webacy

How to Use Packs

There are two ways to use a pack: the Newton Dashboard (no CLI required) and newton-cli. Both reference the same open-source packs in the newton-policy-packs repo and the same deployed PolicyData addresses in deployments.json — pick whichever fits your workflow.

Using the Dashboard

The dashboard lets you browse the available data oracles, add one to your policy, configure its secrets and params, simulate, and deploy, all from the browser.

This tutorial focuses on the pack-specific steps. For signing in, generating an API key, and the full project lifecycle, see Using the Dashboard.

Open a project in the policy editor

Sign in at dashboard.newton.xyz and open a project to reach the policy editor. If you haven’t created one yet, follow Using the Dashboard to create a project and set a PolicyClient. A new project starts with an empty Data Oracles sidebar — “Data Oracles not found. Explore Data Oracles and add to your smart contract.”

Policy editor with an empty Data Oracles sidebar and the Add Data Oracles button

Open Discover Data Oracles

Click Add Data Oracles in the sidebar. The Discover Data Oracles modal lists the available packs — Chainalysis, vaults.fyi, Webacy, and RedStone — plus a Custom Data Oracle option for your own deployed PolicyData address. The Learn more about Policy Packs link points back to this guide.

Discover Data Oracles modal listing the available policy packs

Pick a pack

Select a pack to open its detail view. The Overview describes what the pack checks, and Resources links to the provider’s Website and docs. When you’re ready, click Continue.

Policy pack detail view showing the Overview and Continue button

Configure secrets and params

Continue opens the setup form. Packs that call authenticated APIs prompt for a Secret Key (paste the value from the provider); packs that don’t show No Secret Required. Selecting a built-in pack also pre-fills a reference Rego template, default parameters, and the list of secrets the pack needs, so you start from a working baseline. Secrets are encrypted client-side and uploaded per PolicyData address — see Secrets in Oracles.

Data oracle setup form for entering a pack's secret key

Reference the pack in Rego

The pack now appears in the Data Oracles sidebar. The configure panel (previous step) gives you the deny rules to copy into your Rego — read the pack’s output under its pack id, for example data.wasm.vaultsfyi.risk_score, and the thresholds you configured under data.params.<pack-id>.*. Add more packs to compose a multi-oracle policy; see Chaining Data Oracles.

Simulate

Click Test to run the full pipeline against sample inputs — every oracle executes, outputs merge into data.wasm, and your Rego is evaluated. The output panel shows the allow/deny result and the merged data the policy saw. Use it to confirm your references resolve before deploying. See Testing Policies.

Simulation output panel showing the policy allow or deny result

Deploy

When the policy behaves correctly, click Publish. The dashboard uploads your Rego and schemas to IPFS, deploys the PolicyData and NewtonPolicy contracts, and binds the policy to your PolicyClient. For deployment details and mainnet allowlisting, see Using the Dashboard.

Publish Policy modal in the Newton Dashboard

Using the CLI

Prefer the command line? newton-cli uses a pack by its deployed PolicyData address — you never deploy the oracle yourself. Make sure the CLI is installed (curl -L cli.newton.xyz | sh && newtup) and your NEWTON_API_KEY and chain are set; see Deploying with CLI for the full setup.

Look up the pack's PolicyData address

Pick a pack from the VaultKit Policy Packs catalog and copy its production PolicyData address for your chain from the catalog or the canonical deployments.json. You reference this address directly — there is no oracle to build or deploy.

Upload the pack's secrets

For packs that call authenticated APIs, upload the required key(s) encrypted, scoped to the pack’s PolicyData address. The keys must match the pack’s secrets schema (e.g. VAULTS_FYI_API_KEY).

cat > secrets.json <<'EOF'
{ "VAULTS_FYI_API_KEY": "sk-prod-xxxxxxxxxxxx" }
EOF

newton-cli --chain-id 11155111 secrets upload \
  --secrets-file secrets.json \
  --policy-client 0xYourPolicyClient \
  --policy-data-address 0xPackPolicyData \
  --api-key $NEWTON_API_KEY

Packs that need no credentials skip this step. See Secrets in Oracles for the full lifecycle.

Write a policy that reads the pack

In your Rego, read the pack’s output under its pack id (data.wasm.<pack-id>.*) and the thresholds you configure under data.params.<pack-id>.*. Compose multiple packs by referencing several pack ids in the same policy — see Chaining Data Oracles.

Deploy and bind the policy to the pack

Generate CIDs for your Rego and schemas, deploy the NewtonPolicy against the pack’s PolicyData address, then set it on your PolicyClient.

# 1. Upload Rego + schemas to IPFS
newton-cli policy-files generate-cids \
  --directory policy-files \
  --output policy_cids.json \
  --entrypoint "your_policy.allow"

# 2. Deploy the policy bound to the pack's PolicyData address
newton-cli policy deploy \
  --policy-cids policy_cids.json \
  --policy-data-address 0xPackPolicyData

# 3. Set the deployed policy on your PolicyClient
newton-cli policy-client set-policy \
  --policy-client 0xYourPolicyClient \
  --policy-address 0xDeployedPolicy

Because you reuse the pack’s existing PolicyData, there is no policy-data deploy step. See Deploying with CLI for params, registration, and verification.

Simulate

Verify the policy resolves the pack’s data before going live with newt_simulatePolicy (or newt_simulatePolicyDataWithClient to confirm uploaded secrets resolve). See Testing Policies.

Chaining Data Oracles

Compose several packs under one Newton policy.

Secrets in Oracles

Upload API keys for packs that need provider credentials.

Using the Dashboard

Browse data oracles and configure policies in the dashboard.

Testing Policies

Test Rego and simulate policy evaluation before going live.

Getting Started

Verifiable Credential

Guides

Use Cases

Deep Dives

Reference

Advanced

Resources

Pack Catalog

VaultKit Policy Packs

Canonical deployments.json

Available Packs

How to Use Packs

Using the Dashboard

Using the CLI

Chaining Data Oracles

Secrets in Oracles

Using the Dashboard

Testing Policies

​Pack Catalog

VaultKit Policy Packs

Canonical deployments.json

​Available Packs

​How to Use Packs

​Using the Dashboard

​Using the CLI

Chaining Data Oracles

Secrets in Oracles

Using the Dashboard

Testing Policies

Pack Catalog

Available Packs

How to Use Packs

Using the Dashboard

Using the CLI