Txtx

Txtx is the team that built Surfpool and Txtx runbooks, two free tools for Solana developers. Surfpool is a local test network. It is the one Anchor uses by default. Runbooks let you write a smart contract deployment as code. The idea comes from HashiCorp Terraform: you say what you want deployed, and the tool works out the steps.

Txtx is no longer an independent company. As of October 2026, Colosseum lists it as acquired. Its two cofounders now work at the Solana Foundation, and so does its code. Both tools are open source under the Apache 2.0 licence and still maintained.

Is Txtx now part of the Solana Foundation?

In practice, yes. Several public records point the same way:

• The Txtx and Surfpool repositories now live under the solana-foundation GitHub organisation. Old github.com/txtx/... links redirect there.
• Cofounder Micaiah Reid's X profile reads "Cofounder at Txtx where we built @surfpool_sol & @moneymq. Now building @solanafndn".
• Colosseum's portfolio page gives Txtx's status as "Acquired" and lists surfpool.run as its website.
• Surfpool's documentation is now hosted on solana.com.

We found no public post giving a date or terms. The move was done by 2 April 2026. The Anchor 1.0 release notes from that day already link to the Foundation's copy of Surfpool. The old txtx.sh website now shows a "page not found" error. The docs at docs.txtx.sh still work.

For developers, little has changed. The same people still maintain both tools. The work now sits inside Solana's official tool set instead of next to it.

How Txtx runbooks work: infrastructure as code for smart contracts

A Txtx runbook is a config file that describes a whole deployment from start to finish. It lists which programs to deploy, in what order, with which settings, and who has to sign each step. The language is a cut-down version of HCL, the config language Terraform uses. It has no loops or general-purpose code, so the runbook can be checked before anything runs. Runbooks sit in source control and get reviewed like any other code change.

The runtime keeps a record of what earlier runs did. When you run a runbook again, it applies only the steps that differ from what is already on-chain, so it doesn't send the same transactions twice. Steps can also check on-chain state before and after they run, and halt the deployment if something doesn't match.

An optional browser interface, the supervisor, walks you through a run. It connects your wallet and asks for each signature when that step comes up. Your key stays in your browser or hardware wallet. It is never saved in a script on disk. The Surfpool docs say a project can switch from a single key to a Squads multisig by changing configuration, with no code to rewrite.

The engine supports Solana and other chains built on the Solana Virtual Machine, Ethereum and other EVM chains, Bitcoin and Stacks. The Solana add-on can deploy Anchor programs and, since June 2026, create tokens (the svm::deploy_token action). The Txtx repository says the platform "is currently in beta" and asks users to run it "for testing purposes only".

Surfpool: the Solana local validator built by Txtx

Surfpool is a "drop-in replacement for solana-test-validator", the local test network that ships with the Solana CLI. The difference is where the data comes from. solana-test-validator starts empty. Surfpool fetches mainnet accounts and programs when your tests first touch them. Your changes stay on your machine. So a test that calls a live DEX or oracle runs against the real program and its current state. You never download a full copy of the chain. Helius, where Surfpool came out of the Helius Startup Launchpad, calls this a "lazily forked network, copying state on read and writing changes locally".

Anchor 1.0 came out on 2 April 2026. Since then, anchor test and anchor localnet run on Surfpool by default. To use the old validator, pass --validator legacy. Solana's own setup guide now has a page on the Surfpool command line.

Surfpool also has the runbook engine built in. Start it inside an Anchor or Pinocchio project and it writes a deployment runbook for you. That one file can then take the program to devnet and on to mainnet.

Surfpool cheatcodes, token faucet and Surfpool Studio

According to surfpool.run and the repository, Surfpool adds these tools on top of the standard RPC interface:

• Cheatcodes. Extra RPC methods (named surfnet_*) that set account data and token balances, move the clock forward (surfnet_timeTravel) or reset the network.
• A token faucet that hands out SOL, USDC, USDT and BONK for testing.
• Surfpool Studio, a local dashboard at localhost:18488. It shows transactions and accounts as they change, byte by byte, and how much compute each instruction uses.
• Scenarios for setting up account states slot by slot. Release notes mention ready-made scenarios for Pump and Kamino.
• Jito bundle testing, through simulateBundle and getBundleStatuses.
• A tool that turns a program's IDL into SQL tables, and an MCP integration so AI coding agents can drive a local network.

