> For the complete documentation index, see [llms.txt](https://docs.selcier.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.selcier.xyz/markets-and-capital/gated-pools.md).

# Gated AMM pools

A company can opt a share class into continuous AMM trading on Robinhood Chain, where the PoolGate hook applies transfer rules to each swap and liquidity change.

Scheduled windows and bilateral quotes do not suit every company, and some want a share class to trade continuously. Permissioned pools meet that need. Built on Robinhood Chain DEX infrastructure, they pair a Selcier Share Token with a stablecoin, and a hook contract named `PoolGate` holds each interaction to the share class's [transfer rules](/fundamentals/compliance-modules.md).

Nothing happens unless a company opts in. Enabling is per share class in [Console](/the-platform/issuer-console.md), and disabling is possible whenever the company chooses.

## Making a pool eligible

Transfers of a Selcier Share Token require a recipient with a verified identity. Since no person stands behind a pool contract, it has to be identified differently.

Approval by a company places the pool's address in that company's `IdentityRegistry`, carrying a `VENUE` claim that marks it as an approved venue for the share class. The `RuleEngine` handles such an address as a pass-through. Shares may flow in and out, on condition that the wallet at the other end of the trade passes all rules.

Each `VENUE` claim belongs to one share class, and the company is able to revoke it. Revocation halts trading in the pool. It also ends the pass-through for shares leaving the pool, so the share side of a liquidity withdrawal then faces the token's sender identity check.

## Checks made by PoolGate

Ahead of each swap or liquidity change in an approved pool, `PoolGate` works out the end wallet, that is, whichever address will send or receive shares, and tests that wallet against the pool using `canTransfer`.

| What the user does   | How it is checked                                                                                                                             |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Buys shares          | `beforeSwap(recipient, sharesOut)` is called by the pool and evaluates `canTransfer(pool, recipient, sharesOut)`                              |
| Sells shares         | Sender rules run inside the share token at the moment shares enter the pool                                                                   |
| Adds liquidity       | `beforeAddLiquidity(provider)` is called by the pool and applies all recipient-side rules to the provider, treating them as a share recipient |
| Moves an LP position | `beforeTransferPosition(from, to)` is called by the pool and runs that same test on the incoming owner                                        |

Failure means no swap and no liquidity change: `TransferNotAllowed(reasonCode)` is the revert the hook raises. To get the same reason code with no revert, use the views `checkSwap` and `checkLiquidityProvider`. Taking shares out of a pool counts as a normal transfer from the pool, which means the recipient gets checked by the share token.

Routers and aggregators are welcome, subject to one condition: the end recipient has to reach the hook. `PoolGate` looks at the recipient and ignores the router, so a router unable to name its recipient is shut out.

## Every rule stays in force

Pools relax nothing. Here is how each kind of rule applies:

| Rule                 | Effect inside a pool                                                                                                                                   |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Holding periods**  | Selling into a pool is impossible for a locked lot. A pool purchase creates a separate lot, starting whatever holding period the class has configured. |
| **Holder caps**      | `HOLDER_CAP_REACHED` is the failure when a purchase would bring in a holder past the `HolderCapModule` limit.                                          |
| **Ownership caps**   | `MAX_OWNERSHIP_EXCEEDED` is the failure when a purchase would push a wallet past the `MaxOwnershipModule` limit.                                       |
| **Transfer windows** | Under a `TransferWindowModule`, trading in the pool is possible only during an open window.                                                            |
| **ROFR**             | A class with a `ROFRModule` is barred from pools, as an instant swap leaves no way to exercise a right of first refusal.                               |
| **Pause**            | Pausing the token halts trading in all of that class's pools.                                                                                          |

## Providing liquidity

An LP position represents a claim over shares in the pool, so restrictions match those on the shares. Providers must be verified holders who pass the transfer rules, and a position can move only to another eligible holder. Where a company wants a named group of providers, such as a market maker it has engaged, it can use the share class's rules to require a claim held by those providers alone.

## Pool prices versus valuations

Market activity sets a pool price, through the curve and the trades made against it. Such prices are not Reference Valuations, and Selcier never publishes them that way. For comparison, Portfolio and the Explorer display the pool price beside the latest Reference Valuation with a clear label on each.

## Who collects what

Liquidity providers earn the pool's own swap fee. `PoolGate` confines itself to rule checks and collects nothing. More detail is in [How trades settle](/markets-and-capital/how-trades-settle.md) and [Fees](/reference/fees.md).

{% hint style="warning" %}
Continuous trading needs a class with sufficient holders and float. Most private companies get better price discovery from [Scheduled Liquidity Windows](/markets-and-capital/scheduled-windows.md), so a pool is best treated as an addition to them.
{% endhint %}


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.selcier.xyz/markets-and-capital/gated-pools.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.