Building fully onchain is not the easiest path. It is slower, more complex and far less forgiving than pushing key components off-chain or hiding execution behind APIs. In practice, many teams take that route in the name of performance or convenience.

We made a different choice.

From the beginning, o2 was designed to operate entirely onchain. Not partially. Not “onchain for settlement, off-chain for everything else.” Fully onchain: execution, state changes and system logic included.

This decision wasn’t ideological. It was practical.

On o2, “fully onchain” means that trade execution, scoring, incentive logic and state transitions all happen through smart contracts. There is no off-chain engine interpreting results or applying adjustments behind the scenes. If a rule exists, it exists onchain. If an outcome happens, it happens through contract execution.

When systems operate off-chain, transparency becomes a promise. Users are told how things work, but they can’t independently verify what’s happening behind the scenes. Execution logic, matching behavior and state transitions are hidden in places users can’t see.

Onchain systems remove that ambiguity.

Every transaction on o2, every state change, every operation is publicly verifiable. Not through dashboards or status pages, but through the blockchain itself. This isn’t “trust us, we’re transparent.” It’s mathematical and cryptographic transparency.

In practice, this means traders can verify how scores are calculated, how referral volume contributes, when boosts apply and how rewards are distributed; directly from onchain data. The order matching rules themselves are auditable onchain, which matters because they directly affect the prices users are exposed to. There is no secondary system translating or “summarizing” results after the fact.

That distinction matters, especially in competitive trading environments where execution quality, fairness and predictability directly affect outcomes.

Fully onchain architecture also changes how security works.

o2 doesn’t rely on a separate security model layered on top of the blockchain. It inherits the security guarantees of the Fuel network itself. The same consensus, validation and cryptographic protections that secure Fuel also secure o2.

There are no centralized components that can become single points of failure. There is no privileged backend that can reorder execution, selectively exclude participants or alter system behavior.

Security isn’t something we bolt on later. It’s native.

The most powerful consequence of being fully onchain isn’t just transparency or security. It’s composability.

Because o2 is entirely onchain, other smart contracts can interact with it directly. No permissions. No API negotiations. No intermediaries. Developers can simply build.

Trading strategies can interact with o2 contracts directly. Analytics tools can compute scores without relying on internal APIs. Other protocols can use o2 activity as an input to their own logic. These integrations don’t require coordination or approval, they emerge naturally from open infrastructure.

This level of interoperability isn’t possible when core components live off-chain. It requires infrastructure that is open by default.

Choosing to build fully onchain also meant designing o2 as infrastructure, not just a product.

It meant building systems that wouldn’t need to be reinterpreted, rewritten or selectively enforced as usage increased. Rules that exist as code don’t drift over time. Incentives that are enforced onchain don’t depend on discretion.

We aren’t building for the next quarter. We are building for the next phase of the ecosystem: one where transparency, composability and security aren’t optional.

Fully onchain architecture is our commitment to doing things right, not just doing things fast.


For those of you who want to explore the architecture in more detail or build on top of o2, tech documentation is available in the o2 docs: docs.o2.app

Building fully onchain is not the easiest path. It is slower, more complex and far less forgiving than pushing key components off-chain or hiding execution behind APIs. In practice, many teams take that route in the name of performance or convenience.

We made a different choice.

From the beginning, o2 was designed to operate entirely onchain. Not partially. Not “onchain for settlement, off-chain for everything else.” Fully onchain: execution, state changes and system logic included.

This decision wasn’t ideological. It was practical.

On o2, “fully onchain” means that trade execution, scoring, incentive logic and state transitions all happen through smart contracts. There is no off-chain engine interpreting results or applying adjustments behind the scenes. If a rule exists, it exists onchain. If an outcome happens, it happens through contract execution.

When systems operate off-chain, transparency becomes a promise. Users are told how things work, but they can’t independently verify what’s happening behind the scenes. Execution logic, matching behavior and state transitions are hidden in places users can’t see.

Onchain systems remove that ambiguity.

Every transaction on o2, every state change, every operation is publicly verifiable. Not through dashboards or status pages, but through the blockchain itself. This isn’t “trust us, we’re transparent.” It’s mathematical and cryptographic transparency.

In practice, this means traders can verify how scores are calculated, how referral volume contributes, when boosts apply and how rewards are distributed; directly from onchain data. The order matching rules themselves are auditable onchain, which matters because they directly affect the prices users are exposed to. There is no secondary system translating or “summarizing” results after the fact.

That distinction matters, especially in competitive trading environments where execution quality, fairness and predictability directly affect outcomes.

Fully onchain architecture also changes how security works.

o2 doesn’t rely on a separate security model layered on top of the blockchain. It inherits the security guarantees of the Fuel network itself. The same consensus, validation and cryptographic protections that secure Fuel also secure o2.

There are no centralized components that can become single points of failure. There is no privileged backend that can reorder execution, selectively exclude participants or alter system behavior.

Security isn’t something we bolt on later. It’s native.

The most powerful consequence of being fully onchain isn’t just transparency or security. It’s composability.

Because o2 is entirely onchain, other smart contracts can interact with it directly. No permissions. No API negotiations. No intermediaries. Developers can simply build.

Trading strategies can interact with o2 contracts directly. Analytics tools can compute scores without relying on internal APIs. Other protocols can use o2 activity as an input to their own logic. These integrations don’t require coordination or approval, they emerge naturally from open infrastructure.

This level of interoperability isn’t possible when core components live off-chain. It requires infrastructure that is open by default.

Choosing to build fully onchain also meant designing o2 as infrastructure, not just a product.

It meant building systems that wouldn’t need to be reinterpreted, rewritten or selectively enforced as usage increased. Rules that exist as code don’t drift over time. Incentives that are enforced onchain don’t depend on discretion.

We aren’t building for the next quarter. We are building for the next phase of the ecosystem: one where transparency, composability and security aren’t optional.

Fully onchain architecture is our commitment to doing things right, not just doing things fast.


For those of you who want to explore the architecture in more detail or build on top of o2, tech documentation is available in the o2 docs: docs.o2.app