> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kleros.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Integration Guide

> Verify unique humans with Proof of Humanity V2 through CrossChainProofOfHumanity on Ethereum Mainnet and Gnosis Chain.

# Proof of Humanity 2.0 Integration Guide

This guide is for developers who want to verify whether an address belongs to a registered human.

<Note>
  Integrators consume identity through **CrossChainProofOfHumanity**. PoH operators manage the registry through **ProofOfHumanity**. If you are integrating PoH into an application, you only need CrossChainProofOfHumanity.
</Note>

***

## Quick start: Verify a human

Use `CrossChainProofOfHumanity` as the integration contract on every supported chain. It exposes both locally registered and synchronized cross-chain humanities.

```solidity theme={null}
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface ICrossChainProofOfHumanity {
    function isHuman(address account) external view returns (bool);
    function humanityOf(address account) external view returns (bytes20);
}

contract HumanOnly {
    ICrossChainProofOfHumanity public immutable proofOfHumanity;

    error NotHuman();

    constructor(address crossChainProofOfHumanity) {
        proofOfHumanity = ICrossChainProofOfHumanity(crossChainProofOfHumanity);
    }

    modifier onlyHuman() {
        if (!proofOfHumanity.isHuman(msg.sender)) revert NotHuman();
        _;
    }

    function humanOnlyAction() external onlyHuman {
        // Application logic
    }
}
```

### CrossChainProofOfHumanity addresses

| Network          | CrossChainProofOfHumanity                    |
| ---------------- | -------------------------------------------- |
| Ethereum Mainnet | `0xa478095886659168E8812154fB0DE39F103E74b2` |
| Gnosis Chain     | `0x16044E1063C08670f8653055A786b7CC2034d2b0` |

* Use `isHuman(address)` when you only need human verification.
* Use `humanityOf(address)` and store application data by humanity ID when identity must survive wallet changes.

<Warning>
  Cross-chain state is delivered through bridge synchronization, so a recent registration, revocation, or transfer may not appear on another chain immediately.
</Warning>

***

## Identity lookup

Once you have a `humanityId` from `humanityOf(address)`, these read-only functions provide additional detail:

```solidity theme={null}
function isClaimed(bytes20 _humanityId) external view returns (bool);
function boundTo(bytes20 _humanityId) external view returns (address);
```

| Function                | Purpose                                                     |
| ----------------------- | ----------------------------------------------------------- |
| `isClaimed(humanityId)` | Returns true if the humanity ID is actively claimed         |
| `boundTo(humanityId)`   | Returns the wallet address currently bound to a humanity ID |

For the full status of a humanity (vouching state, pending requests, expiration, owner) via `getHumanityInfo(humanityId)`, and for the registry management functions used by operators, see the [Smart Contracts](/developers/products/poh/smart-contracts) reference.

***

## Soulbound Identity Design

PoH V2 follows the principle: **1 human → 1 humanity ID ↔ 1 wallet address**.

The `humanityId` is a soulbound identifier that persists across wallet transitions. If a user loses wallet access, they can re-register with a new address while keeping the same `humanityId`. Applications that key reputation, assets, or history by `humanityId` rather than by address preserve them across the user's wallet changes.

```
humanity.owner == lostAddress      // Lost access
humanity.owner == address(0)       // Removal requested
humanity.owner == newAddress       // Re-registered with new wallet
```

<Note>
  V1 users have a `humanityId` equal to their original registration address (`bytes20(address)`). V2 users receive a new unique `humanityId` at registration. The `isHuman()` call automatically covers V1 registrations through the Fork Module.
</Note>

***

## Registry contract addresses

Operators who manage the registry directly interact with `ProofOfHumanity` (and, on Ethereum Mainnet, `ProofOfHumanityExtended`).

<Tabs>
  <Tab title="Gnosis Chain">
    | Contract                  | Address                                      |
    | ------------------------- | -------------------------------------------- |
    | ProofOfHumanity           | `0xa4AC94C4fa65Bb352eFa30e3408e64F72aC857bc` |
    | CrossChainProofOfHumanity | `0x16044E1063C08670f8653055A786b7CC2034d2b0` |
    | AMB Bridge Gateway        | `0x6Ef5073d79c42531352d1bF5F584a7CBd270c6B1` |
  </Tab>

  <Tab title="Ethereum Mainnet">
    | Contract                  | Address                                      |
    | ------------------------- | -------------------------------------------- |
    | ProofOfHumanityExtended   | `0xbE9834097A4E97689d9B667441acafb456D0480A` |
    | CrossChainProofOfHumanity | `0xa478095886659168E8812154fB0DE39F103E74b2` |
    | AMB Bridge Gateway        | `0xddafACf8B4a5087Fc89950FF7155c76145376c1e` |
    | Fork Module               | `0x068a27Db9c3B8595D03be263d52c813cb2C99cCB` |
  </Tab>
</Tabs>

***

## What's Next?

<CardGroup cols={2}>
  <Card title="PoH Overview" icon="fingerprint" href="/developers/products/poh/overview">
    Architecture and technical details
  </Card>

  <Card title="Smart Contracts" icon="file-contract" href="/developers/products/poh/smart-contracts">
    Core interfaces and data structures
  </Card>
</CardGroup>