Every serious vault mandate includes a counterparty rule: authorized brokers only, and no anonymous large trades. Here’s the critical part: the bot moving the money has never read it. This policy fixes that specific gap. The same wallet gets a high limit with verified exchanges and approved protocols, a small introductory limit with anything unlabelled, a human in the loop when identity is uncertain, and a hard stop on prohibited risk tags. Arkham supplies the identity; Newton enforces the rule before the transaction settles.
The problem
An agent wallet will send $500K to Coinbase’s official deposit address and $500K to a contract deployed last Tuesday with exactly the same enthusiasm. Onchain, they’re both just addresses. The wallet has no concept of “counterparty we trust” (that concept lives in your mandate, which is a document, which the automation cannot read).
So you get to pick your poison:
- Set the limit low enough to contain the deployed-last-Tuesday case, and your strategy can’t do real work with exchanges you’ve trusted for years.
- Set it high enough to be useful, and one bad routing decision sends real money to an address nobody can name, while your written policy was correct the entire time.
You can hardcode exceptions in Solidity, but then someone has to keep the contract’s address logic current as labels change. That turns a policy problem into an ongoing maintenance problem.
That second scenario is the one that ends a curator’s track record. You promised allocators a standard, the standard existed, and it was enforced by nothing. And the environment is not conceptual: Chainalysis counted at least $154 billion received by illicit addresses in 2025, $104 billion of it by sanctioned entities. That is still under 1% of all transaction volume, which is precisely the problem. The bad counterparties are rare, and they look like everyone else. Nobody is watching the dashboard at 3am. The automation does exactly what it was told, which turns out not to be the same thing as what you promised.
The policy
One wallet, one policy, four outcomes decided per transaction by who’s on the other side:
The interesting shift: the limit stops being a property of the wallet and becomes a property of the relationship. A new counterparty can earn its way up. A trusted one can be transacted with at size. A tagged one is unreachable no matter what the bot decides at 3am.
The decision record
Approved or denied, the record is the receipt. The counterparty standard in your mandate stops being a claim and becomes something an allocator can check on the explorer. Enforceable, not aspirational.
Configuration is five choices: the approved-entity list, the introductory limit, the confidence threshold, the prohibited tag set, and the failure mode. If the oracle can't answer, nothing proceeds.
Where the identity comes from
Arkham is a blockchain intelligence platform that connects addresses to real-world entities: the entity behind an address, its role (exchange hot wallet, deposit address, treasury), its behavioral tags, and, the part this policy leans on hardest, whether the attribution is Arkham-verified or a prediction, and with what confidence. That distinction is what lets a policy treat “we know who this is” differently from “we think we know.” Arkham is partnered with leading L1s and L2s in the industry, including Polygon, Avalanche, BNB Chain, Optimism, Arbitrum, Base, and Tron.
Arkham can tell you all of this. It cannot stop a transaction. Newton is the part that stops the transaction. Counterparty trust used to live in a dashboard. This makes it live in the transaction.
Build this policy → docs.newton.xyz/developers/guides/policy-packs