NEWTON PROTOCOL · POLICY CLIENT
0x65cc…4f10revision 2 · current
0x65cc59bb687884657b0bf772736a934da7bd4f10 · 1 of 8 policies · Sepolia
POLICY ID
REVISION
2 of 2
POLICIES
1 of 8
DISTINCT
1
RESPONSE EXPIRY
300 blocks
CHAIN
Sepolia
TASKS · 24H
0
ALLOW RATE
0.0%
Policies — 1
one Rego + WASM pair per slot- 00x75e6ce3a25b874fc4ef24125ec827ec410c477a60x75e6…77a6not in factory registry300 blocksbounds set expiryadminnot in schema0x0000000000000000000000000000000000000001allowed_chain_idsnot in schema["11155111"]allowed_contractsnot in schema["0xb1ad5f82407bc0f19f42b2614fb9083035a36b69"]allowed_functionsnot in schema["buy"]
policyParams — 200 bytes on chain
0x7b0a20202261646d696e223a2022307830303030303030303030303030303030303030303030303030303030303030303030303030303031222c0a202022616c6c6f7765645f636861696e5f696473223a205b223131313535313131225d2c0a202022616c6c6f7765645f636f6e747261637473223a205b22307862316164356638323430376263306631396634326232363134666239303833303335613336623639225d2c0a202022616c6c6f7765645f66756e6374696f6e73223a205b22627579225d0a7d0a
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.
Configuration history
2 writes · newest first| Rev | Policy set | Change | Policies | Configured by | Block | Tasks |
|---|---|---|---|---|---|---|
| 2 · current | 0xf5781a6d…5ecb | identical re-apply | 0x75e6ce3a25b874fc4ef24125ec827ec410c477a6 | — | 11,769,9990x33d5…280a | 0 |
| 1 | 0x2e78001a…325b | first set | 0x5c141295bae0c15b9ffc712288bebfbba8e1161d | — | 11,759,7580xdcfc…55df | 0 |
Every write mints a new policyId and revokes every attestation bound to the previous one, because the id commits the client, the chain, the revision counter and the exact ordered list — keccak256(POLICY_SET_DOMAIN, chainId, client, revision, policies). Revision 2 is the only one whose attestations are still spendable. One write here re-applied a byte-identical list. PoliciesUpdated fires anyway and the revision advances anyway, so that write changed nothing about the policies and still killed every outstanding authorization.
Task history — every revision
3 of 3 matchingExport CSVJSON| Task | Sender | Policy | Function | Signers | Result | Age |
|---|---|---|---|---|---|---|
| 0x2d6d7704… | 0xf39f…2266 | — | 0x62757928616464726573732c75696e743235362c75696e74333229 | NON-COMPLIANT | 139d 2h | |
| 0xb38084d9… | 0xf39f…2266 | — | 0x62757928616464726573732c75696e743235362c75696e74333229 | NON-COMPLIANT | 139d 2h | |
| 0xbe09edfb… | 0xf39f…2266 | — | 0x62757928616464726573732c75696e743235362c75696e74333229 | NON-COMPLIANT | 139d 2h |
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.