diff --git a/use-cases/programmable-policy.md b/use-cases/programmable-policy.md new file mode 100644 index 0000000..064966a --- /dev/null +++ b/use-cases/programmable-policy.md @@ -0,0 +1,55 @@ + + +| title | primary\_domain | secondary\_domain | +| :---- | :---- | :---- | +| Compliant privacy via programmable policy | Identity & Compliance | | + +## 1\) Use case + +Institutional users need privacy tooling to keep competitive information (trading strategies, portfolio composition, risk exposure, vendor payments, etc.) confidential when transacting onchain. But the same privacy mechanisms that protect legitimate institutional activity can also be leveraged by malicious actors, creating business, legal, and regulatory risks. + +As a result, institutions using privacy-enhanced protocols and chains (e.g. private vaults, shielded transfer systems, privacy L2s), or issuing stablecoins and other RWA tokens that may circulate through such environments, need tools that allow them to manage business and regulatory risk. More specifically, they need tools enabling them to avoid transacting with or commingling funds with high-risk entities, even when privacy features are in use. + +## 2\) Additional Business Context + + + +## 3\) Actors + +Issuer, Investor, Payer/Payee, Compliance/Monitoring, Law enforcement, Regulator, Privacy protocol operator + +## 4\) Problems + +### Problem 1: Preventing commingling of funds with malicious actors when using privacy protocols + +Institutions may use DeFi protocols with privacy enhancements (e.g. [private vaults](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-private-vaults.md)) to complete onchain investments, payments, and other financial operations without exposing their strategy or risk exposure. This can be done using encryption protocols on Ethereum mainnet or protocols on privacy L2s. However, privacy enhancements can make it harder for institutions to avoid commingling of funds with deposits from malicious actors, as is mandated by regulations and/or internal risk management requirements. + +**Requirements:** + +- Must allow protocol operators to prevent commingling of funds and deny deposits from malicious actors at the smart contract level while still preserving privacy + +**Constraints:** + +- Any solution must not compromise privacy or introduce significant latency or UX detractions for compliant users + +## 5\) Recommended approaches + +Operators of privacy protocols and privacy L2s can set programmable policies restricting high-risk or malicious actors from using their tools – those policies are then integrated and enforced at the smart contract level. + +For example, a privacy project operator may decide to implement a policy restricting all addresses on the OFAC sanctions list and addresses with exposure to certain high-risk activity (e.g. terrorism financing, darknet market sales, etc.) from depositing funds to their project. + +If the project in question is a privacy-enhanced application on Ethereum mainnet, the application team can integrate this policy into its smart contracts and automatically prevent restricted addresses from depositing funds. This provides more consistent compliance enforcement than the common framework of front-end compliance checks, which can be bypassed via direct contract calls. If the project is a privacy L2, the operator can integrate their programmable policy with the bridge contract, and prevent restricted addresses from moving funds to the chain at all. + +In both cases, the application calls the policy platform, which returns a cryptographic attestation confirming whether or not the transaction adheres to the application team’s policy. If it does adhere, the transaction proceeds with the attestation attached, which allows the deposit to be executed. If the transaction doesn’t adhere to the policy, the address is unable to deposit funds to the protocol, thereby significantly reducing commingling risk for institutions using the protocol compliantly. Compliant users deposit funds unimpeded, and face no degradation of privacy guarantees. + +## 6\) Open questions + +- N/A + +## 7\) Notes and links + +- Relevant use cases where programmable policy can enhance compliance: + - [Private stablecoins](https://github.com/ethereum/iptf-map/blob/master/use-cases/private-stablecoins.md) + - [Private RWA Tokenization](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-private-vaults.md) + - [Private Bonds](https://github.com/ethereum/iptf-map/blob/master/use-cases/private-bonds.md) +- Predicate programmable policy platform [docs](https://docs.predicate.io/v2/essentials/overview) diff --git a/vendors/predicate.md b/vendors/predicate.md new file mode 100644 index 0000000..7db50e2 --- /dev/null +++ b/vendors/predicate.md @@ -0,0 +1,99 @@ +--- +title: "Vendor: Predicate" +status: draft +--- + +# Predicate – Programmable, real-time compliance for onchain financial products + +## What it is + +Predicate enables financial technology companies to enforce compliance and business rule requirements for applications and assets on public blockchains. It abstracts policy logic and enforcement from smart contracts, making it easy to adapt as requirements change over time. + +How it works: + +- **Programmable policy:** Compliance policies set by financial application teams and/or asset issuers using the Predicate dashboard, with templates designed for real-world use cases such as AML checks, rate limits, collateral thresholds, anomaly detection, and jurisdictional restrictions. Policies can run on data from any onchain or offchain source, including sanctions lists, risk scoring, internal compliance data, geolocation, zero knowledge proofs, onchain identity systems, and more. +- **Offchain API:** Transaction data is sent to the Predicate REST API in real–time to receive a cryptographic attestation that reflects whether the request meets the operator’s configured rules. +- **Onchain enforcement:** Predicate enforces policies directly at the smart contract level in real-time, ensuring only transactions which adhere to operators’ defined policies can be executed. Sub-second latency ensures no added friction for compliant users. + +## Fits with patterns + +- [Aztec Noir Private Contracts](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-noir-private-contracts.md) +- [Private L2s](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-privacy-l2s.md) +- [Private ISO 20022 Messaging & Settlement](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-private-iso20022.md) +- [Private Stablecoin Shielded Payments](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-private-stablecoin-shielded-payments.md) +- [Private Intent-Based Vaults](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-private-vaults.md) +- [Shielded ERC-20 Transfers](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-shielding.md) +- [Hybrid TEE \+ ZK Settlement](https://github.com/ethereum/iptf-map/blob/master/use-cases/private-bonds.md) +- [Selective disclosure (viewing keys \+ ZK proofs)](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-regulatory-disclosure-keys-proofs.md) + +## Not a substitute for + +- Address risk scoring +- Whitelists/blacklists +- ZK Identity solutions +- Offchain KYC/KYB vendors + +## Architecture + +**Core components:** + +- **Predicate API:** High performance RESTful service that evaluates transaction adherence to the application’s policy, returning an attestation. +- **Web application:** The server hosting the financial application business logic, which calls Predicate API. +- **Onchain application:** The smart contract(s) containing the application business logic, which has one or more functions requiring a Predicate attestation to execute (also known as Predicated Functions). +- **Predicate registry:** The smart contracts/programs used to verify attestations and enforce policy-to-client bindings. + +​ +![Predicate system diagram](https://mintcdn.com/aethos/xFQko6f71IQeLxjv/images/system.png?fit=max&auto=format&n=xFQko6f71IQeLxjv&q=85&s=386f8f152933be3f1dec54ce8a90b35c) + +**Attestation process:** + +The user submits their transaction and associated details (e.g. amount) via a web app, and the Predicate API validates the request against the latest policy and returns an attestation, which the user then includes in their onchain transaction for verification and execution. + +![Predicate sequence diagram](https://mintcdn.com/aethos/qz-wtxIt_2jZVTke/images/sequence.png?w=1650&fit=max&auto=format&n=qz-wtxIt_2jZVTke&q=85&s=c5ca38d20a1f2f47afe6a2935862bcbc) + +**How it works for asset issuers:** + +- **Monitoring:** Predicate monitors for new addresses matching your policy’s specified risk characteristics (e.g. inclusion on the OFAC sanctions list) and ingests new ones with sub-15 minute wait time. +- **Detection:** New risk-excluded addresses are identified, categorized, and queued for onchain enforcement. +- **Enforcement:** New addresses are automatically frozen, blocked, or temporarily paused depending on policy specifications, for all enrolled token contracts submitted by asset issuer. +- **Visibility:** The Predicate dashboard provides audit trail of all address actions (freezes, blocks, temporary pauses) and timestamps. + +## Privacy domains + +- Compliant privacy: Allows privacy protocols and chains to ensure their tools aren’t abused by malicious actors + +## Enterprise demand and use cases + +Target audience is organizations operating in regulated markets or catering to capital from regulated markets. This includes RWA and institutional DeFi companies, privacy protocols, fintechs, financial institutions, asset issuers, and payment providers. + +## Technical details + +- Policies are defined offchain and enforced onchain via API calls to Predicate, which returns cryptographic attestation in sub-second latency for all transactions verifying whether transactions adhere to policy +- Predicate integrates and enforces policies at the smart contract level +- Reporting available in Predicate app for all transactions verified, including logs for why denied transactions did not pass policy + +## Strengths + +- Provides a unified compliance layer that abstracts away the need to manage providers across AML risk scoring, geolocation, KYC/KYB and identity, etc. +- Enables compliance enforcement on permissionless blockchain networks +- Provides more robust compliance enforcement than the common framework of frontend compliance checks, which are easily bypassed via direct contract calls +- Allows privacy projects to to implement compliance best practices and reduce risk +- Provides redundancy of data providers to ensure policies remain operational if one provider fails +- Enforces policy with sub-second latency, ensuring no additional friction for compliant users +- Provides the compliance guarantees institutions need to conduct financial operations and deploy financial products onchain + +## Risks and open questions + +- Possible centralization risk under most deployments (but also possible to deploy as decentralized operator network) +- Policies are only as strong as underlying data +- Some policies may impact privacy if required for transaction validation. Privacy projects must balance this reality with compliance needs when setting policies. Please note however that under no circumstances does Predicate publicize private information (e.g. KYC/KYB information) on chain or offchain, regardless of policy or application infrastructure + +## Links: + +- Predicate site: [https://predicate.io/](https://predicate.io/) +- Predicate docs: [https://docs.predicate.io/v2/essentials/overview](https://docs.predicate.io/v2/essentials/overview) +- Risk Management Framework for Institutional Liquidity on Uniswap V4 (white paper by Predicate and Paxos): [https://predicate.io/blog/risk-management-framework-for-institutional-liquidity-on-uniswap-v4](https://predicate.io/blog/risk-management-framework-for-institutional-liquidity-on-uniswap-v4) + +[image1]: + +[image2]: