Michael Sutton has opened a new experimental compiler project called Argent, a high-level frontend for Silverscript covenant contracts. Silverscript lets developers write individual covenant contracts on Kaspa. Argent tries to solve a different problem: helping developers write an application made of several covenant contracts that move through a controlled state machine together. (Argent README)
Sutton described Argent as "a small high-level DSL for multi-contract covenant apps that produces silverscript code." (Sutton thread) The project repository calls it a very early research prototype, not production-ready, not audited, and not stable. (Argent README) That warning matters. Argent is not a product launch. It is Sutton opening the workshop door while the idea is still being shaped.
The motivation traces back to a chess experiment Sutton ran earlier. He tried to explore complex Silverscript contracts by building a chess game, but the single-script approach became unwieldy once rules, pieces, movement checks, and state updates were all packed into one script. (Sutton thread) The chess work then split into multiple contracts: a League contract, a Player contract, a Game family, and a ChessSettle contract, with the game itself divided into a router and separate worker contracts for pawn, knight, diagonal, horizontal, vertical, king, castling, and settlement logic. (chess webinar notes) (chess Silverscript tree)
For readers who know what Silverscript is but have not gone deeper, the change is straightforward. Instead of one large contract trying to encode every rule, the application becomes a set of small contracts with narrow jobs. A chess router sends a claimed move to whichever worker contract knows how to validate that type of move. A settlement contract later converts a finished game result into updated player state and value distribution. (ChessMux) (ChessSettle)
That structure fits the UTXO model. Sutton drew a contrast with traditional virtual-machine chains, where a complex application can live as one long-running global object. In a UTXO covenant model, code only gets revealed when a UTXO is spent, so the design pressure runs the other way: reveal only the specific validator path being used at that moment. (Sutton continuation)
This is why Ori Newman's earlier comparison to Bitcoin-style MAST only goes part of the way. MAST lets a spend reveal one branch from a precommitted tree of script paths. (Bitcoin Optech MAST) Argent is dealing with a broader problem, where several separate covenant contracts coordinate as a state machine across multiple transactions, not just multiple branches of one script. (Sutton continuation)
Argent's central language feature is the keyword become. Sutton called it the most significant word in the language, since it lets a developer state which contract or contracts the application should transition into next. (Sutton continuation) In a small example called Tickets, an Issuer contract can issue a new Ticket: the source simply says the issuer output should become the next Issuer state, while a separate output should become a Ticket state. (Tickets example)
The Silverscript that Argent generates from that statement performs the mechanical verification. It checks that the output is locked to the expected contract template and the expected state bytes through validateOutputStateWithTemplate. (generated Issuer Silverscript) That is the detail worth sitting with. Argent does not add a new consensus feature to Kaspa. It moves repetitive, error-prone contract-routing code out of hand-written application logic and into a compiler.
According to the project README, current working pieces include multi-file .ag parsing, shared state and helper declarations, actor definitions, entry points, delegates, references to other covenant contracts as inputs, named output handles, terminal become routes, generated hidden template fields, generated typed state reads, and generated successor checks. (Argent README) A second example, called Stones, demonstrates the same pattern in a smaller two-player game built from League, Player, StonesGame, and StonesSettle contracts. (Stones README)
Argent treats covenant applications as closed, well-formed state machines. The compiler is meant to track every contract that exists in an application, which entry points can lead to which successor contracts, and which transitions are actually permitted. (Argent design notes) It also generates hidden internal state to carry template references automatically, so a developer does not have to manually track every template hash and route commitment by hand. (Argent design notes)
In practice, that means writing application logic closer to statements like "player starts game" or "ticket is redeemed," while the generated Silverscript handles template propagation, output-shape checks, and reads of state from other covenant contracts. The generated Stones manifest shows this as a closed app with League, Player, StonesGame, and StonesSettle actors, each with declared entries, consumed inputs, emitted outputs, and routes. (generated Stones manifest)
The unresolved parts remain genuinely unresolved. Design notes for the project list open questions around how applications bootstrap, how launch proofs work, how the transaction-builder context should behave, how route commitments get encoded, whether same-template shortcuts are safe, exact syntax for input and output shapes, and how much validation belongs inside Argent itself before handing generated code to the Silverscript compiler. (Argent design notes)
The README is direct about what is missing: no generated transaction builder, no launch-proof tooling, no Merkle tree support for routes, no stable application binary interface, no complete typechecker, minimal diagnostics, and no security claims. (Argent README) That list should cool down any "apps are ready" take. This is compiler research, and early compiler research is where sharp edges go to breed.
One additional file in the repository, describing a token-style asset pattern, should be read with particular caution. Its first line states it is a syntax sketch only, and that the foreign covenant-reference pattern it describes does not compile yet. (ICC sketch) It signals a possible future direction rather than a working token framework today.
Sutton also made the meta point explicit. Agents helped build Silverscript and Argent, and compiler layers may help agents and humans build end-to-end applications without writing raw script-language code directly. (Sutton epilogue) That is a very Sutton-style sentence, but the underlying point is practical: if the lower layer is too sharp to use safely, build a formal layer above it.
Argent should not be read as proof that Kaspa applications are ready for general developers. The narrower and more accurate read is that, following Toccata and Silverscript, Kaspa now has public research into the next layer up: a compiler that lets a developer describe an application as a set of contracts and state transitions, then generates inspectable Silverscript underneath. If the project matures, the work for a builder shifts from manually wiring every transition by hand to designing the state machine and reviewing what the compiler generates.
Sources include Michael Sutton's public X thread, the public Argent repository, the linked Silverscript chess materials, and the Bitcoin Optech MAST reference.
