Banner: AI-generated editorial illustration.
Monad introduced Typewriter on October 8. The prototype gives applications their own rules for ordering user actions, with built-in accounts and gas sponsorship. Its introduction points to exchanges, games and marketplaces as possible uses. Monad introduction.
How an action reaches the chain
A user signs an application action, called a mutation, and sends it to the app server. The server orders it, runs it against a local copy of the application's state and returns a response. It then submits batches of actions onchain in the same order.
That response arrives before onchain confirmation. The server and the chain run the same application logic, but the chain remains authoritative if their results disagree.
The README distinguishes five stages: received, accepted, included, safe and finalized. For a product interface, that distinction is useful: accepting an action locally is not the same as telling a user it has settled. Prototype README.
Normal server path; the delayed force-inclusion route is described below. AI-generated conceptual diagram based on Monad’s introduction.
The server still has a role
Users rely on the application server for ordering and availability. Signatures and contract authorization govern which actions are permitted. Permission checks do not remove the need to trust the server's ordering behavior.
If the server becomes unresponsive or refuses an action, Typewriter offers a force-inclusion route. The user puts the signed action in an onchain queue. During a fixed delay, the server can execute it through the normal path. After the delay, anyone can call the contract to execute it, provided it remains valid. This is a delayed alternative, not a promise of an immediate response. Trust model.
Where the prototype fits
The introduction describes limits on application logic. Mutations cannot call arbitrary external contracts, whose state could change between local execution and settlement. Applications that need other contracts to call them directly also face a composability constraint.
That makes the interaction pattern part of the design choice. Application-specific ordering may suit a user-facing product, while direct interaction with other protocols may be essential to another. The prototype needs to be evaluated against those requirements.
Typewriter remains under development. Its public README says it has not been audited and is not ready for production use. The implementation and examples are available for inspection; that availability does not establish production readiness. Prototype README.
Sources
- Applications can define how their signed user actions are ordered.
- Application acceptance happens before onchain settlement.
- Users rely on the server for ordering and availability, with a delayed force-inclusion route.
- The prototype is unaudited and is not ready for production use.