Surfpool vs solana-test-validator and LiteSVM

Pick Surfpool when your program calls code that is already live on mainnet. With solana-test-validator, you copy every outside program and account by hand. Those copies go stale when the live programs change. Surfpool fetches them as needed. solana-test-validator still makes sense offline, or when a test must never touch mainnet. Surfpool needs an internet connection to fetch accounts.

LiteSVM is a different kind of tool. It runs a small Solana runtime inside your test code, with no network server, so unit tests run very fast. The Solana Foundation's testing guide treats LiteSVM, Mollusk and Surfpool as layers of one strategy, and notes that Surfpool is itself built on LiteSVM. A common setup uses LiteSVM or Mollusk for fast unit tests and Surfpool for integration tests against mainnet state.

For deployments, the alternatives are hand-written shell scripts or a plain anchor deploy. Runbooks add a stored record of past runs, checks before and after each step, and signing through a browser or multisig. The cost is a new config language to learn, and an engine its own maintainers still call beta.

How to install Surfpool and Txtx

• Surfpool: run the one-line installer script from run.surfpool.run (the exact command is on surfpool.run), then surfpool start from a project directory. There is also a Docker image (surfpool/surfpool) and a source build (cargo surfpool-install). Anchor 1.0 starts Surfpool for you during anchor test.
• Txtx CLI (standalone runbooks): brew install txtx/taps/txtx on macOS, or build from source. The docs are at docs.txtx.sh.

MoneyMQ: Txtx's stablecoin payments engine

MoneyMQ was a later Txtx product. It called itself "Stripe, but for stablecoins". It was a payments engine you could host yourself, with support for x402, a way to charge for each API call in stablecoins. The project was archived in June 2026. It now points to the Solana Foundation's pay tool instead. Don't start new work on MoneyMQ.

Who should use Txtx and Surfpool

• Solana program developers on Anchor 1.0 or later already use Surfpool unless they opt out. It suits teams whose programs call other live protocols and who want local tests to run against real mainnet state.
• Teams preparing a mainnet launch or upgrade that want repeatable deployments reviewed in source control, with multisig signing, should look at runbooks. The beta label means the setup should be tested on devnet first, and someone on the team needs to read and maintain the config files.
• Developers who need offline or fully isolated tests, or who only need fast unit tests, will be better served by LiteSVM, Mollusk or solana-test-validator.
• Txtx has no consumer product, so it isn't relevant to traders or token holders.

Is Txtx safe? Risks and limitations

Txtx and Surfpool run on your own machine or build server. They are not on-chain programs. There is no upgrade key, treasury or user deposit to lose. We found no published security audit of either tool. The risks come from how you use them:

• Beta status. The Txtx repository says the platform is "currently in beta" and should be used "for testing purposes only". That is an awkward label for a tool whose purpose is mainnet deployment. Any mainnet runbook needs a dry run on devnet and a careful review first.
• Installer trust. The standard Surfpool install pipes a remote script into your shell. Teams with strict supply-chain rules may prefer the source build or the Docker image, pinned to a version.
• Forked state is not mainnet. Surfpool copies an account the first time you read it. If that account later changes on mainnet, your local copy can fall behind. Timing, fee markets and other live network behaviour are simulated, not real.
• Key handling still depends on you. Runbooks are designed to keep private keys off disk and to send signing to a wallet or Squads. A runbook set up with a local keypair file still exposes that file.
• A small, consolidated team. Both tools rely on a few core maintainers, now at the Solana Foundation. That makes long-term support more likely, but the roadmap now follows the Foundation's priorities.

Txtx team, funding and history

Ludo Galabru and Micaiah Reid cofounded Txtx. Reid's profile lists earlier roles at Consensys and Hiro Systems. Txtx built runbooks first for Bitcoin and Stacks. Its GitHub README says the first runbook executed on mainnet moved $2.5 million.

In November 2024, Txtx won first place in the Infrastructure track of Colosseum's Solana Radar Hackathon. The prize was $30,000 in USDC. Colosseum described it as "a developer platform for engineering teams to leverage runbooks". Txtx then joined Colosseum's second accelerator group, where each team got $250,000 in early funding. Txtx never had a token, and its tools don't need one.

The team presented Surfpool at Solana Accelerate 2025 (talk summary). Within a year, Surfpool went from hackathon tool to Anchor's default. Then the team and its code moved to the Solana Foundation.