On-Chain Program#

Seesaw's on-chain program does real work inside each instruction — matching orders against a resting book, moving collateral, and settling positions — all within Solana's per-instruction compute budget. That requirement drives how the program is built: for low compute overhead, a small binary, and direct (zero-copy) access to account data.

The program is built on Pinocchio, a thin framework over Solana's raw runtime, rather than a heavier framework. The choice trades some convenience for efficiency and explicit control, which suits a financial protocol.

What this enables#

Zero-copy account access. State accounts (market, order book, position) are fixed-layout structs read directly from account bytes with no deserialization step. The 10,240-byte order book in particular is accessed in place, which keeps matching cheap; deserializing it on every instruction would consume a large share of the compute budget.
Low compute overhead. Without per-instruction deserialization or a heavy account-constraint layer, more of the compute budget is available for the matching and settlement logic itself.
A small, cheap-to-deploy binary. A lean framework keeps the program binary small, which lowers deployment cost and speeds upgrades.
Explicit account handling. Account ownership, signer, and address (PDA) checks are written out deliberately rather than hidden behind macros — appropriate for code that custodies funds, and easier to audit.
Cross-program calls via typed wrappers. Token transfers and account creation go through Pinocchio's typed token and system helpers, keeping CPI explicit and low-overhead.

How it's kept safe and usable#

Building close to the runtime means the program does not get a framework's safety rails and conveniences for free, so it provides them deliberately:

A testable core. Business logic is written against an abstraction over the Solana runtime, so the same logic runs against real on-chain accounts in production and against in-memory state in tests. The bulk of the protocol's logic is exercised by fast native unit tests in addition to on-chain integration tests, property tests, fuzzing, and mutation testing.
Explicit, checked arithmetic on all value-handling paths, with rounding that always favors protocol solvency.
A generated client interface. Because the framework does not emit an interface description automatically, Seesaw generates its IDL and typed clients from the program, with checks to keep them in sync. See the SDK Guide.

Alternatives we did not take#

A full-featured framework (with automatic interface generation and account constraints) adds per-instruction deserialization and binary-size overhead that is too costly for the large order-book account, and tends to hide logic that is better kept explicit here.
No framework at all (raw runtime calls) removes even the typed CPI and account helpers, adding error-prone boilerplate for little gain over a thin framework.

This is implementation background; you do not need to know any of it to trade or to integrate. For account layouts and the instruction set, see Architecture. For the order-book design that benefits most from zero-copy access, see Design → Order Book. For oracle integration design, see Design → Price Oracle.

On-Chain Program#

What this enables#

Zero-copy account access. State accounts (market, order book, position) are fixed-layout structs read directly from account bytes with no deserialization step. The 10,240-byte order book in particular is accessed in place, which keeps matching cheap; deserializing it on every instruction would consume a large share of the compute budget.

Low compute overhead. Without per-instruction deserialization or a heavy account-constraint layer, more of the compute budget is available for the matching and settlement logic itself.

A small, cheap-to-deploy binary. A lean framework keeps the program binary small, which lowers deployment cost and speeds upgrades.

Explicit account handling. Account ownership, signer, and address (PDA) checks are written out deliberately rather than hidden behind macros — appropriate for code that custodies funds, and easier to audit.

Cross-program calls via typed wrappers. Token transfers and account creation go through Pinocchio's typed token and system helpers, keeping CPI explicit and low-overhead.

How it's kept safe and usable#

Building close to the runtime means the program does not get a framework's safety rails and conveniences for free, so it provides them deliberately:

A testable core. Business logic is written against an abstraction over the Solana runtime, so the same logic runs against real on-chain accounts in production and against in-memory state in tests. The bulk of the protocol's logic is exercised by fast native unit tests in addition to on-chain integration tests, property tests, fuzzing, and mutation testing.

Explicit, checked arithmetic on all value-handling paths, with rounding that always favors protocol solvency.

A generated client interface. Because the framework does not emit an interface description automatically, Seesaw generates its IDL and typed clients from the program, with checks to keep them in sync. See the SDK Guide.

Alternatives we did not take#

A full-featured framework (with automatic interface generation and account constraints) adds per-instruction deserialization and binary-size overhead that is too costly for the large order-book account, and tends to hide logic that is better kept explicit here.

No framework at all (raw runtime calls) removes even the typed CPI and account helpers, adding error-prone boilerplate for little gain over a thin framework.