Iraquin: A Verification First Settlement Layer 1 Blockchain

Motivation

To many people outside Web3, blockchains are still a foreign concept. They are often associated with cryptocurrencies, speculation, or digital assets. Yet beneath all of that sits one of the most remarkable distributed systems ever created.

At its simplest, a blockchain can be described as a distributed database secured by a set of rules that independent participants collectively agree upon. Of course, that description hardly does justice to what blockchains actually are. Like most elegant systems, their beauty is not found in a single sentence but in the countless design decisions, tradeoffs, and assumptions that make them work.

Over the past decade, thousands of blockchain networks have emerged. Some optimized for decentralization, some for throughput, some for programmability, and others for specific applications. No single architecture has proven to be the answer for every use case, nor should it be expected to.

What fascinated me most was not what blockchains had become, but the assumptions they all seemed to share.

One of those assumptions is that computation and verification should happen as part of the same tightly coupled process. Transactions are executed, verified, and finalized together. This was a reasonable design choice when blockchains primarily dealt with token transfers and relatively simple smart contract execution. It kept systems understandable, secure, and predictable.

The world ahead, however, looks very different.

Modern decentralized systems increasingly depend on heterogeneous forms of computation: zero-knowledge proofs, trusted execution environments, AI inference, machine learning workloads, external simulations, and verifiable off-chain execution. These workloads differ dramatically in complexity, verification cost, proof size, and latency.

As these systems evolve, an uncomfortable question begins to emerge:

Must the progress of an entire network remain bound to the speed of its slowest verification task?

For many years, the answer has effectively been yes. This constraint simplified system design and strengthened security guarantees. But simplicity is not a law of nature. It is merely a design choice, and every design choice eventually reaches its limits.

The motivation behind Iraquin is not to make blockchains faster for the sake of speed, nor to replace existing networks that have proven enormously successful. It begins with a simpler belief:

The next generation of decentralized systems will be defined less by how they execute computation and more by how they verify it.

Core Insight

Most blockchain systems follow a familiar pipeline of ordering, execution, verification, and finality. A state transition is not considered final until the entire process completes. This creates a synchronization point where unrelated transactions inherit the latency of the most expensive verification workload.

An intuitive way to think about this is a water pipeline feeding an apartment. One resident may only need a cup of water while another may need a bucket. The time required to satisfy both requests is fundamentally different, yet they share the same supply infrastructure. Modern blockchains face a similar challenge. A simple token transfer, a TEE attestation, and a large zero-knowledge proof may differ dramatically in verification cost, but they are often forced through a common path toward finality.

The question is not whether verification is necessary. Verification remains the foundation of correctness. The question is whether every transaction must wait for every other transaction to reach correctness before progressing toward finality.

System Model

Before diving into Prime, Omega, and the mechanics of settlement, This section helps to understand the world Iraquin operates in.

Traditional blockchains view transactions as a sequence of events. A transaction happens, state changes, and the network moves forward. Once finalized, the chain rarely needs to look back.

Iraquin approaches the problem differently.

In a verification-first system, settlement and correctness do not always arrive at the same moment. A transaction may influence the future state while parts of its verification journey are still unfolding. This means the protocol cannot simply remember what happened, it must also remember how later state came to depend on earlier state.

To accomplish this, Iraquin maintains an explicit dependency graph. Transactions, proofs, certifications, and corrections are connected through relationships that allow the network to reason about correctness over time. Rather than viewing state as a collection of isolated updates, the protocol treats state transitions as part of a continuously evolving graph.

The following sections introduce the participants that maintain the network and the objects through which the protocol operates.

Actors

Users

Users are the source of activity within the network. They submit transactions, proofs, and externally computed outcomes that they wish to settle on-chain.

Ingress

Ingress nodes act as the entry point to the network. They receive transactions, perform preliminary validation, and ensure workloads are distributed efficiently across protocol participants.

Verifier

Verifiers are responsible for examining proofs, validating computations, and advancing transactions towards block production.

Collider

Colliders are responsible for state verification, establish canonical transaction ordering and produce optimistic blocks that allow settlement to progress without waiting for full network-wide verification.

Validator

Validators participate in consensus, certification decisions, and the broader security of the network.

Recovery Validator

