A Covenant-Native Framework for Agentic Commerce on Kaspa

Asset Standards
1

Axiom: A Covenant-Native Framework for Agentic Commerce on Kaspa

Hi everyone,

I’ve been working on Axiom, a conceptual framework exploring how autonomous agents can interact economically using Kaspa’s covenant surface.

Motivation
While most agent systems focus on orchestration and reasoning, the question that interests me is:
How can agents natively hold value, authorize actions, manage escrow, pay for services, and produce verifiable economic outcomes on-chain?

Toccata covenants now give us the primitives to explore this directly.

Core Idea
Axiom models agent interactions as sequences of atomic covenant state transitions rather than monolithic contracts.

Example reference workflow (Agentic Pay):

text

intent → auth → data → escrow → pay → settle → logs

Each transition is verifiable and builds on the previous state.

Current Structure
Primitives are grouped into layers:

  • Orchestration: intent, agents, mcp
  • Identity & Governance: auth, identity, governance
  • Data: data, oracle, logs
  • Economic Layer: pay, escrow, settle, borrow, repay, supply, treasury, compliance, compute
  • Infrastructure: kskd, custody, kurrent

Scope
Axiom is not a protocol proposal or token standard. It is a reference architecture to explore practical patterns for agent-native commerce.
Several settlement primitives have been tested with the Argent compiler.
A small reference implementation of Agentic Pay is available on GitHub.

GitHub - axiomarchitecture/axiom-agentic-pay: Reference implementation of the Agentic Pay scenario from the Axiom Manifesto — built on Argent DSL and Kaspa's covenant-native composable state. · GitHub

Open Questions
I’m particularly interested in feedback on:

  • Covenant patterns for agent-controlled treasuries
  • Compliance & permissioning frameworks
  • Compute / inference settlement
  • Alignment with emerging standards such as KCC20
  • Indexing & observability needs for agent workflows

Current draft: Axiom — The Conceptual Architecture for Intent-Native Commerce

Happy to receive criticism, suggestions, and collaboration.

6 Likes
2

Hello and welcome. For intent based interactions OpCheckSigFromStack could be the solution, if you willing to read and inform yourself about it, I’d be happy to further discuss and brainstorm.

1 Like
3

@Manyfest Thanks for the pointer. I hadn’t considered OpCheckDataSig for the intent layer specifically… makes sense as a lightweight authorization primitive before the covenant chain kicks in. Would be glad to dig into this further. How do you see it composing with multi-output covenant flows?

4

The OP is allowing users to sign over data – an intent basically (instead of a specific tx). This is handy for designing concurrent transactions or ease the burden of needing to fetch live utxos inputs.

This related to input spending auth, so I am unsure what you mean by asking about outputs

1 Like
5

Apologies, I wrote OpCheckDataSig but meant OP_CHECKSIGFROMSTACK, of course — thanks for the clarification.

That distinction helps. So the intent layer would sit at input authorization (the agent signs a structured intent object, and the covenant verifies that signature), while output constraints remain a separate concern enforced by the covenant itself. Does that match how you see it?

2 Likes
6

Relevant to the “indexing & observability needs for agent workflows” I mentioned:

@0xKnitser just shipped kascov — a covenant explorer with JSON API, indexing since Toccata activation.

This solves a real pain point for making agent flows verifiable on-chain.

2 Likes