# 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: 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:

```
GET https://docs.bitbadges.io/token-standard/learn/approval-criteria/address-checks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.