Not every verification task completes as expected. Recovery validators provide a fallback mechanism that helps ensure stalled or incomplete verification workloads continue progressing toward resolution.

Protocol Objects

The actors described above interact through a small set of protocol objects. Together, these objects form the language through which the network expresses settlement, verification, certification, and correction.

Transaction

A transaction represents a request to change the state of the network. Whether transferring value, settling a computation, or committing the result of an external system, every meaningful action in Iraquin begins as a transaction.

Proof

A proof is the evidence accompanying a transaction. It allows the network to independently verify that a computation, execution, or claim was performed correctly without having to blindly trust the party that submitted it.

Dependency

Transactions rarely exist in isolation. A dependency represents a relationship where one transaction relies upon the validity of another. These relationships allow the protocol to understand how correctness propagates through state over time.

Block

Blocks provide canonical ordering. They group settled transactions into a shared history that can be independently reproduced and verified by every participant in the network.

Correction

Not every settled transaction ultimately proves to be valid. A correction is a protocol artifact that records invalidity and propagates its effects through dependent state while preserving forward progress of the network.

Certificate

A certificate represents the protocol's acknowledgement that a transaction, block, or collection of state transitions has successfully completed the certification process and can be considered finalized.

Transaction Lifecycle

A transaction has to go through multiple steps throughout the protocol, where every step is a filter to settle the transaction. A transaction will reach the settled state when it's added to a block and when it reaches the state of certified is where it is finalized.

The components introduced in this section establish the entities and protocol objects that compose the Iraquin network. Subsequent sections describe how state is represented, how dependencies are tracked, and how settlement progresses toward certification and finality.

State & Dependency Model

Traditional blockchains primarily care about the current state of the network. Once a transaction is finalized, the chain rarely needs to remember how later the state became dependent upon it. Iraquin introduces a different requirement. Because certification may occur after settlement, the protocol must understand not only what state exists, but also how that state came into existence. To achieve this, Iraquin maintains a dependency-aware state model.

For simplicity, the state can be understood through four primary layers: Accounts, Transactions, Dependencies, and Certifications. Additional protocol records such as validator assignments, data availability commitments, correction records, and protocol parameters are introduced in later sections.

Accounts

Accounts represent ownership and participation within the network. In addition to balances, accounts maintain protocol-specific information such as staking commitments, reputation, role assignments, permissions, and other metadata required for network operation. Together, these attributes determine how an account interacts with settlement, verification, and governance processes.

Transaction

Transactions are the mechanism through which state evolves. Every transfer, proof submission, protocol action, or settlement request enters the network as a transaction. A transaction records the intent of the sender, the state it wishes to modify, the accounts it affects, and the proof artifacts required for verification.

Unlike traditional blockchain transactions that focus solely on execution, Iraquin transactions also carry the information necessary for dependency tracking and certification. This allows the protocol to understand not only what state changes occurred, but also how those changes influence future state transitions.

Dependencies

Transactions rarely exist in isolation. A transfer may fund another transaction, a proof may establish state consumed by future applications, and a settled outcome may become the foundation for an entire chain of subsequent activity.

To understand these relationships, Iraquin maintains a dependency graph. Every transaction is connected to the state it consumes and the state it produces, allowing the protocol to understand how correctness propagates throughout the network.

For example Transactions T2, T3, and T4 are derived from state produced by T1 and therefore depend upon its validity. Transactions T5 and T6 form an independent branch and may continue progressing toward certification regardless of the state of T1.

Beyond tracking relationships, dependencies play a central role in certification. Transactions are not certified independently; they are certified in a manner that respects the dependency structure of the network. This ensures that state derived from unresolved transactions does not incorrectly advance toward finality.

The protocol also maintains a dependency depth for each transaction. This depth provides visibility into how far uncertified state has propagated through the network and serves as an important measure of protocol health. By monitoring dependency depth, the network can detect stalled verification workloads, limit uncertified exposure, and prevent state from progressing beyond acceptable certification boundaries.

Together, the dependency graph and dependency depth provide the foundation for asynchronous certification while preserving deterministic correctness.

Certification

Settlement determines ordering, but certification determines permanence.

