k256
WhyHow we thinkPricesDocs
WhyHow we thinkPricesDocs
[00]why / the gap

The gap.

what nobody puts on the landing page is that solana execution is sold one way and operated another. we built k256 for the second one.

Picture a Tuesday. A ticket comes in at 11:47pm. A user claims their swap executed at a bad price during a minute of real volatility. Support has the signature. They do not have the route. They do not have the pool state at that slot. They do not have the fee chosen, the retry history, or the reason the first submission expired. They have a log line and a theory.

The engineer on call opens three dashboards. None of them were designed to answer this question. The product manager wants a policy change for the next volatile window. The compliance lead wants to know which venues were eligible for that trade and who decided. By the time any of them have an answer, the user has already posted a screenshot on a public channel.

this is the moment the execution stack stops being a routing problem and starts being an operations problem.

Every team that runs on-chain execution at any real scale meets this moment. The choice they made at the start of the year decides how painful it is. And the choice today is narrow.

An isometric diagram of two architectural structures: a dense, cluttered in-house assembly on the left, a sealed consumer-API monolith on the right, and a single teal puzzle piece floating in the gap between them.

the shape of the choice

[01]the two doors

Two doors.
Neither one is an operator's door.

Door one is to build it. Hire two or three senior systems engineers. Spend a year integrating venues. Spend another year chasing the landing path. Spend the year after that keeping up with the venues, the validator clients, the fee markets, and a policy model your compliance team will redesign twice. The product you are trying to ship waits for the stack you are forced to own.

Door two is to integrate a routing API that was designed for a consumer swap interface. Start fast, ship a demo, announce a partnership. Then, quietly, find out that the policy you wanted is not in the product, the lifecycle you needed is not exposed, the evidence you require for a support ticket does not exist, and the deployment topology your security team asks for was never on the roadmap. You end up either accepting that, or quietly rebuilding it anyway.

Those two doors are not the same problem. One gives you everything and crushes your team with it. The other gives you the easy part and walks away from the hard part. The gap between them is where everyone actually lives.

[02]what we mean by execution

Five things,
not one.

When we say execution we do not mean routing. Routing is one step. What actually has to happen, end to end, before an operator can sleep:

data
know the market. live, in-memory, not a retry loop against rpc.
routing
find the path. honestly compete algorithms, not one frozen preference.
delivery
land the transaction. retry, confirm, cancel. deliberate, not lucky.
policy
say no before the wire. fee caps, venue allowlists, slippage bounds, endpoint gates.
evidence
replay what happened. against the actual slot, not a guess from a log.

the moment you need them together is the moment you find out your stack only has three.

[03]the third option

A neutral counterparty
for the whole path.

A third option owns the full path from quote to terminal outcome. It is neutral: it does not run its own destination you are implicitly competing with, and it does not ship a token that rewrites its incentives later. It is non-custodial: signing authority stays with the caller, always. It is controllable: policy is a first-class surface, not a ticket in someone else’s backlog.

k256 is the control plane we wanted to buy, and could not.

It aggregates liquidity. It builds the route. It lands the transaction and retries when it has to. It enforces your policy server-side, so every request that reaches the wire has already been through your rules. It keeps a durable lifecycle of every accepted piece of work, pollable, with an explicit terminal reason, with signed webhooks when you want them. And it keeps enough captured state that you can replay a request against the slot it actually ran in.

[04]why now

Solana
is not slowing down.

The protocol surface under every Solana team is about to move more than it has moved in years. New validator clients. New finality targets. A proposed change in how transactions are included that, if it lands, turns transaction selection into its own sub-problem with its own fee curve and its own lifecycle depth. Every team that owns its own execution stack will feel each of those shifts personally.

The teams that integrated an abstraction layer will not. That is the plain argument for why this is the right thing to build now. An abstraction layer is most valuable on the day the thing underneath it moves.

[05]who is building this

Operators
who were paged for this.

k256’s core runtime (the routing engine, the landing runtime, the capture pipeline, the policy engine, the control plane) is built by engineers who have run production Solana infrastructure at scale. The failure modes this product addresses are the ones we have carried a pager for.

next / how we think
k256
WhyHow we thinkPricesDocs
© 2026 k256