About Engine Room

What this desk covers

Engine Room writes about the internals of automated trading systems on Solana, at the level an engineer would need to build one or to evaluate somebody else's. That means components and their contracts, the transaction pipeline from intent to confirmation, and the reliability behaviours that decide whether a system can be left running: retries, backpressure, metrics and safe growth.

The subject is deliberately narrow. There is no market commentary here, no token coverage, no price analysis and no strategy. Those are different disciplines with different failure modes, and mixing them into a systems publication produces writing that is authoritative about neither.

Who this is for

Three readers, in roughly this order. Someone building a system and looking for the shape of a component before writing it. Someone operating a system and trying to work out why it behaves the way it does under load. And someone evaluating a hosted tool who wants to know which questions actually distinguish a serious implementation from a fast one.

The notes assume you are comfortable with the idea of a transaction, an account and a program on Solana. They do not assume you have written one, and where a protocol mechanism matters to the design it is explained rather than referenced.

How a note gets written

A note starts as a component, not as a keyword. The desk picks a part of a system, works out what it receives and what it must produce, then writes down the ways it fails and what each design choice costs somewhere else. If a section cannot state a trade-off, it usually means the section has described a preference as though it were a conclusion, and it gets rewritten.

Protocol behaviour comes from Solana's public documentation and from responses anyone can reproduce against a public endpoint. Where a claim depends on a specific validator build, a private endpoint policy or a provider's internal behaviour, the note says the claim is unverified rather than rounding it into a fact. That is why several answers on this site end with a statement about what is not known.

What this desk will not publish

• Claims about how any specific product is implemented. A hosted engine is described by what it exposes to a user, never by a guessed architecture.
• Runnable automation. Notes publish component contracts, sequence steps and pseudocode, because the useful thing to convey is the boundary rather than the implementation.
• Performance statistics, benchmark tables, review counts, ratings or testimonials. There are no numbers on this site that describe results the desk cannot show you the source of.
• Invented authors. Every note carries the desk byline because the work is collective and no individual credential is being sold to you.
• Financial advice of any kind. Everything here is engineering description, and it stays on that side of the line deliberately.

About the byline

Notes are signed by The Engine Room Desk. That is an editorial byline, not a person, and it is used because inventing a named engineer with a fabricated background would be the easiest way to make this site look more credible and the fastest way to make it dishonest. The desk stands behind the work, and the corrections policy is the mechanism by which that means something.

Numbers on this site

Three kinds of number appear here and each is labelled. Protocol constants, such as the packet size limit or the base fee per signature, are stated as constants and can be checked against public documentation. Illustrative arithmetic uses inputs the reader supplies and is always introduced as illustrative. Everything else, meaning any figure describing an outcome, does not appear at all, because the desk does not operate engines and has no results to report.

If a page ever presents a number that does not fall into one of those categories, that is an error and the desk would like to hear about it. The editorial policy sets out how corrections are handled, and the contact page is the route for raising one.