A settled transaction may influence future state while portions of its verification journey are still underway. Certification is the process through which the network continuously establishes correctness until a transaction can be considered part of the immutable history of the chain.

Unlike traditional blockchains that often derive finality at the block level, Iraquin approaches certification at the transaction level. Transactions are certified according to their dependency relationships rather than the boundaries of the block in which they were settled. This allows independent portions of the network to progress toward finality without waiting for unrelated verification workloads.

To support this model, the protocol maintains a dependency graph that captures how state propagates through the network. Certification progresses through this graph, allowing independent branches to advance concurrently while ensuring that the dependent state respects correctness boundaries.

The result is a dependency-aware certification model where finality emerges continuously rather than as a single block-wide event. In addition to improving certification throughput, the dependency graph provides valuable insight into network health, certification progress, and verification bottlenecks.

Prime Protocol — Deterministic Settlement

Before a transaction can become permanent, it must first enter the network, be ordered, and become part of the shared history observed by every participant.

This responsibility belongs to Prime.

Prime is the settlement engine of Iraquin. Its job is not to determine whether every transaction is ultimately correct. Instead, Prime focuses on progressing the network forward by admitting transactions, establishing canonical ordering, and producing optimistic blocks.

By separating settlement from certification, Prime allows the network to continue operating even when verification workloads vary dramatically in complexity. A simple transfer and a large proof-based computation can therefore coexist without forcing the entire network to wait for the slowest verification task.

The result is a system where settlement progresses rapidly while correctness is established independently through Omega.

A transaction entering Prime follows four stages:

Transaction Ingress

Think airport security.

Ingress is simply the entry point into the network.

Transactions arrive, basic structural checks are performed, and valid requests are propagated toward the verifier pipeline.

Ingress nodes do not execute transactions, validate state, or participate in certification.

Verifier Pipeline

Verifiers act as the cryptographic gatekeepers of Prime.

Before a transaction can consume settlement resources, verifiers ensure that signatures, proof references, metadata, and protocol constraints are valid.

Successful verification produces an admission receipt that allows the transaction to continue through the settlement pipeline.

Verification at this stage establishes admissibility, not correctness.

Collider Settlement

Colliders are responsible for producing the shared transaction history of the network.

After receiving verified transactions, colliders perform state validation, establish deterministic ordering, and assemble optimistic blocks.

The resulting blocks become part of the canonical settlement history maintained by Prime.

Non-Blocking Progression

One of Prime's core design goals is to prevent verification latency from slowing network progression.

Proof publication, proof retrieval, verification, and settlement occur concurrently rather than sequentially.

As a result, Prime continues producing blocks without waiting for every verification workload to complete.

Relationship with Omega

Prime answers the question: What happened?

Omega answers the question: Was it correct?

Prime focuses on ordering and settlement.

Omega focuses on certification and finality.

Together they allow Iraquin to separate progression from correctness while preserving deterministic behavior.

Omega Protocol — Correctness, Certification and Forward Correction

If Prime is responsible for moving the network forward, Omega is responsible for ensuring that it moved forward correctly.

Traditional blockchains tightly couple settlement and verification. Before state can progress, the network must collectively verify that the proposed state transition is valid. While this approach provides strong correctness guarantees, it also forces simple transactions and computationally expensive workloads to share the same path toward finality.

Iraquin separates these responsibilities.

Prime establishes canonical ordering and optimistic settlement. Omega continuously follows behind, auditing optimistic settlement history and determining whether the resulting state transitions satisfy the protocol's correctness requirements.

An intuitive way to think about Omega is as an independent audit layer operating over the blockchain. Prime records what happened. Omega verifies whether what happened was correct.

Unlike traditional execution-replication systems, Omega does not attempt to reproduce every step of execution performed during settlement. Instead, Omega focuses on outcomes. Validators verify whether the resulting state transition can be justified by valid proofs, valid protocol rules, and valid dependency relationships. In other words, Omega verifies correctness of effects rather than correctness of execution procedure.

Verification occurs continuously and asynchronously. While Prime continues producing optimistic settlement blocks, Omega retrieves proof artifacts, analyzes dependencies, validates state transitions, and advances transactions toward certification. Settlement progression and correctness verification therefore overlap continuously rather than blocking one another.

