Writ — a written command that executes

Abstract

Writ turns a plain-English sentence into a live, on-chain trading automation. A user writes an instruction — for example, “if NVDA beats earnings, buy $20 and text me” — and Writ parses it into a persistent rule, watches for the trigger, and, when it fires, executes a swap into the user’s own wallet. Writ is non-custodial: it never holds user funds and acts only within a capped, revocable allowance.

The problem

Event-driven trading is hard to express with the primitives most venues offer. Limit orders capture price, but not real-world events like an earnings beat, a portfolio drawdown, or a recurring schedule. Doing this today means scripts, dashboards, or handing custody to a third party. Writ removes that friction: you say what you mean, confirm what it understood, and keep your keys.

How it works

• Parse. Natural language is turned into a structured, confirmable rule — trigger, asset, action, size, and notification.
• Authorize. The user grants a capped USDC allowance once. Writ can spend only within it, and only when a rule fires.
• Watch. An off-chain evaluator monitors the trigger, paying per call for market and event data.
• Execute.On a fire, the trade is routed on-chain for best price and settles to the user’s wallet — never an account Writ controls.

Architecture

Writ is a thin orchestration layer over existing on-chain rails rather than a reinvention of them:

• Settlement & execution on Solana, routed for best price with user-set slippage limits.
• Delegated, capped spendso funds stay in the user’s wallet and the authorization expires or can be revoked.
• Pay-per-call data in USDC for the market and event signals that drive triggers — predictable cost, no standing subscriptions.
• Tokenized equities and liquid on-chain assets as the tradeable universe, subject to jurisdictional availability.

$WRIT — design intent

The intended role of a native token is to align usage with the network, not to serve as a fee currency. Fees and data are denominated in USDC so costs stay predictable. The design intent is a usage-linked model:

• Stake-per-slot. Each live automation slot requires staking a token amount referenced to a USD value, so more automations running means more supply committed.
• Burn-per-execution. Each executed automation burns a fixed USD value of token, so more usage means more supply retired.

This section describes design intent only. Any token mechanics are subject to change and legal review, are not final, and create no expectation of profit or return. There is no token sale described here.

Roadmap

• Prove the non-custodial allowance and pay-per-call data loop.
• Execution path and slippage handling.
• Natural-language rule engine and event evaluator.
• Product surface: rule management, allowance controls, notifications.

This draft will be revised. It is not an offer or solicitation and is not investment advice. Consult your own advisers before making any decision.