Record-Token Binding

How Integra permanently binds ERC tokens to cryptographically verifiable on-chain records, creating Real World Contracts.

Overview

Integra's Record-Token Binding is a two-layer architecture that connects ERC token standards (ERC-20, ERC-721, ERC-1155) to real-world records through a permanent on-chain registry. This creates tokens that represent verifiable ownership of physical or digital assets --- what we call Real World Contracts (RWC).

The Problem with Traditional Tokenization

Traditional NFT/Token Approach

Token Contract
  - tokenId: 1 -> metadata URI -> JSON
  - tokenId: 2 -> metadata URI -> JSON
  - tokenId: 3 -> metadata URI -> JSON

Limitations:

No connection to real-world content
Metadata can change or disappear
No standardized content identity
No way to attach services (resolvers) to tokens
Each token contract is isolated

Integra's Record-Bound Approach

IntegraExistenceV1 (Immutable Hash Layer)
  - contentHash: 0xdef... -> timestamp, registrant
  Write-once proof that specific content existed at a specific time

IntegraRecordV1 (Record Identity Layer)
  - integraHash: 0xabc... -> RecordInfo
       - contentHash (content proof)
       - owner
       - tokenizer -> OwnershipTokenizerV1
       - resolvers (contact, lifecycle, etc.)

  Tokenizer Contract (ERC Standard Layer)
       - tokenId: 1 -> bound to integraHash: 0xabc...

Benefits:

Token permanently linked to record identity
Content cannot be changed (immutable hash)
Services attach to the record, not the token
Standard ERC interfaces work everywhere
Multiple tokenizers can reference the same records

How It Works

Step 1: Content Hash Registration (IntegraExistenceV1)

The first layer is a write-once, permissionless hash registry:

// Anyone can register a content hash
integraExistenceV1.registerHash(
    keccak256(documentContent)  // contentHash - proves content exists
);

This creates an immutable, timestamped proof that specific content existed. No ownership, no metadata --- just existence.

Step 2: Record Registration (IntegraRecordV1)

The second layer creates the full record identity with ownership and tokenizer bindings:

bytes32 integraHash = integraRecordV1.registerRecord(
    keccak256(documentContent),  // contentHash - proves content
    ipfsCID,                     // referenceHash - where to find content
    address(ownershipTokenizerV1), // which tokenizer will create tokens
    address(0),                  // optional executor
    bytes32(0),                  // processHash
    bytes32(0),                  // identityExtension
    bytes32(0),                  // primaryResolverId
    new bytes32[](0)             // additionalResolvers
);

What happens:

System generates unique integraHash = keccak256(contentHash + referenceHash + owner + timestamp)
Stores immutable record: owner, content proof, tokenizer address
Returns integraHash as permanent record identifier

This creates a permanent record identity that:

Can never be changed
Proves the content (via hash)
Links to a specific tokenizer
Can have services attached (resolvers)

Step 3: Token Creation (Bound to Record)

Now the tokenizer creates ERC tokens bound to the integraHash:

// Owner reserves token for recipient
ownershipTokenizerV1.reserveToken(
    integraHash,      // Links token to record
    0,                // tokenId (auto-assigned)
    recipientAddress,
    1,                // amount
    processHash
);

// Recipient claims with capability attestation
ownershipTokenizerV1.claimToken(
    integraHash,              // Token bound to this record
    tokenId,
    capabilityAttestationUID,
    processHash
);

What happens:

Tokenizer validates integraHash exists in registry
Tokenizer validates caller is record owner (from registry)
ERC-721 token minted with internal integraHash binding
Token now represents ownership of the real-world record

Step 4: The Binding Lives Forever

The token-record binding is permanent:

// Anyone can verify what record a token represents
bytes32 recordHash = tokenizer.getContentHash(tokenId);
// Returns the integraHash this token is bound to

// And what tokenizer a record uses
address tokenizerAddr = integraRecordV1.getTokenizer(integraHash);
// Returns which tokenizer contract manages this record's tokens

The Architecture

Two-Layer System

Layer 1: Content Existence (IntegraExistenceV1)

IntegraExistenceV1
  - Write-once, permissionless
  - contentHash -> timestamp, registrant
  - Minimal and immutable
  - Proves content existed at a point in time
  - NEVER changes after creation

Layer 4: Record Identity (IntegraRecordV1)

IntegraRecordV1
  - integraHash -> RecordInfo
  - Content hash (content proof)
  - Owner address
  - Tokenizer address (which contract creates tokens)
  - Resolver references (services)
  - Executor authorization

Token Standard Layer (ERC-Compliant)

Tokenizer Contract (e.g., OwnershipTokenizerV1)
  - Implements ERC-721/1155/20
  - Creates tokens bound to integraHash
  - All tokens reference back to record registry
  - Tokens work with any ERC-compatible system

The Binding Mechanism

