# Identity Proofs (EVM)

### Background

On EVM chains, Fairway doesn’t mint identity tokens. Instead, compliance status is expressed through **EAS attestations** that encode:

* **When the user last passed KYC** (`kyc_verified_at`).
* **Current sanctions/risk freshness** (`sanctions_epoch`).
* **Optional compliance claims** (jurisdiction, accreditation, risk score).
* **Commitment root** linking to Midnight proofs.

These attestations are:

* **Issued off-chain** by the Fairway Cloud Agent (Witness) after reading KYC data from decentralized storage.
* **Anchored on-chain** in the EAS registry.
* **Referenced** in dApps through the Fairway **PolicyEngine**:

```solidity
(bool ok, uint32 reason) = policyEngine.isEligible(user, ruleBytes);

```

***

### Components

* **EAS (Ethereum Attestation Service)** → canonical registry of typed attestations.
* **Fairway Verifier** → contract that validates attestations, issuer trust, timestamp, and sanctions epoch.
* **PolicyEngine** → single-call YES/NO eligibility check for dApps.
* **IdentityRegistry** → governance-controlled list of trusted issuers and rules.
* **Optional façade tokens** → ERC-5484 / ERC-5192 for UX or whitelist compatibility.

***

### Flow

```mermaid
sequenceDiagram
  participant User as Wallet
  participant Agent as Fairway Cloud Agent (Witness)
  participant EAS as EAS Registry
  participant Verifier as Fairway Verifier
  participant Policy as PolicyEngine
  participant dApp as Protocol

  User->>Agent: Completes off-chain KYC
  Agent->>EAS: Issue EIP-712 attestation {kyc_verified_at, sanctions_epoch, claims}
  dApp->>Policy: isEligible(user, ruleBytes)
  Policy->>Verifier: Verify attestation + signature + epoch freshness
  Verifier->>EAS: Resolve attestation UID
  Verifier->>Policy: Return (ok, reason)
  Policy->>dApp: YES / NO

```

***

### Example Attestation Schema

```json
{
  "name": "FairwayComplianceV2",
  "fields": [
    { "name": "subject", "type": "address" },
    { "name": "policyId", "type": "bytes32" },
    { "name": "kyc_verified_at", "type": "uint64" },     // unix timestamp
    { "name": "sanctions_epoch", "type": "uint64" },     // rolling freshness counter
    { "name": "jurisdictionSet", "type": "uint16" },
    { "name": "accredited", "type": "bool" },
    { "name": "risk_profile_score", "type": "uint16" },
    { "name": "commitmentRoot", "type": "bytes32" }
  ],
  "revocable": true}

```

***

### Rule Encoding

Policies are defined once in the **IdentityRegistry**.

dApps pack rules as `ruleBytes`:

```solidity
bytes32 policyId = keccak256("POOL-A.KYC2.EU-ACCREDITED");

bytes memory ruleBytes = abi.encode(
    policyId,
    userAttestationUID,   // EAS UID
    expectedEpochRoot,    // sanctions freshness
    maxKycAge             // e.g. 180 days
);

```

***

### Validator Checks

1. **Attestation validity** → issuer signature + schema match.
2. **KYC freshness** → `block.timestamp - kyc_verified_at <= maxKycAge`.
3. **Sanctions freshness** → `sanctions_epoch == latestEpochRoot`.
4. **Other claims** → jurisdiction, accreditation, or risk score thresholds.

***

### Benefits

* **PII-free** → no sensitive docs stored on-chain.
* **Separation of duties** → KYC timestamp (long-lived) + sanctions epoch (short-lived).
* **Compliant** → FATF/AMLD rules enforced per jurisdiction by dApp-defined max age.
* **Interoperable** → compatible with ERC-3643 TransferManager, EAS tooling, and SBT façades.
* **Simple DX** → dApps use a single `isEligible()` call.
* **Auditable** → `commitmentRoot` links attestations back to Midnight ZK proofs.

***

### Next Steps

* [Learn about Revocation Epochs & Freshness.](https://docs.fairway.global/~/revisions/X8Jlv38w66ja0MIFhnqJ/developers/core-concepts/revocation-epochs-and-freshness)
* [Explore Build on EVM for full Solidity integration.](https://docs.fairway.global/~/revisions/X8Jlv38w66ja0MIFhnqJ/developers/build-on-evm)
* [See the ERC-3643 Adapter for RWA integration.](https://docs.fairway.global/~/revisions/Dk4tf7CZM5uuRFD9IJ8x/developers/build-on-evm/attestation-led-compliance-eas-erc-1271-erc-3643/adapter-for-erc-3643-transfermanager)&#x20;


---

# 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.fairway.global/developers/core-concepts/identity-proofs-evm.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.