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

# Requesting verification

# Requesting Verification

Registration puts a resource on-chain. Verification elevates it from "registered" to "attested by validators", giving consumers a protocol-level signal that the resource is legitimate at a specified trust level. This guide walks through the three verification levels, their fees, and the end-to-end request flow.

## The three levels

| Level         | On-chain value | Who attests                    | Quorum | Typical use                           |
| ------------- | -------------- | ------------------------------ | ------ | ------------------------------------- |
| BASIC         | 0              | Any active validator           | 3 of 5 | Personal wallets, small dApps         |
| ENHANCED      | 1              | Professional+ validators       | 5 of 7 | Merchant payouts, DAO treasury subset |
| INSTITUTIONAL | 2              | Enterprise+ validators (KYC'd) | 7 of 9 | Exchange deposit wallets, custodians  |

Fees scale with level: governance sets the exact amounts via the `FeeManager`; see [Fee Model](../protocol/fee-model.md) for current values. All fees are denominated in `NOTA`.

## When to request which

* **BASIC** is appropriate for most self-custody wallets and public contracts where the operator wants a cheap, fast trust signal.
* **ENHANCED** raises the evidence bar. Expect validators to perform additional checks: on-chain behavioral analysis, proof of ownership, recent activity thresholds.
* **INSTITUTIONAL** is for regulated entities. Validators at this level typically require off-chain KYC documents delivered through a side channel and hold operators to periodic re-verification.

## The flow

```mermaid theme={"system"}
sequenceDiagram
    participant Owner
    participant VerificationEngine
    participant Validator1
    participant Validator2
    participant Validator3
    Owner->>VerificationEngine: requestVerification(resourceId, level)
    Note right of VerificationEngine: Deducts fee in NOTA
    VerificationEngine-->>Validator1: event VerificationRequested
    VerificationEngine-->>Validator2: event VerificationRequested
    VerificationEngine-->>Validator3: event VerificationRequested
    Validator1->>VerificationEngine: submitAttestation(approved=true)
    Validator2->>VerificationEngine: submitAttestation(approved=true)
    Validator3->>VerificationEngine: submitAttestation(approved=true)
    Note right of VerificationEngine: Quorum reached
    VerificationEngine->>VerificationEngine: update verificationLevel on NotaRegistry
    VerificationEngine-->>Owner: event VerificationApproved
```

## Prerequisites

* The resource must already be registered on-chain (see [Registering a Resource](registering-a-resource.md)).
* Your account must hold enough NOTA to pay the level's fee, plus enough native gas for the transaction.
* The `VerificationEngine` must be approved as a NOTA spender for at least the fee amount.

## Step 1: Check the fee

```typescript theme={"system"}
import { VerificationLevel } from "@notareum/sdk";

const fee = await ntm.verification.getVerificationFee(VerificationLevel.ENHANCED);
console.log(`Enhanced fee: ${fee} NOTA wei`);
```

## Step 2: Approve NOTA

```typescript theme={"system"}
import { Contract } from "ethers";

const nota = new Contract(
  contracts.notaToken,
  ["function approve(address,uint256) returns (bool)"],
  signer
);
await (await nota.approve(contracts.verificationEngine, fee)).wait();
```

## Step 3: Request verification

```typescript theme={"system"}
const txHash = await ntm.verification.requestVerification(
  resourceId,
  VerificationLevel.ENHANCED
);
console.log("Verification requested:", txHash);
```

The `VerificationRequested` event is emitted and a numeric `requestId` is assigned. Validators pick up the event, evaluate the resource against the level's policy, and submit `submitAttestation(resourceId, approved)` transactions.

## Step 4: Track progress

```typescript theme={"system"}
const req = await ntm.verification.getVerificationRequest(requestId);
console.log(req.status, req.approvalCount, req.rejectionCount);
```

`VerificationStatus` values are `PENDING` (0), `APPROVED` (1), `REJECTED` (2), `EXPIRED` (3). On approval, the registry's `verification_level` for the resource ID is updated atomically.

## Step 5: Confirm elevation on the registry

```typescript theme={"system"}
const info = await ntm.registry.getResource(resourceId);
console.log("Verified level:", info.verificationLevel);
```

This is what third-party wallets and explorers read. Once it changes, every consumer sees the same elevated level without needing any side channel.

## If the request is rejected

If the rejection count reaches quorum first, the level does not change and the fee is partially refunded per the `FeeManager` policy. Common causes: tampered `.nota` file, insufficient evidence at the requested level, conflict with existing registrations. See [Dispute Resolution](../protocol/dispute-resolution.md) to challenge an outcome.

## Next steps

* [Validator Network](../protocol/validator-network.md)
* [Verification Engine protocol page](../protocol/verification-engine.md)
* [Becoming a Validator](becoming-a-validator.md) to attest yourself