# Deployment Checklist \[Pre-launch verification checklist for deploying Newton Protocol policies, oracles, and PolicyClient contracts]

Use this checklist to verify your Newton Protocol integration before going to production.

## Policy Development

:::steps
### Rego policy passes local evaluation

```bash
newton-cli regorus eval \
  --policy policy.rego \
  --input '{"from":"0x...","to":"0x...","value":"0x0","data":"0x","chainId":"0xaa36a7","functionSignature":"0x"}' \
  --data '{"params":{...},"data":{...}}'
```

Verify `allow`, `deny`, and `cap` paths all produce expected results.

### Data oracle returns valid JSON

```bash
newton-cli policy simulate -p policies/my-oracle
```

Set the oracle's input in `configs/wasm_args.json`, then confirm the output matches your policy's `data.wasm` expectations.

### Gateway simulation succeeds

Run `newt_simulatePolicy` with realistic intent parameters, and verify aggregate and per-policy results. Simulation returns no attestation. Separately obtain live signatures and verify an allowed application transaction.

### Edge cases tested

* Zero-value transactions
* Maximum-value transactions
* Addresses not on allowlists
* Expired or missing data
* Invalid function signatures
:::

## On-Chain Deployment

:::steps
### Mainnet policy allowlisting confirmed

Mainnet policy usage requires allowlisting by the Newton team. Before deploying or using policies on mainnet, [reach out through the intake form](https://newton.xyz/intake-form).

### Independent policies deployed

```bash
newton-cli policy deploy -p policies/my-policy
```

Each policy has Rego, schema, metadata, code hash, and optional WASM/secrets-schema CIDs. Pure-Rego needs no WASM module. Require a successful receipt, nonempty code, and registration with the TaskManager's factory.

### PolicyClient configured

```bash
cast send "$POLICY_CLIENT" \
  'setPolicies((address,(bytes,uint32))[])' \
  "[(\"$POLICY_0\",(\"$PARAMS_0\",25))]" \
  --rpc-url "$RPC_URL" --private-key "$PRIVATE_KEY"
```

Deploy using the [contract integration guide](/developers/guides/smart-contract-integration), then configure the complete ordered set with owner `setPolicies`. Read `getPolicySetSnapshot()` and check ID, revision, params, order, and nonzero expirations.

### Ownership and registry verified

Verify `getOwner()` matches the intended owner. Register for identity flows where required by the target deployment; a registry owner record is separate from the client's owner authority.
:::

## API & Secrets

:::steps
### API key created with correct permissions

Verify your key has `rpc_read` for task submission and simulation, `rpc_write` if you need to manage secrets. See [Dashboard & API Keys](/developers/overview/dashboard-api-keys).

### Encrypted secrets stored (if applicable)

If your oracle requires API keys, store them via `newt_storeEncryptedSecrets`. Verify with `newt_simulatePolicyDataWithClient`. See [Encrypting Secrets](/developers/advanced/encrypting-secrets).

### Secrets match schema

Confirm your uploaded secrets match the `secretsSchemaCid` defined on your Policy contract. Schema mismatches produce validation errors.
:::

## Frontend Integration

:::steps
### SDK installed and configured

```bash
pnpm add @newton-xyz/sdk viem
```

Verify `newtonPublicClientActions` and `newtonWalletClientActions` are properly extended on your viem clients.

### Environment variables set

* `NEWTON_API_KEY` — your Gateway API key
* `NEWTON_GATEWAY_URL` — the correct Gateway URL for your environment
* PolicyClient address for your target chain

### End-to-end flow verified

1. Submit an evaluation via `evaluateIntentDirect` or `submitEvaluationRequest`
2. Receive attestation
3. Execute the attested transaction on-chain
4. Verify the transaction succeeds

### Error handling implemented

Handle all SDK error codes: `TASK_TIMEOUT`, `POLICY_NOT_FOUND`, `ATTESTATION_EXPIRED`, `UNAUTHORIZED`. See [Error Reference](/developers/reference/error-reference).
:::

## Security

* \[ ] PolicyClient ownership verified on-chain (not just in your local config)
* \[ ] API keys stored in environment variables, never committed to source control
* \[ ] WASM oracle does not log or expose secrets
* \[ ] Attestation expiration is checked before on-chain submission
* \[ ] Challenge window (100 blocks) is accounted for in your UX
* \[ ] Contract uses `_validateAttestation` or `_validateAttestationDirect` correctly
* \[ ] Intent fields (`from`, `to`, `value`, `data`, `chainId`) are validated before submission

## Pre-Launch Verification

```bash
newtup
newton-cli --version
newton-cli doctor
```

Record the chain, TaskManager, configured factory, and gateway deployment. Require a gateway task ID, aggregate verdict, and—on allow—a successful application transaction hash and state readback. Verify denial and replay leave state unchanged.

## Policy-set validation checklist

Use two independent deterministic test policies, each with allow and deny fixtures. Keep the same client and record its ordered set before each run.

| Policy 0 | Policy 1 | Aggregate | Application state |
|---|---|---|---|
| Allow | Allow | Allow | Changes only after successful attested transaction |
| Allow | Deny | Deny | Unchanged |
| Deny | Allow | Deny | Unchanged |
| Deny | Deny | Deny | Unchanged |

* Check every input and result maps to its policy-set position; preserve repeated entries.
* Replace with a reordered set, then an identical set. Each successful replacement advances the revision and changes the ID. Old attestations must fail.
* Reject empty sets, more than 8 entries, unregistered policies, zero expiry, oversized params, and unauthorized updates on the pinned contract.
* Reject reused attestations and changes to sender, target, chain, value, calldata, or protected arguments. Verify expired responses and mismatched task snapshots fail.
* Read state before and after denial and failed validation. An API denial alone does not prove the contract rejects a deny attestation.

Record evidence separately:

| Level | Evidence |
|---|---|
| Local policy tests | Inputs, expected and actual Rego verdicts |
| Local contract tests | Configuration, intent binding, deny, stale response, and replay assertions |
| Gateway simulation | Endpoint, current set ID, per-policy results, aggregate verdict; no signatures |
| Live operator evaluation | Gateway task ID, frozen task, aggregate `allowed`, signed response |
| On-chain validation | Successful BLS validation or expected revert |
| Application execution | Transaction hash, receipt, and resulting application state |

Do not use wall-clock conditions for a deterministic tutorial. An allow decision applies to evaluation time; block-based expiration is not a promise that external conditions remain true until execution.

## Next Steps

<Card icon="question" to="/developers/resources/faq" title="FAQ & Troubleshooting">
  Common questions and error solutions
</Card>

<Card icon="code" to="/developers/reference/contract-addresses" title="Contract Addresses">
  Deployed contracts on all networks
</Card>