NEWTON PROTOCOL · POLICY CLIENT
0x8fe2…ebc5revision 1 · superseded
0x8fe204e53d5f7fdd5463a0f03d518f05aec8ebc5 · 1 of 8 policies · Sepolia
Revision 1 is superseded. Every attestation minted against 0xa7e81006…1702 was revoked when revision 2 landed on 2026-10-06 — regardless of its expiry block, because the client’s policyId no longer matches. Tasks created under it still replay correctly: each one carries this exact set as its own frozen snapshot. See revision 2, the current set →
POLICY ID
REVISION
1 of 2
POLICIES
1 of 8
DISTINCT
1
RESPONSE EXPIRY
50 blocks
CHAIN
Sepolia
TASKS · 24H
—
ALLOW RATE
—
Policies — 1
one Rego + WASM pair per slot- 00x811feaca33095f5fde8001ed401946e81322f10e0x811f…f10enot in factory registry50 blocksbounds set expiryexpected_ratifiernot in schema0x4cD178f4DF8244d9DA16a9ca56d9388e06f1aaB3max_cumulative_fill_limitnot in schema500000000000000000000000
policyParams — 121 bytes on chain
0x7b2265787065637465645f7261746966696572223a22307834634431373866344446383234346439444131366139636135366439333838653036663161614233222c226d61785f63756d756c61746976655f66696c6c5f6c696d6974223a22353030303030303030303030303030303030303030303030227d
Each module is evaluated against its own input — {"params": <this slot’s policyParams>, "wasm": <this slot’s WASM output>}. There is no shared data.wasm object and no cross-slot namespace, so slot 1 cannot read slot 0’s WASM output and a policy cannot be written to depend on its neighbours.
Tasks under revision 1
no tasksExport CSVJSONNo tasks match this scope yet.
The export carries one row per task with the frozen policy set in slot order, and it is the complete filtered history rather than this page. It has no per-policy verdict column: TaskResponse.allowed is a single boolean for the whole set, so which policy denied a task is in no record.