> For the complete documentation index, see [llms.txt](https://docs.valantis.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.valantis.xyz/amms-and-vaults/design-space/modules/verifier-module.md).

# Verifier Module

<figure><img src="https://986147118-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1hNJeG4CApeBcE2NlR61%2Fuploads%2Fgit-blob-955c8d84f41154fd0f38d0764ed61ed2ec1055d5%2FVerifier%20Module%20Fig.%201_V2%20(1).jpg?alt=media" alt=""><figcaption><p>Verifier Module in context</p></figcaption></figure>

The Verifier Module is an optional module that individually manages authentication and access to the following pool functions:

* `swap`
* `depositLiquidity`
* `withdrawLiquidity`

The Verifier Module passes verification bytes encoded data to Liquidity Modules, allowing for different swap logic for different parties. The verifier module can also be used for simply gating access to these functions in a permissioned setup.

`verifierModule` can be set in the constructor as an immutable value. If set as `address(0)` the pool will be completely permissionless, and none of the functions described below would apply.

`verifierModule` has to implement the following function:

```solidity
function verify(
        address _user,
        bytes calldata _verificationContext,
        uint8 accessType
    ) external returns (bool success, bytes memory returnData);
```

* `_user` The address of msg.sender which is calling either `swap`, `depositLiquidity` or `withdrawLiquidity` in the Sovereign Pool. This is used as a convenient way to perform authentication of external callers.
* `_verificationContext` Optional byte encoded calldata. This can be used to pass off-chain or external data which is critical to the module's logic.
* `accessType` Flag which tells the Verifier Module through which pool function it is being called:
  * `accessType=0` if `verify` is being called via `swap`
  * `accessType=1` if `verify` is being called via `depositLiquidity`
  * `accessType=2` if `verify` is being called via `withdrawLiquidity`

The verify function returns two variables:

* `success` If True, the pool’s execution control flow will continue uninterrupted, otherwise it will revert.
* `returnData` Byte encoded data to be passed to Liquidity Module’s `getLiquidityQuote` function, in the case of `success=True`

Verifier modules make it straightforward to constrain/customize access to liquidity pools without requiring changes to the Liquidity Module or core protocol contracts. This allows for custom verification logic while preserving pre-established security assumptions.