Application language

Argent, explained.

Argent calls its building blocks actors, and they are nothing like the actors in Erlang or Akka. They have no mailboxes and no message queues. An Argent actor is a covenant object that a transaction consumes and recreates.

That distinction is the whole design. On an account chain, a contract is a thing that sits at an address and receives calls. On Kaspa there is no such thing to call. There are only outputs, and a covenant is a rule about what the next output has to look like. Argent takes that constraint seriously instead of hiding it: an application is a transaction-wide state transition over covenant UTXOs, and the compiler's job is to turn a readable description of that transition into script the network already enforces.

Michael Sutton writes it. The compiler turns .ag source into plain Silverscript contracts and a portable artifact, and a Rust runtime builds the transaction that satisfies them.

The problem it solves

Why a language had to exist

Toccata activated covenants on mainnet, which means the rules are enforceable today. It did not make them writable. A covenant is opcodes, and a useful one has to check a signature, verify the shape of its own successor, carry state forward without corrupting it, and reject every path you did not intend. Writing that by hand once is a weekend. Writing a multi-contract application that way, and then auditing it, is not something most teams will do.

So there is a gap between a primitive being live and an application being buildable, and a language is what fills it. Argent is one attempt. It is not the only possible one, and it is not officially blessed.

The model

State, actor, entry, become

Four ideas carry the language. A state is a typed record. An actor owns one. An entry is a way to spend that actor, taking arguments and declaring which actors it emits. And become names the successor the transaction creates. Read the transfer entry below and the shape is visible: check that the caller owns this ticket, check the signature, check the value carries over, then build the next state and become it.

state TicketState {
    byte[32] owner;
    int units;
}

actor Ticket owns TicketState {
    entry transfer(byte[32] next_owner, sig owner_sig, pubkey owner_pk) emits next: Ticket {
        require(blake2b(owner_pk) == owner);
        require(checkSig(owner_sig, owner_pk));
        require(next.value == self.value);

        TicketState new_state = {
            owner: next_owner,
            units: units,
        };

        become next <- Ticket(new_state);
    }
}

app Tickets {
    actor Ticket;
}

Nothing here is a call to a contract. The transaction spends the old ticket and creates the new one, and every require is a condition the script engine checks before it will let that happen. If a condition fails, the transaction is invalid. There is no revert, no gas refund, and no partially applied state, because there was never a running program to interrupt.

Composition

Making separate apps work in one transaction

Inter-Covenant Communication extends the same model across independently compiled applications, so an actor from one app can observe or authorize an actor from another inside a single atomic transaction. That is the piece that makes something like a mint controller possible: one app owns the asset rule, another owns the policy that decides when supply moves, and neither has to be recompiled into the other.

The compiler emits three things for each build: artifact.json as the portable description, manifest.json as build metadata, and ordinary .sil Silverscript contracts. Those contracts use no covenant macros and compile like any other Silverscript, which matters for review: an auditor reads generated script, not a black box. An argentc inspect command reports script and state sizes, static opcode counts, entry arguments, route metadata, and signature-script size estimates without rebuilding.

The design targets script composition primitives such as OP_CAT and OP_SUBSTR, transaction introspection, and consensus-supported covenant identities. That last one is KIP-20, which Toccata carried to mainnet.

Repository pulse

Where the code actually stands

Three repositories, one contributor. The table below is a baseline verified by hand, replaced with live data from GitHub when this page loads.

Baseline read on July 29, 2026. This table refreshes from GitHub when the page loads.

The project moved out of Michael Sutton's personal namespace into an argent-lang organisation, and the old path redirects. Sixty-four commits so far, forty-six of them in July, which is where most of his month went.

Status

How far this is from production

Argent's own README is the most useful source here, because it is more conservative than anything a reader would write on its behalf. "The project is still under active development and is not yet release-ready." A production path opens only "Once Silverscript completes its audit and is released," and even then it is described as viable for advanced users who can review the generated contracts themselves. Argent "will still need further audit and hardening before general production use."

Four concrete limits follow from that. No repository has a tagged release. Silverscript, the layer underneath, still labels itself experimental and recommends its bytecode artifact only on testnet-10. The starter template states that it does not connect to a Kaspa network, manage a wallet, or submit transactions. And one person writes all of it.

None of that makes the work less real. A compiler that emits auditable script for a live primitive is exactly what the missing middle needs. It does mean that anyone describing Argent applications as running on Kaspa mainnet today is describing something that has not happened.

One convention is already travelling ahead of its own process: the compiler ships a kcc20_asset.ag example implementing a KCC-0020 style transferable asset, whose owner can be either a public key or a covenant ID. The specification it follows is still an open pull request. Track that on the KCC side of the proposal tracker.