# 5.1 SBT Architecture

### 5.1 SBT Architecture 

At the heart of Omni-ID technology is a Dynamic Soulbound Token. We abandoned the ERC-721 standard used for art collection and adopted the ERC-5192 (Minimal Soulbound NFTs) standard, which is designed specifically for “non-transferable relationships.”

#### 5.1.1 Compliance with ERC-5192 

1. Why choose ERC-5192?

The traditional ERC-721 standard allows for the free transfer of tokens, which is fatal to reputation systems—if a "five-star" account can be sold to malicious fraudsters, then reputation becomes worthless.

ERC-5192 is the "minimum soul-binding interface" standard established by the Ethereum community. It enforces locking logic on top of ERC-721.

2\. Locking Mechanism

The Omni-ID contract rewrote the underlying transfer functions, physically blocking the transfer path at the code level:

Solidity

```
// Omni-ID Core Logic
function transferFrom(address from, address to, uint256 tokenId) public override {
    revert("OmniID: Soulbound token cannot be transferred");
}

function safeTransferFrom(address from, address to, uint256 tokenId) public override {
    revert("OmniID: Soulbound token cannot be transferred");
}

// ERC-5192 Interface Implementation
function locked(uint256 tokenId) external view returns (bool) {
    return true; // Permanently locked upon minting
}
```

* Uniqueness constraint: Each wallet address is limited to one Omni-ID in Mint.`balanceOf(user)` It is always equal to 0 or 1.
* Revocability: Although users cannot transfer their IDs, the protocol has the highest authority (triggered by DAN adjudication) to execute`burn()` This is the ultimate punishment for serious fraudsters (such as those proven to have carried out Sybil attacks or malicious scams) – a “digital death penalty.”

#### 5.1.2 Metadata Storage and Update Logic 

Omni-ID had to resolve a contradiction: reputation scores needed to be frequently accessed by smart contracts (e.g., to calculate fee discounts), but complete profile data was too massive to be stored entirely on the blockchain.

To address this, we adopted a "dual-layer storage" architecture.

**A. Layer 1: On-Chain Reputation State** 

Storage location: Ethereum/L2 State Trie 

Data content: Only the most core quantitative indicators are stored.

Solidity

```
struct IdentityStatus {
    uint16 score;        // Current Omni-Score (0-1000)
    uint32 totalTx;      // Total transaction count
    uint8 tier;          // User Level (Newbie/Expert/Master)
    bool isHuman;        // ZK-KYC status flag
}
mapping(uint256 => IdentityStatus) public identityData;
```

* Purpose: To allow other smart contracts (such as OES escrow contracts, DeFi lending protocols) to `IIdentity.getScore(user)` It atomically reads user credit information, thereby automating the logic of "high credit, no deposit required" or "low fee".

**B. Layer 2: Off-Chain Contextual Metadata** 

Storage location: IPFS / Arweave

Data content: Rich, visually appealing data.

JSON

```
{
  "name": "Alice.eth",
  "description": "Solidity Developer | 98% Success Rate",
  "image": "ipfs://bafy...", // Dynamic PFP based on Tier
  "attributes": [
    {"trait_type": "Skills", "value": "Python"},
    {"trait_type": "Badges", "value": "Top Seller 2025"},
    {"trait_type": "Review_Last", "value": "Great work, very fast!"}
  ]
}
```

* Linking method: On-chain storage only `tokenURI` pointer.
* Purpose: To provide front-end DApps, OpenSea, or recruitment platforms with a way to display users' detailed resumes.

**C. The Dynamic Update Cycle** 

Omni-ID is not a static NFT; it evolves in real time with user behavior.

1. Trigger:

   When an OES escrow transaction is finalized or arbitration is completed, the OES contract triggers emitReputationUpdate.
2. Calculation:

   The on-chain ReputationController contract calculates the new score increment $\Delta S$ according to a predefined formula (see Section 5.2).
3. State Mutation:

   The controller calls the Omni-ID contract's updateScore(tokenId, newScore).

   * Access control: This function is modified by the following modifiers `onlyProtocol` Protect your data and strictly prohibit users from modifying their scores.
4. Metadata Refresh:

   If a user's level changes (e.g., from Level 1 to Level 2), the contract will trigger the BatchMetadataUpdate event (EIP-4906), notifying platforms such as OpenSea to fetch the latest NFT image again (e.g., a medal changes from bronze to gold).

***

> This section demonstrates to technical readers, through a two-layer storage architecture, that Omni-ID possesses both DeFi composability (lightweight on-chain data) and a Web2-level user experience (enriched off-chain data).


---

# 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.omnipact.io/developers/omnipact-technology-white-paper/readme/omni-id-reputation-and-identity-protocol/5.1-sbt-architecture.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.