To support this process, Omega maintains and analyzes the dependency graph introduced earlier in the protocol. Dependencies allow Omega to understand how state propagates throughout the network and determine which transactions are affected when invalidity is discovered. Rather than treating invalidity as a block-level problem, Omega treats invalidity as the propagation of incorrect state through a dependency graph.

Because certification operates independently from settlement, transactions may temporarily exist in a state of bounded uncertainty. During this period, proof verification may still be underway, dependency analysis may still be incomplete, and correction operations may still be generated. Once a transaction exits its verification window without unresolved invalidity, it becomes eligible for economic finality.

Importantly, bounded uncertainty does not imply probabilistic fork choice or speculative rollback. Canonical ordering remains deterministic throughout the verification process. Omega never competes between alternative histories and never attempts to replace previously settled blocks.

When Omega discovers an invalid state transition, it constructs a correction artifact describing the invalid transaction, the affected dependency descendants, and the correction actions required to restore protocol correctness. Omega itself does not modify canonical state. Instead, correction artifacts are submitted back into Prime, where colliders apply deterministic correction operations through normal settlement.

This design introduces one of the fundamental properties of Iraquin: forward correction.

Traditional systems often recover from invalid execution through rollback or chain reorganization. Iraquin takes a different approach. Invalid state remains visible within the ledger, while correction occurs through explicit forward state transitions that neutralize the effects of invalid execution. History is never rewritten. Instead, correctness is restored through auditable correction records that preserve the continuity of the ledger.

Because corrections operate over explicit dependency relationships, invalidity remains localized and computationally bounded. The protocol therefore avoids global state rewinds while maintaining deterministic correctness guarantees.

Once verification completes and no unresolved invalidity remains, Omega produces certification records establishing that the corresponding transactions have satisfied the protocol's correctness requirements. Certified transactions become part of the irreversible economic history of the network and advance beyond the certification frontier.

Together, asynchronous verification, dependency-aware certification, and deterministic forward correction allow Omega to provide correctness and finality without preventing Prime from sustaining rapid settlement progression.

Economics and Incentives

A decentralized system survives only when the incentives of its participants are aligned with the health of the network. Iraquin introduces multiple specialized roles, each responsible for a distinct function within settlement, verification, certification, and correctness enforcement. The economic model ensures that participants are rewarded for contributing useful work and penalized when their actions threaten the correctness or liveness of the protocol.

Unlike traditional blockchains where a single validator often performs ordering, execution, and verification simultaneously, Iraquin distributes these responsibilities across specialized participants. As a result, incentives must be aligned not only around block production, but around the entire lifecycle of settlement and certification.

The economic design of Iraquin is guided by four principles:

Transaction Fees

Every transaction submitted to the network pays a protocol fee. These fees compensate the participants responsible for admitting, verifying, ordering, certifying, and maintaining the transaction throughout its lifecycle.

Because verification costs may vary significantly between workloads, transaction fees are composed of multiple components rather than a single uniform charge.

Typical fee components may include:

This structure allows lightweight transactions and computationally expensive proof systems to coexist while paying proportionally for the resources they consume.

Role-Based Rewards

Iraquin rewards participants according to the work they perform.

Ingress nodes receive compensation for transaction admission and propagation.

Verifiers receive compensation for validating proof artifacts, transaction metadata, and protocol constraints.

Colliders receive compensation for producing optimistic settlement blocks and maintaining deterministic ordering.

Validators receive compensation for advancing the certification frontier and verifying correctness.

Recovery validators receive compensation when assuming responsibility for stalled or unavailable verification workloads.

By aligning rewards with protocol responsibilities, the network creates economic incentives for participants to contribute resources where they are most needed.

Staking and Security

Participants responsible for settlement and certification must maintain economic stake within the protocol.

Stake serves as a security deposit that aligns participant incentives with network correctness. By placing value at risk, participants are economically discouraged from producing invalid settlement results, approving malformed verification artifacts, or interfering with certification progression.

The amount of stake required may vary according to protocol role, workload responsibility, and network governance parameters.

Slashing and Accountability

Rewards alone are insufficient to secure a decentralized system. Participants must also face consequences when protocol rules are violated.

Iraquin therefore incorporates economic accountability through slashing and participation penalties.