Each tokenizer stores the integraHash for every token:

// Inside OwnershipTokenizerV1 (ERC-721)
struct TokenData {
    bytes32 integraHash;  // Record binding
    address owner;
    bool minted;
    // ... other token data
}

mapping(uint256 => TokenData) private tokenData;
mapping(bytes32 => uint256) public integraHashToTokenId;

This creates bidirectional references:

Token -> Record: tokenData[tokenId].integraHash
Record -> Token: integraHashToTokenId[integraHash]

Why This Matters

1. Verifiable Real-World Ownership

Traditional NFT:

"This token represents a house"

How do you verify? You cannot.

Integra RWC:

Token #123 -> integraHash 0xabc...
  -> contentHash: 0xdef... (SHA-256 of deed)
  -> owner: 0x789...
  -> registered: 2025-01-15

Anyone can verify the content hash matches the real deed.

2. Tokens Work Everywhere (Standard ERCs)

Because tokenizers implement standard ERCs:

Works in MetaMask, Ledger, any wallet
Can trade on any marketplace
Composable with DeFi (collateral, lending)
Standard transfer/approval mechanisms

But also connected to real records:

Proves what the token represents
Links to record services (contact info, lifecycle)
Immutable record identity

3. Services Attach to Records, Not Tokens

Traditional approach:

Each tokenizer must implement resolvers,
contact storage, lifecycle management, etc.

Integra approach:

IntegraRecordV1
  - integraHash -> resolvers
       - Lifecycle Resolver (expiry, renewal)
       - Custom Resolver (your logic)

Any tokenizer for this record can access these services

4. Multiple Tokenization Strategies

Because record identity is separate from tokenization:

// Register record once
bytes32 integraHash = integraRecordV1.registerRecord(..., tokenizerA);

// Later, can change tokenization strategy
integraRecordV1.setTokenizer(integraHash, tokenizerB);

Example: Start with single-owner token (ERC-721), later fractionalize into shares (ERC-20).

5. Cross-Chain Record Identity

The integraHash can be replicated cross-chain:

Polygon:   integraHash 0xabc... -> OwnershipTokenizerV1 (ERC-721)
Ethereum:  integraHash 0xabc... -> SharesTokenizerV1 (ERC-20)
Base:      integraHash 0xabc... -> MultiPartyTokenizerV1 (ERC-1155)

Same record, different tokenization per chain.

Real-World Example: Property Deed

Step-by-Step Flow

1. Property owner registers deed:

bytes32 deedHash = keccak256(physicalDeedPDF);
bytes32 ipfsCID = "Qm..."; // Uploaded to IPFS

bytes32 integraHash = integraRecordV1.registerRecord(
    deedHash,                         // Proves deed content
    ipfsCID,                         // Where to find full deed
    address(ownershipTokenizerV1),   // Use ERC-721 NFT
    address(0),
    bytes32(0),
    bytes32(0),
    bytes32(0),                      // primaryResolverId
    new bytes32[](0)
);

Registry stores:

integraHash: 0xabc123...
contentHash: 0xdef456... (deed SHA-256)
owner: 0x789... (property owner)
tokenizer: OwnershipTokenizerV1

2. Owner creates NFT for buyer:

// Reserve deed NFT for buyer
ownershipTokenizerV1.reserveToken(
    integraHash,     // Links NFT to deed
    0,               // Auto-assign tokenId
    buyerAddress,
    1,
    saleProcessHash
);

// Create claim attestation (via TokenClaimResolver)
bytes32 attestationUID = createClaimAttestation(
    integraHash,
    tokenId,
    buyerAddress
);

3. Buyer claims deed NFT:

ownershipTokenizerV1.claimToken(
    integraHash,        // Claims token for this deed
    tokenId,
    attestationUID,
    saleProcessHash
);

Result:

Buyer now owns ERC-721 token
Token permanently bound to deed integraHash
Anyone can verify: token -> deed hash -> actual deed
Token works in any ERC-721 wallet/marketplace
Deed ownership on-chain, verifiable, transferable

Verification by Third Party

Anyone can verify the token represents the real deed:

// 1. Get integraHash from token
bytes32 integraHash = ownershipTokenizerV1.getContentHash(tokenId);

// 2. Look up record in registry
(address owner, bytes32 contentHash, , , ) =
    integraRecordV1.getRecordInfo(integraHash);

// 3. Compare contentHash with actual deed
bytes32 actualDeedHash = keccak256(physicalDeedPDF);
require(contentHash == actualDeedHash, "Deed does not match!");

// 4. Verified: This token definitely represents this deed

Comparison with Other Approaches

Approach 1: Metadata-Only NFTs (OpenSea standard)

Token -> tokenURI -> { "name": "My House", "description": "..." }

Problems:

No proof of content authenticity
Metadata can change
No services (resolvers)
No real-world content link

