Skip to content
LogoLogo

Why Weld

Regulated shielded payments need two proofs per transition: the wallet proves the transfer is well formed, and the institution proves its compliance policy permits it. The second proof is where projects stall. Policy circuits are written by compliance engineers, not cryptographers, and a policy that forgets to bind a value to a public commitment is silently vacuous, while a policy that cannot prove on some payment shape silently bricks its institution.

Weld's answer is to shape the protocol so that the framework has almost nothing dangerous to do. The protocol exposes exactly one object for policies to judge, the context tree, committed as one root that both the wallet and the institution can recompute. The framework's accessors return only values already welded to that root. Phase is fixed by which verification key the wrapper selects, never by anything a policy can read. A policy at the accept or reject phase structurally cannot read the sender's private region. None of these are conventions a reviewer has to check; they are types and circuits.

Goals

  1. An FI engineer with no ZK background writes a compliance policy in under a page of Noir and cannot write a vacuous or self-bricking one.
  2. Policy code is private (only a salted commitment is registered). Policy parameters are private and can be changed without recompiling or rotating keys.
  3. Policies can be stateful, with state anchored on chain, and can pass attestations forward to the counterparty FI's policy.
  4. New payload fields never require protocol circuit changes and never invalidate a registered policy that does not read them.
  5. The chain learns that a hold was resolved, never whether it was accepted or rejected.
  6. One toolchain, weld build | test | register | params | codegen, with a manifest that is the single contract between circuits, contracts, and client SDKs.

Non-goals in v1

  • Cross-FI proof aggregation or on-chain recursion beyond the wrapper. If throughput matters, the path is a batch-verifying aggregator in front of the pool, not a change of proof system.
  • Programmable authority, asset-issuer, or unshield policy slots. Designed for, not shipped.
  • Recipients that stay offline indefinitely. Holds expire by design.
  • A visual policy editor. The manifest and rule catalog make one possible later.
  • The transparent, non-shielded rail.

What the workflow layer adds

The workflow layer keeps every one of these properties and generalizes the object being judged from a payment to a party's view of an arbitrary multi-party transaction. Its own goals and non-goals are on its introduction page.