Examples of slashable behavior may include:

Importantly, correctness restoration and fault attribution remain separate processes. Omega first restores correctness through deterministic correction. Responsibility and penalties are determined afterward.

This ensures that disputes regarding blame never delay correction or certification.

Sustainable Verification Markets

One of the central challenges facing modern decentralized systems is the increasing diversity of verification workloads.

A simple token transfer, a zero-knowledge proof, a TEE attestation, and a large external computation may impose dramatically different verification costs on the network.

Iraquin embraces this diversity by treating verification as a first-class economic activity rather than a secondary byproduct of block production.

As proof systems evolve and computational workloads become increasingly sophisticated, the protocol's economic model allows verification capacity to scale alongside demand.

In this way, Iraquin establishes not only a settlement network, but also a market for correctness itself.

Security Model

Every decentralized system operates under a set of assumptions regarding participant behavior, network conditions, data availability, and cryptographic correctness. The purpose of the security model is not to eliminate all failures, but to clearly define the conditions under which the protocol maintains safety, liveness, and correctness.

Iraquin separates settlement and correctness certification into two independent protocol layers. As a result, the security model is likewise divided between the guarantees provided by Prime and the guarantees provided by Omega.

Prime is responsible for deterministic ordering and optimistic settlement. Omega is responsible for correctness certification, invalidity detection, and forward correction. Together they provide a system capable of progressing under bounded uncertainty while preserving deterministic correctness.

Settlement Safety

Prime establishes a single canonical ordering of transactions and maintains a deterministic settlement history.

Once a transaction has been settled, its position within the canonical ledger does not change. The protocol does not rely on speculative forks, probabilistic settlement replacement, or chain reorganization to recover from invalid execution.

As a result, settlement history remains stable and auditable even while correctness certification is still underway.

Certification Safety

Omega continuously verifies optimistic settlement outputs and advances transactions toward certification.

A transaction is considered certified only after its verification requirements have completed and no unresolved invalidity remains within its dependency chain.

Certification therefore represents the protocol's acknowledgement that correctness has been established for the corresponding state transition.

Certified state is considered economically final and no longer subject to correction.

Forward Correction Safety

Iraquin resolves invalidity through deterministic forward correction rather than rollback.

When invalid state effects are discovered, Omega constructs correction artifacts identifying the affected transaction set and the required correction operations. These corrections are applied through normal settlement rather than through history replacement.

This guarantees that invalid execution remains permanently observable and auditable while preserving append-only ledger continuity.

Dependency Safety

The dependency graph provides the foundation for bounded correction.

Rather than treating invalidity as a block-level event, the protocol traces how invalid state propagates through dependent transactions. Corrections are therefore applied only to affected dependency branches rather than to unrelated portions of the ledger.

This allows correctness restoration to remain localized, deterministic, and computationally bounded even when verification is delayed.

Data Availability Assumptions

Iraquin assumes that proof artifacts, verification receipts, certification records, and settlement metadata remain available through the configured data availability layer.

Transactions whose required verification artifacts cannot be retrieved cannot progress toward certification.

The availability of verification data is therefore a prerequisite for correctness certification and finality.

Cryptographic Assumptions

The protocol assumes the security of the underlying cryptographic primitives used for signatures, proof verification, hashing, and validator authentication.

Any compromise of these primitives may undermine the protocol's ability to establish correctness, attribute responsibility, or enforce economic accountability.

Like all modern blockchain systems, Iraquin ultimately inherits the security properties of the cryptographic mechanisms upon which it is built.

Liveness Assumptions

Iraquin is designed to continue progressing despite validator failures, network delays, temporary partitions, and verification workload variability.

Prime may continue producing optimistic settlement blocks while Omega independently advances certification.

Recovery validators may assume responsibility for stalled verification workloads when required.

Under normal network conditions and honest majority assumptions, both settlement progression and certification progression continue advancing over time.

Security Guarantees

Subject to the assumptions described above, Iraquin provides the following guarantees:

These guarantees collectively allow Iraquin to separate progression from correctness while maintaining safety, transparency, and deterministic behavior.

Applications and Future Directions

Iraquin is not designed around a specific virtual machine, proof system, execution environment, or application category. Instead, the protocol provides a general framework for settling and certifying externally executed computation.