Approach 2: Content Hash in NFT

Token -> metadata includes contentHash

Better, but:

Each tokenizer reinvents the wheel
No standardized record identity
No resolver services
Cannot change tokenization strategy

Approach 3: Integra Record-Token Binding

IntegraExistenceV1 (contentHash) + IntegraRecordV1 (integraHash) <-> Tokenizer (ERC tokens)

Advantages:

Permanent record identity
Cryptographic content proof
Standard ERC tokens (universal compatibility)
Resolver services
Flexible tokenization
Cross-chain support

Technical Benefits

For Smart Contract Developers

1. Reusable Record Identity

// Use integraHash across multiple contracts
contract MyContract {
    function processRecord(bytes32 integraHash) external {
        // Verify record exists
        require(integraRecordV1.exists(integraHash));

        // Get record owner
        address owner = integraRecordV1.getRecordOwner(integraHash);

        // Get tokenizer
        address tokenizer = integraRecordV1.getTokenizer(integraHash);

        // Your custom logic...
    }
}

2. Composability with DeFi

// Use as collateral (because it is standard ERC-721)
lendingProtocol.depositCollateral(tokenId);

// But backed by real content
bytes32 integraHash = tokenizer.getContentHash(tokenId);
bytes32 contentHash = integraRecordV1.getContentHash(integraHash);
// Can verify collateral is real property deed

3. Service Discovery

// Get contact info for record holder
bytes32 integraHash = tokenizer.getContentHash(tokenId);
bytes32 resolverId = integraRecordV1.getPrimaryResolver(integraHash);
address resolver = integraRegistry.getComponent(resolverId);
bytes memory contactData = IRecordResolver(resolver).resolve(integraHash);

For Application Developers

1. Standard Wallet Integration

Tokens are standard ERC-721/1155/20
Work in MetaMask, WalletConnect, etc.
No custom wallet support needed

2. Marketplace Integration

List on any marketplace
Standard approval/transfer mechanisms
Can show real content verification

3. Content Verification

Query registry for content proof
Show "Verified Record" badge
Link to IPFS for full content

Advanced Patterns

Pattern 1: Multi-Tokenizer Records

One record, multiple tokenization strategies:

// Polygon: Single owner (ERC-721)
integraRecordV1.registerRecord(
    contentHash,
    ipfsCID,
    ownershipTokenizerV1,  // ERC-721
    ...
);

// Ethereum: Fractionalized (ERC-20)
// Use same contentHash + owner = same integraHash cross-chain
integraRecordV1.registerRecord(
    contentHash,         // Same hash
    ipfsCID,             // Same reference
    sharesTokenizerV1,   // ERC-20 for fractions
    ...
);

Pattern 2: Record Evolution

Start simple, evolve over time:

// Phase 1: Simple NFT ownership
registerRecord(..., ownershipTokenizerV1);

// Phase 2: Add rental capability
integraRecordV1.setTokenizer(integraHash, rentalTokenizerV1);

// Phase 3: Add royalty distribution
integraRecordV1.setTokenizer(integraHash, royaltyTokenizerV1);

Pattern 3: Service Composition

Add services to records without changing tokenizer:

// Start with basic record
registerRecord(..., basicTokenizer, NO_RESOLVER);

// Later: Add lifecycle resolver
integraRecordV1.setPrimaryResolver(integraHash, lifecycleResolverId);

// Later: Add payment automation
integraRecordV1.addAdditionalResolver(integraHash, paymentResolverId);

Security Considerations

Immutable Content Hash

Once registered, the contentHash can never change:

Permanent proof of content
Cannot be tampered with
Historical verification possible

Tokenizer Validation

Tokenizers must validate with registry:

// Inside tokenizer
function _validateRecord(bytes32 integraHash) internal view {
    require(integraRecordV1.exists(integraHash), "Record not found");
    require(
        integraRecordV1.getTokenizer(integraHash) == address(this),
        "Wrong tokenizer for record"
    );
}

Owner Controls

Record owner controls:

Who can claim tokens (via attestations)
Which resolver services are attached
Executor authorization
But CANNOT change the content hash

Summary

Integra's Record-Token Binding:

Separates record identity from tokenization across two contract layers
Links ERC tokens to permanent on-chain records
Enables standard wallet/marketplace compatibility
Provides verifiable proof of real-world asset ownership
Supports flexible tokenization strategies
Allows services to attach to records
Works cross-chain with consistent identity

This is what makes Integra's tokens Real World Contracts --- they are not just NFTs with metadata, they are cryptographically bound to verifiable real-world records with permanent on-chain identity.

Learn More

Record vs Token Ownership --- Dual ownership model
Reserve-Claim Pattern --- Token issuance for non-wallet users
Privacy-First Architecture --- Privacy considerations

Why Real World Contracts?

See It In Action

Try Without Code

Join the Community

On this page