> For the complete documentation index, see [llms.txt](https://docs.bitbadges.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bitbadges.io/token-standard/learn/approval-criteria/address-checks.md).

# Address Checks

Additional restrictions on address types for transfer approval. These checks validate whether addresses involved in a transfer meet specific requirements (e.g., must be an EVM contract, must not be a liquidity pool).

## Interface

```typescript
interface AddressChecks {
    /** Require the address to be an EVM contract. */
    mustBeEvmContract?: boolean;
    /** Require the address to not be an EVM contract. */
    mustNotBeEvmContract?: boolean;
    /** Require the address to be a liquidity pool. */
    mustBeLiquidityPool?: boolean;
    /** Require the address to not be a liquidity pool. */
    mustNotBeLiquidityPool?: boolean;
}
```

## How It Works

Address checks validate the type of addresses involved in a transfer. The checks are applied to different parties depending on the approval type:

### Collection Approvals

Collection approvals can check all three parties:

* **`senderChecks`**: Validates the sender address (`from`)
* **`recipientChecks`**: Validates the recipient address (`to`)
* **`initiatorChecks`**: Validates the initiator address (`initiatedBy`)

### Incoming Approvals

Incoming approvals can check the sender and initiator (but not the recipient, since the recipient is always the approval owner):

* **`senderChecks`**: Validates the sender address (`from`)
* **`initiatorChecks`**: Validates the initiator address (`initiatedBy`)

### Outgoing Approvals

Outgoing approvals can check the recipient and initiator (but not the sender, since the sender is always the approval owner):

* **`recipientChecks`**: Validates the recipient address (`to`)
* **`initiatorChecks`**: Validates the initiator address (`initiatedBy`)

## Available Checks

### EVM Contract Checks

* **`mustBeEvmContract`**: Requires the address to be an EVM smart contract
* **`mustNotBeEvmContract`**: Requires the address to NOT be an EVM smart contract

### Liquidity Pool Checks

* **`mustBeLiquidityPool`**: Requires the address to be a liquidity pool
* **`mustNotBeLiquidityPool`**: Requires the address to NOT be a liquidity pool

## Examples

### Collection Approval: Require EVM Contract Recipients

Only allow transfers to EVM contracts:

```json
{
    "approvalCriteria": {
        "recipientChecks": {
            "mustBeEvmContract": true
        }
    }
}
```

### Collection Approval: Block Liquidity Pool Senders

Prevent transfers from liquidity pools:

```json
{
    "approvalCriteria": {
        "senderChecks": {
            "mustNotBeLiquidityPool": true
        }
    }
}
```

### Incoming Approval: Require EVM Contract Initiators

Only allow transfers initiated by EVM contracts:

```json
{
    "approvalCriteria": {
        "initiatorChecks": {
            "mustBeEvmContract": true
        }
    }
}
```

### Outgoing Approval: Block Liquidity Pool Recipients

Prevent sending tokens to liquidity pools:

```json
{
    "approvalCriteria": {
        "recipientChecks": {
            "mustNotBeLiquidityPool": true
        }
    }
}
```

### Combined Checks

You can combine multiple checks for a single party:

```json
{
    "approvalCriteria": {
        "recipientChecks": {
            "mustBeEvmContract": true,
            "mustNotBeLiquidityPool": true
        },
        "initiatorChecks": {
            "mustNotBeEvmContract": true
        }
    }
}
```

## Use Cases

* **Smart Contract Integration**: Require transfers to/from specific EVM contract types
* **Liquidity Protection**: Prevent transfers to/from liquidity pools to maintain token economics
* **Security**: Enforce that certain operations can only be initiated by contracts or regular addresses
* **Protocol Compliance**: Ensure transfers comply with protocol-specific address requirements

## Constraints

All checks are evaluated after the address lists (`toList`, `fromList`, `initiatedByList`) are matched. An address must first be in the appropriate list, then pass the address checks.


---

# 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://docs.bitbadges.io/token-standard/learn/approval-criteria/address-checks.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.