Introducing Typewriter

Introducing Typewriter, a framework for crypto apps that offers custom transaction sequencing, fast confirmations, and built-in accounts with gas sponsorship.

The transaction supply chain

When a user clicks "buy" in a crypto application, the request typically passes through a wallet, an RPC provider, a mempool, a block builder, a fee market, and a consensus algorithm. Together, these systems form a transaction supply chain.

This supply chain shapes the user experience, determining how quickly the application can respond, how competing transactions are ordered, and what fees the user has to pay. It is effectively part of the product, yet developers rarely give it the same attention as the rest of the application.

Apps are building their own infrastructure

To offer a user experience that competes with centralized alternatives, some of crypto's most successful applications have decided to take these concerns into their own hands.

Hyperliquid controls the entire transaction supply chain. It runs its own chain, with execution and consensus designed specifically for an exchange. As a result, blocks confirm in under a second, trades don't require gas, and transaction ordering follows exchange rules. For example, the chain processes cancels before new orders, so market makers can pull stale quotes before they're filled.

Polymarket uses an existing chain for settlement, but moves the majority of the transaction supply chain offchain. Users sign orders, an operator matches them in an offchain order book, and smart contracts settle the matched trades. Users get exchange-speed matching without paying gas on each order.

These systems demonstrate the potential value of application-specific infrastructure, but they're also bespoke and require substantial engineering investment. New applications that want the same degree of control typically need to rebuild these features from scratch.

Typewriter

Typewriter is a framework that gives application developers more control over the transaction supply chain, without the engineering investment of building this infrastructure from scratch.

Developers write the application's state transitions in Solidity. Users interact with the application by signing mutations, which are application-specific actions such as placing an order. An application-operated server runs the same Solidity logic offchain to order and execute mutations before they reach the chain:

The user signs a mutation with their account credentials.
The server receives the mutation and sorts it among other pending mutations according to the application rules.
The server executes the mutation against a local copy of contract state, which includes the state transitions of all previously accepted mutations.
The server responds to the user immediately, without waiting for onchain confirmation.
The server submits batches of mutations onchain in the same order as execution.

Because the server and the chain run the same mutations in the same order, the result the user receives matches the onchain result.

Features

Typewriter gives applications several properties that are difficult to achieve through the standard transaction supply chain.

Custom sequencing. Applications can process mutations in arrival order (FIFO), or collect short batches and prioritize certain mutation types.
Fast confirmations. Transactions are processed by the application server in single-digit milliseconds, before any block is produced.
Built-in accounts. Passkeys and session keys are first-class through EIP-712 plus P-256, WebAuthn, and secp256k1 verification. Users can add and remove credentials without changing their account identity, and credentials can have scoped permissions and expiration times.
Gas sponsorship. The server pays for settlement transactions.
No intermediaries. No external relayers, sequencers, or builder auctions between users and the application.

Typewriter provides a consistent programming model for building application-specific transaction systems, while abstracting the common infrastructure required to run them.

How it works

During normal operation, the contract only accepts mutations from the application's scheduler address, which the server controls. No other transaction can modify the contract's state between local execution and onchain settlement. This lets the server execute mutations in a local EVM, return results immediately, and later submit the same mutations onchain in the same order.

The Solidity contract is the single definition of the application's state transitions and authorization rules. The server runs it locally to compute results ahead of settlement, and the chain runs it to settle them. If the two ever disagree, the onchain result is canonical.

Trust model

Typewriter users trust the application server with ordering and liveness. They don't trust it with custody or authorization.

The server decides which mutations execute and in what order. Users trust the operator not to reorder mutations for the operator's own benefit, such as by front-running a trade, in the same way they trust a centralized exchange's matching engine. However, the server is designed to not forge user intent or move user funds — every mutation requires the user's signature and must pass the contract's authorization rules.

Force inclusion. If the server becomes unresponsive or refuses a mutation, the user can force-include it:

The user submits a signed mutation to a queue in the contract.
During a fixed delay, the server can execute the queued mutation through the normal path.
After the delay, anyone can call the contract to execute the mutation, as long as it's still valid.

The delay gives the server a chance to recover from brief liveness issues while ensuring that local results match onchain results.

When to use Typewriter

Typewriter is for applications that serve users directly, such as exchanges, games, and marketplaces. These applications benefit from fast responses and control over ordering, and they typically already run offchain infrastructure.

Typewriter is a poor fit for composable infrastructure like WETH and spot exchanges that serve swap aggregators. Other contracts call these contracts directly within their own transactions, but Typewriter routes every state change through the application's server, which breaks that composability. These contracts also gain little in return, because they don't need custom ordering or fast local responses.

The current prototype also introduces some limits on application logic, because each mutation must produce the same result locally and onchain:

Mutations can't call arbitrary external contracts because their state can change between local execution and settlement.
Block timestamps and other block-dependent values can differ between local execution and settlement. Applications that use these values must tolerate the difference.

What's next

We're looking for teams building applications where transaction ordering, confirmation latency, or transaction UX are product constraints. If Typewriter would let you offer something meaningfully better to your users, we want to work with you.

You can find the Typewriter prototype and example applications on GitHub, or reach out to @kyscott18 on X.