> 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/composability.md).

# Composability and DeFi

A tokenised security is only as useful as the protocols it can interact with. cyberSCRIP is the layer where that interaction happens.

## What cyberSCRIP unlocks

* **AMM liquidity.** A LiquiLeX Uniswap v4 pool can quote a cyberSCRIP against USDC continuously. The `MetalexIssuerFeeHook` routes a portion of swap fees to the issuer, turning the cyberCORP into a tiny perpetual fee-receiver on its own scrip.
* **Lending and money markets.** A cyberSCRIP, like USDC, is an ERC-20 with optional compliance powers. It can be listed as collateral on lending protocols that accept ERC-20s with admin extensions.
* **Vesting and streaming.** Any standard ERC-20 vesting contract works.
* **Programmable distributions.** Dividends, buybacks, or other holder- facing flows can be paid in or settled against cyberSCRIP.

## What you trade off

### Restricted ERC-20

A cyberSCRIP with a `WhitelistTransferHook` is not a free-floating ERC-20. Some integrations (especially permissionless ones) will reject it. Operators should either pick an open compliance model (no transfer hook, compliance at the de-scripification boundary) or accept that their scrip will only flow through whitelisted venues.

### Compliance powers are visible

Force transfer / force burn / freeze / blocklist are public functions on the cyberSCRIP, even when not currently invoked. Some lending protocols will decline to list any ERC-20 with these powers. The **permanent disable** toggles (`permanentlyDisableForceTransfer`, etc.) exist for exactly this reason: an issuer can credibly commit to an open posture.

### Token possession ≠ registered ownership

This is by design (see [the dual-token model](/metalex-docs/protocol-explanation/dual-token-model.md)) but it means naive integrations may make wrong assumptions. The cyberSCRIP holder is not the holder of record. The cyberCERT holder is. Anywhere registered ownership matters (voting, dividends to record holders, §219 lists), reads must go through the cert layer.

## The two LiquiLeX models, side-by-side

| Aspect                 | Whitelisted pool                        | Open pool                                 |
| ---------------------- | --------------------------------------- | ----------------------------------------- |
| Per-swap check         | Full LeXcheX credential                 | Optional zkPassport (sanctions / Reg S)   |
| Pool address           | Only whitelisted addresses can hold LP  | Anyone can hold LP                        |
| Holder of record       | Same regardless of trades               | Same regardless of trades                 |
| De-scripification gate | Standard                                | Standard (this is where compliance lives) |
| Best for               | High-touch private credits, Reg D names | Reg S issuances, public-style scrip       |

## See also

* [How-to: Deploy a LiquiLeX pool](/metalex-docs/protocol-how-to-guides/deploy-liquilex-pool.md)
* [Compliance architecture](/metalex-docs/protocol-explanation/compliance-architecture.md)
* [Hooks](/metalex-docs/protocol-reference/hooks.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/composability.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.