Why Real World Contracts?

Real World Contracts (RWCs) are the core use case for the Integra protocol. This page explains the problem they solve, the vision behind them, and how Integra's approach differs from other projects in the space.

The Problem with Traditional Agreements

Every day, billions of dollars in value are governed by agreements that exist as static files -- PDFs in email threads, Word documents on shared drives, paper copies in filing cabinets. These agreements share a set of fundamental limitations:

No Provable Integrity

Once a contract is signed, there is no standard way to prove the document has not been altered. You rely on trust in the custodian, the storage system, or the notary. If two parties have different versions of the same agreement, resolving which one is authoritative requires lawyers, courts, and time.

No Programmable Execution

Traditional contracts describe obligations in natural language. Enforcing those obligations -- payments, deadlines, conditions -- requires manual action, intermediaries, or litigation. There is no mechanism for the agreement itself to trigger downstream actions.

No Transferable Ownership

Transferring rights in a real-world agreement (selling a property deed, assigning a license, transferring an invoice) typically requires intermediaries: title companies, escrow agents, legal counsel. The process is slow, expensive, and opaque.

Fragmented Systems

Every organization maintains its own database, format, and process. A property deed exists in a county recorder's office; the mortgage exists at a bank; the insurance policy exists at a carrier. Nothing is interoperable. Integration between these systems is expensive custom work, if it exists at all.

No Composability

In DeFi, tokens can be composed -- collateralized, wrapped, pooled, streamed. Real-world agreements cannot participate in any of this. A signed lease, a supply chain invoice, or a license grant is locked in its original format with no way to interact with on-chain infrastructure.

What Real World Contracts Enable

An RWC takes a traditional agreement and gives it on-chain identity. This unlocks capabilities that static documents cannot provide:

Existence proof. The content hash of the agreement is registered on-chain, creating an immutable, timestamped record that the document existed in a specific form at a specific time. This is done through IntegraExistenceV1 -- a minimal, write-once contract with no admin functions.

Verifiable ownership. IntegraRecordV1 binds the content hash to an owner address. Ownership can be transferred, and transfer history is recorded on-chain. No intermediaries required.

Tokenized rights. The record can be associated with any of Integra's 23 tokenizer contracts. This means an agreement can be represented as an ERC-721 (single owner), ERC-1155 (multi-party), or ERC-20 (fractional shares). Tokens are standard -- they work in wallets, marketplaces, and DeFi protocols.

Attestation-gated access. Parties to the agreement receive capability attestations through EAS. These attestations define exactly what each party can do -- view, sign, transfer, amend -- using a 256-bit capability bitmask. Permissions are granular, cryptographically signed, and revocable.

Programmable resolution. Resolvers attach on-chain logic to records: compliance gating before transfers, dispute resolution workflows, automated condition evaluation. The agreement becomes active rather than static.

Gasless operation. Through ERC-2771 meta-transactions, end users can interact with their agreements without holding ETH. Relayers pay gas; users sign typed data off-chain.

Use Cases

Property and Real Estate

Register deeds, leases, and mortgage documents as on-chain records. Tokenize ownership for instant, verifiable transfer. Attach compliance resolvers that gate transfers behind KYC verification. Use fractional tokenization (ERC-20) to enable shared ownership of commercial properties.

Financial Instruments

Invoices, promissory notes, and debt agreements become tokenized instruments. An InvoiceTokenizerV1 token can be transferred to a factor. A DebtTokenizerV1 token represents a debt obligation with on-chain provenance. Payment signals (IntegraSignalV1) enable encrypted payment requests between token holders.

Intellectual Property

Register patents, trademarks, and creative works with content hash existence proofs. License grants become LicenseTokenizerV1 tokens -- soulbound (non-transferable) by design. Royalty distribution happens through RoyaltyTokenizerV1 (ERC-1155).

Supply Chain

Register bills of lading, certificates of origin, and quality certifications. SupplyChainTokenizerV1 tokens track provenance through the chain of custody. Each transfer is recorded on-chain with full history.

Identity and Credentials

Credentials, certifications, and membership records become soulbound tokens (SoulboundTokenizerV1, MembershipTokenizerV1). These are non-transferable, bound to the recipient, and instantly verifiable by any party. No phone calls to registrars, no waiting for transcripts.

Multi-Party Agreements

Contracts with multiple signers use MultiPartyTokenizerV1 (ERC-1155) to represent each party's participation. Governance decisions about the agreement use GovernanceTokenizerV1 (ERC-20) for voting. Dispute resolution is handled by ADRResolverV3, which implements a full arbitration lifecycle on-chain.

How Integra Differs

Separation of Existence and Records

Most document-blockchain projects conflate "registering a hash" with "managing a record." Integra separates these concerns into two distinct contracts:

• IntegraExistenceV1 (Layer 1) is permissionless and minimal. Anyone can register any content hash. No ownership, no access control, no fees. It does one thing: prove that a hash was registered at a specific time.
• IntegraRecordV1 (Layer 4) adds ownership, metadata, tokenizer binding, resolver attachment, and executor authorization. It references IntegraExistenceV1 but is a separate contract with separate deployment.

This separation means existence proofs are permanent and independent of any business logic. Even if the entire upper protocol were abandoned, the existence layer would continue to function.

Immutable Contracts, No Proxies

Every Integra contract is deployed once and cannot be upgraded. There are no proxy patterns, no DELEGATECALL forwarding, and no admin functions that can swap implementation addresses. All inter-contract references are immutable Solidity variables set at construction time.

This is a deliberate tradeoff: upgrading a referenced contract requires deploying a new version of the referencing contract. But it eliminates an entire class of attacks where an admin key is used to redirect a contract to a malicious implementation.

Progressive Ossification

Governance evolves through four one-way stages: BOOTSTRAP, MULTISIG, DAO, OSSIFIED. Each transition is irreversible and moves control further from any single party. The final stage freezes the governance model permanently while preserving operational flexibility.

Capability-Based Access, Not Role-Based

Instead of coarse-grained roles (admin, user, viewer), Integra uses a 256-bit capability bitmask verified through EAS attestations. A party can be granted exactly CORE_VIEW | DOC_SIGN without any other permissions. Capabilities are composable, delegatable, and cryptographically verifiable.

General-Purpose Record Identity

Integra is not limited to legal contracts. Any file, artifact, or data payload that can be hashed to bytes32 can be registered. "Records" rather than "documents" reflects this generality -- the protocol works for agreements, credentials, certificates, media files, datasets, or any other content that needs verifiable on-chain identity.

Next Steps

• Architecture -- How the 11-layer system is structured
• What is Integra? -- Protocol overview and key concepts