Skip to content
Build on Kaspa

Why actors

Silverscript handles one contract well. Real applications are not one contract.

A game has players, matches and a league. A token has an asset and a minter. Each is a separate covenant holding its own state, and a single user action has to move several of them at once, or not at all. Coordinating that by hand means writing each contract so it validates the shape of a transaction it only partly understands, then constructing that transaction so every contract’s view agrees. It is possible. It is also where the bugs live.

Argent is the layer that does it for you.

Actors

An actor is a covenant object that gets consumed and recreated by a transaction. This is the UTXO idea from the UTXO model raised to something you can program against: state does not mutate in place, so an actor’s transition is always “this actor is spent, and this successor actor is created”.

Four words carry the model:

  • state — a typed layout an actor owns.
  • actor — the covenant that owns that state.
  • entry — a callable transition. It consumes actors and emits successors.
  • become — names the successor an entry creates. This is the terminal move.
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(byte[](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;
}

Read entry transfer(...) emits next: Ticket as: this transition is callable, it will produce one successor called next, and that successor is a Ticket. The body proves the caller is the owner, constrains the successor’s value, and then commits with become.

An app groups actors that are compiled and deployed together.

Two mental models to correct

If you know Solidity: an entry is not a method on a stored object. There is no object between transactions. The entry describes a whole transaction-wide transition, and become is closer to returning the new world than to assigning a field.

If you know Bitcoin Script: you already have the consume-and-recreate instinct, and Argent will feel natural. What is new is that it holds across several covenants at once, and that routing, template commitments and witness material are generated rather than hand-built.

What Argent compiles to

Nothing exotic. Argent emits plain Silverscript, plus a portable artifact that a runtime uses to assemble transactions.

.ag source       actors, typed state, entries, become, ICC
    │
    ▼
Argent compiler
    │
    ├──▶ plain .sil contracts ──▶ Silverscript compiler
    │                                        │
    └──▶ portable artifact                   ▼
              │  artifact.json              Kaspa Script
              ▼  manifest.json              OP_CAT, OP_SUBSTR,
       argent-runtime                     introspection, KIP-20
              │
              ▼
  one atomic multi-actor Kaspa transaction

That output being ordinary readable .sil is not a detail — it is the project’s security posture. You are expected to read it.

Next