A policy layer that turns “the curator promises to follow the rules” into rules the vault itself enforces — on every action, before it executes.

Whoever curates an onchain vault holds a remarkable amount of power. They decide how depositor capital is allocated across markets, which markets are enabled in the first place, how caps and fees are set, and when any of it changes. On most vaults today, that authority is a single manager key, and the only thing standing between depositors and a bad decision is trust.

For a long time that was acceptable, because the capital was crypto-native and the depositors knew what they were signing up for. That era is ending. Real-world assets, tokenized funds, and institutional allocations are moving onchain, and the people putting that capital to work answer to risk committees, auditors, and regulators. “Trust the curator” is not an answer those people can write down. They need the rules to be enforced, not promised.

VaultKit is how curators give them that answer.

What VaultKit is

VaultKit is a developer SDK that puts a policy check on every management action a curator takes, without asking the curator to rebuild how they operate. The vault stays the same. The curator’s tools stay the same. What changes is that each action — reallocate, set a cap, enable a market, change a fee — has to pass its policy before it can touch the vault. If the action is within the rules, it executes normally. If it is not, it does not execute at all.

The important part is what VaultKit is not. It is not a new vault product depositors have to migrate into. It is not a custodian that takes control or charges for the privilege. It does not change anything for the end users depositing into the vault. It sits between the curator and the vault they already manage, and enforces a set of rules everyone can read and verify.

It fits the workflow curators already have

Most curation teams already run on a vendor SDK. A team managing a vault uses that vendor’s own tools to build their transactions, producing the exact instructions the vault understands. VaultKit does not replace any of that.

Instead, VaultKit wraps the instructions the curator’s existing SDK already produces and routes them through a policy check on the way to the vault. The curation team keeps the dashboard and the process they have. The difference is that the manager key now points at VaultKit, and VaultKit will only forward an action once it has been checked and approved.

That approval is cryptographic and specific. It is bound to the exact action — the precise instruction, the precise vault, the precise amount. There is no “approved a similar action” or “approved this kind of action.” The check matches the transaction in front of it or it does not pass.

And it fails closed. If the policy denies the action, or the evaluation can’t be completed, the action simply doesn’t go through. An override available on demand would be the same as no control at all, so today the only escape is a public, time-delayed path — observable onchain, with a built-in waiting period — that can’t be quietly exercised the moment it becomes inconvenient. (A logged, policy-governed override is a natural extension of the same model.)

Rules, policies, and an open ecosystem

A policy is what a curator puts on a given vault: the full set of constraints the vault enforces, combined into one thing. “Never allocate more than 40% to a single market.” “Only enable markets above a certain liquidity threshold.” “Block any counterparty on a sanctions list.” A single policy can carry a concentration limit, a liquidity floor, and a compliance screen at once — all checked together, as one decision, before any action executes. The curator isn’t juggling separate gates; they’re authoring one policy that expresses everything the vault should hold to.

Those rules are only as good as the data behind them, and that is where the ecosystem comes in. Newton maintains an open-source library of policy packs — reusable building blocks, each backed by a real data source and co-developed with the partner who owns that data. The packs available today already span the domains a curator has to reason about:

  • Risk and market integrity: vaults.fyi for live vault risk signals, RedStone for oracle-price divergence, Balancer for pool composition and concentration, Webacy for peg and depeg monitoring, and Guardrail for protocol health and active alerts.
  • Compliance and identity: Chainalysis for sanctions and address screening, SumSub for identity verification, and Blockaid for catching malicious transactions before they reach the vault.

A curator composes their policy from these building blocks the way you’d assemble anything from parts, mixing data sources to express exactly the constraints they need.

The library is open, and Newton is deliberately neutral about who contributes to it. Any data provider, risk firm, or compliance vendor in the ecosystem can publish a policy pack, and curators choose which ones to trust. Newton does not sit in the middle picking winners or gating access to the data. The policy packs live in the open:

github.com/newt-foundation/newton-policy-packs

The part that’s hard to do anywhere else

Here is the problem with putting serious compliance and risk rules onchain: the most valuable rules depend on data nobody wants to publish. A proprietary risk model. A private counterparty blocklist. Jurisdiction and eligibility data tied to specific investors. The information that would make a policy genuinely meaningful is exactly the information a firm cannot post to a public chain.

VaultKit’s policy evaluation is privacy-preserving and cryptographically verifiable. Policies are checked using privacy-preserving computation — drawing on techniques such as secure multi-party computation, trusted execution, and zero-knowledge proofs — so a policy can take sensitive or proprietary data into account without that data ever being exposed. What lands onchain is a verifiable approval, not the inputs behind it. Anyone can confirm the decision was made correctly; no one can read the data that produced it.

That guarantee does not rest on trusting Newton. Policy evaluation is designed to run across a network of independent operators, with economic security from restaked ETH through EigenLayer and evaluation correctness provable with zero-knowledge proofs through Succinct. The aim is for the approval a vault acts on to carry the same kind of cryptographic and economic security that protects the chains the vaults themselves live on.

The practical effect: compute over data you never reveal, and trust the result because it’s provable. For a curation team, that means a risk model or an eligibility check can drive real onchain enforcement while the underlying data stays private. For an institution, it means the regulatory and jurisdictional rules they already live by can be enforced on a vault directly — without publishing the rulebook or the data that powers it.

That last point is where this stops being a crypto-native story. The largest asset managers exploring tokenization don’t have a discretion problem; they have a provable-control problem. They can already write the policy. What they’ve been missing is a way to enforce it onchain, verifiably, without handing their compliance logic to the public. That is the capability VaultKit is built to provide.

Vault-agnostic and multichain by design

None of this is tied to one vault product or one chain. VaultKit is built to wrap any vault and operate across networks, with the first vault integrations live and more on the way. A curator running strategies across several protocols and several chains enforces the same kind of policy everywhere, rather than rebuilding controls product by product. As the set of supported vaults and the library of policy packs grows, the same model stretches to cover it.

Who it’s for

If you run a curation or allocation desk today — answering to depositors who want more than a published guideline — VaultKit lets you turn the controls you already operate by hand and by policy doc into controls the vault enforces on its own. The teams who feel this first are the ones whose depositors are starting to ask harder questions.

If you’re an institution looking at onchain vaults and tokenization, this is the missing piece between your compliance regime and the chain: a way to operate onchain under the same rules you operate under everywhere else, enforced and provable, without exposing the data that defines them.

The infrastructure is live in mainnet beta, the SDK is on npm, and the first policy packs are open source and ready to build on.

To explore the policy packs, start with the open-source repository at github.com/newt-foundation/newton-policy-packs. To talk about putting VaultKit on a vault you manage, or to co-develop a policy pack around a data source you own, get in touch with the Newton team.