By separating settlement from correctness verification, Iraquin enables workloads with dramatically different verification characteristics to coexist within the same network. Lightweight transactions, cryptographic proofs, trusted execution environments, AI workloads, and external computational systems may therefore participate in a common settlement and certification framework without forcing a single verification path upon all participants.

While the architecture is broadly applicable, several categories of applications naturally benefit from verification-first settlement.

Verifiable Computation

Modern applications increasingly perform computation outside the blockchain and later produce evidence of correctness.

Examples include:

These systems often produce outputs whose verification cost differs substantially from the cost of execution itself.

Iraquin provides a common framework through which externally executed computation can be settled immediately and certified independently through asynchronous verification.

Artificial Intelligence

Artificial intelligence systems increasingly influence economic, scientific, and operational decision making.

As AI-generated outputs become integrated into critical workflows, questions regarding provenance, correctness, reproducibility, and accountability become increasingly important.

Iraquin provides a framework in which AI outputs may be accompanied by cryptographic evidence, verification artifacts, or trusted execution attestations and subsequently progress toward certification through the protocol's verification pipeline.

While the protocol does not attempt to determine whether an AI decision is correct in a semantic sense, it can establish whether the claimed computational process was executed according to the provided evidence.

Trusted Execution Environments

Trusted execution environments provide strong guarantees regarding execution integrity but often rely upon trust assumptions that exist outside the blockchain itself.

Iraquin enables TEE attestations to participate directly in settlement and certification workflows. Attestation verification, dependency tracking, and correctness certification may therefore occur within a unified protocol framework while preserving the operational advantages of trusted hardware.

Cross-System Settlement

Modern applications frequently span multiple independent systems, organizations, and computational environments.

A transaction may depend upon state generated elsewhere, proofs produced by external systems, or computations executed beyond the blockchain itself.

By treating verification as a first-class protocol responsibility, Iraquin provides a mechanism through which heterogeneous systems can contribute state transitions while maintaining a common path toward certification and finality.

Future Directions

The long-term vision of Iraquin extends beyond financial transactions and traditional blockchain applications.

As computation becomes increasingly distributed across proof systems, specialized hardware, artificial intelligence systems, and external execution environments, the challenge shifts from executing computation to establishing confidence in its results.

Iraquin explores a future in which settlement, verification, certification, and correction become independent protocol primitives. By separating progression from correctness, the network seeks to provide a foundation upon which increasingly complex computational systems can interact, verify outcomes, and converge toward shared truth.

The applications described in this section represent only a subset of the systems that may emerge from a verification-first settlement architecture. Future use cases will likely be discovered by developers, researchers, and organizations operating at the frontier of verifiable computation.

Conclusion

Blockchain systems have traditionally treated ordering, execution, verification, and finality as a single tightly coupled process. This design has proven remarkably successful in establishing trustless systems, but it increasingly faces challenges as modern applications introduce heterogeneous forms of computation whose verification costs vary dramatically.

Iraquin explores a different approach.

Rather than requiring every transaction to progress through a single verification path, the protocol separates settlement from correctness certification. Prime establishes canonical ordering and optimistic settlement, while Omega independently verifies correctness, advances certification, and performs deterministic forward correction when invalidity is discovered.

The result is a verification-first settlement architecture in which correctness and progression become independent protocol responsibilities.

To support this model, Iraquin introduces dependency-aware state tracking, asynchronous certification, bounded verification windows, and forward correction semantics that preserve append-only ledger continuity without relying on rollback or speculative chain reorganization.

While the protocol was motivated by the growing diversity of modern proof systems and external computation environments, its broader objective is to explore how decentralized systems may evolve when correctness is treated as a continuous process rather than a synchronous requirement.

As computation increasingly moves beyond the boundaries of the blockchain itself, the challenge shifts from executing computation to establishing confidence in its outcomes.

Iraquin represents one possible path toward that future.

The protocol is not an attempt to replace verification with optimism, nor to replace correctness with speed. Instead, it seeks to separate the two concerns so that each can evolve independently while remaining cryptographically connected.

The future of decentralized systems may not be defined solely by how computation is performed, but by how its results are verified, certified, and trusted.

Iraquin is an exploration of that future.