> For the complete documentation index, see [llms.txt](https://gabriel-j-shapiro.gitbook.io/metalex-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gabriel-j-shapiro.gitbook.io/metalex-docs/protocol-explanation/compliance-architecture.md).

# Compliance architecture

The protocol does not bake any specific compliance regime into the contracts. Instead, it exposes a small number of **extension points** — conditions, credentials, and the de-scripification boundary — and lets issuers compose them to satisfy whatever rules apply to them (Reg D, Reg S, local private-placement regimes, qualified-purchaser rules, sanctions screening, etc.).

## The two big extension points

### 1. `ICondition` everywhere

Every state transition that matters legally — issuance, scripification, de-scripification, deal close, round acceptance — accepts an `ICondition`. The condition is evaluated at the moment of state change.

This means you can express:

* "This investor must hold a valid LeXcheX accreditation credential."
* "This buyer must have a zkPassport proof that they are non-US."
* "This recipient must hold a soulbound club-membership NFT."
* "This transaction must occur after our SEC Form D filing block."

…and any composition of the above.

### 2. The de-scripification boundary

The critical insight: **compliance at the register boundary, freedom in between**. cyberSCRIP can flow freely (or under light gates); when someone wants to become the holder of record, the full gate runs.

This pattern lets you:

* Have a globally tradable AMM market on private equity.
* Avoid having to KYC every counterparty in that market.
* Still maintain a fully compliant register at the level that matters legally.

For regulated instruments where even the swap layer must be gated, the whitelisted-pool model checks credentials on every swap. Both models live in the same contract suite.

## Credentials: LeXcheX

LeXcheX is the protocol's accreditation and KYC-AML credential layer (see [`LexChex`](/metalex-docs/protocol-reference/contracts/lexchex.md)). Credentials are soulbound NFTs minted to a wallet after the holder completes onboarding (questionnaire, portfolio valuation, agreement countersigning). The credentials can be checked by `lexchexCondition` anywhere in the protocol.

For onchain wealth-based accreditation ("my $5M ETH portfolio makes me qualified"), see the reference UI at [`apps/lexchex-web`](https://github.com/MetaLex-Tech/metalex-webapp/tree/develop/apps/lexchex-web) in `metalex-webapp`.

## Credentials: zkPassport

For Reg S and sanctions-screening purposes, `NonUSNationalityCondition` integrates a zkPassport proof that the address is held by a non-US person. Unlike LeXcheX, zkPassport is zero-knowledge: the address proves nationality status without revealing identity. Useful at the swap layer of open LiquiLeX pools.

## Reg D vs. Reg S

| Regime         | Typical pattern                                                                                                    |
| -------------- | ------------------------------------------------------------------------------------------------------------------ |
| Reg D (US)     | LeXcheX accreditation + KYC required on all primary investors and on de-scripification. Whitelisted LiquiLeX pool. |
| Reg S (non-US) | zkPassport non-US proof at primary, optional light zkPassport gate at swap, full credential on de-scripification.  |
| Combined       | `OrCondition` allowing either path; cyberCORP serves both audiences with two issuance flows.                       |

## Holder caps

`CyberCertPrinter.setMaxHolders(n)` and `CyberScrip.setMaxHolders(n)` let you monitor and enforce 12(g) thresholds (US) and their analogues. The Mainframe UI surfaces these alongside the holder lists for proactive management.

## See also

* [Conditions](/metalex-docs/protocol-reference/conditions.md)
* [`LexChex`](/metalex-docs/protocol-reference/contracts/lexchex.md)
* [How-to: Gate state transitions with conditions](/metalex-docs/protocol-how-to-guides/gate-with-conditions.md)
* [Composability and DeFi](/metalex-docs/protocol-explanation/composability.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://gabriel-j-shapiro.gitbook.io/metalex-docs/protocol-explanation/compliance-architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.