policy

Optional on-chain enforcement for the make-private boundary. Program id 3B8sqPfgKYvxffwCvPx76Syu4R6MzQr7wkiTmvfjEzLR (devnet).

Optional and not wired in. The active screening path is the off-chain screening provider in @p15/compliance. This program is the escalation for a deployer who wants allowlist or limit enforcement that no client can skip. It stands alone behind a feature flag; the dApp does not call it by default.

Shape

A config PDA at ["policy"] holding the admin and a per-transaction max_amount.
A per-wallet denial marker at ["denied", wallet] whose mere existence means "blocked". (An allowlist is the dual; v1 ships the denylist.)
A stateless check assertion that fails the transaction if the amount is over the limit or the wallet has a denial marker.

Instructions

Instruction	Args	Who	Effect
`init_policy`	`max_amount: u64`	anyone (becomes admin)	Create the config; signer is recorded as admin.
`set_limit`	`max_amount: u64`	admin	Update the per-transaction limit.
`deny`	`wallet: Pubkey`	admin	Create the `["denied", wallet]` marker.
`allow`	`wallet: Pubkey`	admin	Close the marker, rent back to admin.
`check`	`amount: u64`	anyone	Pass only if `amount <= max_amount` and the wallet has no denial marker.

check is stateless and CPI-friendly: it derives everything from seeds and stores nothing, so a deployer can prepend it as a top-level instruction before make-private, or CPI it from a wrapping program.

code

check accounts:
  config   ["policy"]                read-only
  denied   ["denied", wallet]        read-only (empty == not denied)

Errors

AmountOverLimit (amount exceeds the policy limit), WalletDenied (the wallet has a denial marker).

When to use it

Reach for policy only when off-chain screening is not enough, for example when a regulated deployer must guarantee that no modified client can bypass an allowlist or a per-transfer cap. For everything else, the off-chain ScreeningProvider is simpler and is the path the dApp uses.