Hello,
I'd like to introduce a draft CIP for discussion, and to ask whether the problem it
describes is one this group considers real.
The problem. Since the CC Space API began speaking x402 on 2026-08-03, an agent can
settle per request in Canton Coin with no signup and no API key. The ledger record of
that action is indistinguishable from a person's: nothing indicates the party was
software, nothing names who is answerable for it, and nothing shows a rule was checked
before it acted. A counterparty who needs to know has to ask off ledger.
The proposal. Five optional metadata keys, carried in the records CIP-0056 already
provides. Two at party level (how a party is operated; who is accountable for it) and
three at action level (which authority policy governed an action, a digest of that
policy, and an opaque decision identifier). The digest is the load-bearing part: it lets
a counterparty confirm a policy did not silently change between two actions without the
policy's contents ever going on ledger.
What it is not. No protocol change, no Daml interface, no new package, no on-ledger
enforcement, no registry of agents, no new role for the Foundation or for Super
Validators, and no obligation on anyone to publish anything. Every key is optional and
absence carries no meaning.
Three things I am specifically unsure about, and would rather be corrected on now:
1. Whether this is already solved somewhere I have not looked. A search of the published
corpus finds no occurrences of "autonomous" or "non-human" and no use of "agent" in
the software sense. That is an absence in the published corpus under those terms and
nothing more — private work, enterprise controls, application-layer solutions, or the
same problem under different terminology would all be better outcomes than a new CIP,
and I would like to be told about them.
2. The namespace, which I have deliberately left unresolved. CIP-0056 assigns a key's
prefix on the basis of which organisation defines the key, and these keys would be
defined by a CIP rather than by any one organisation — so I do not think it is the
author's to guess. The draft writes them as / throughout and puts only
the five name segments forward as substantive. I am not proposing a vendor-controlled
prefix and do not want one: a vendor prefix would defeat a vocabulary whose only value
is that different trust domains read it the same way.
3. Whether the party-level keys belong in this CIP at all, or whether they should be
folded into the existing identity and party-metadata discussion, which is the closest
active workstream I am aware of.
Two objections I expect and cannot fully answer: voluntary disclosure will be populated
by those who least need watching, and the keys are unverifiable claims by the emitting
party. Both are true. The draft states the second in its conformance section.
Status and disclosure. Draft, Standards Track, Layer: Daml. There is no reference
implementation yet and I say so in the document; I would prefer to build one with an
implementor who actually operates one of these workflows. I am the author, at NodeAxis
AI, which is building policy-control software for autonomously operated systems and
therefore has an interest in this vocabulary existing — that is disclosed in the draft so
readers can weigh it. NodeAxis has no deployment, pilot, customer or production
implementation of anything described.
Per CIP-0000, moving past Draft needs one Super Validator to sponsor and a second to
endorse. We are not a Super Validator, so I will need both — but I understand that ask
belongs on this list at the point the draft is ready to move from Draft to Proposed, and
I am not making it yet. If the problem is real but the proposal is wrong, I would rather
hear that first.
I intend to open a pull request against the cips repository during the discussion, as
CIP-0000 describes, and I will post the link in this thread when it is up. Happy to
revise the text before or after that, whichever the editors prefer.
The full draft follows.
Thanks for reading,
Don Johnson
NodeAxis AI
hello@...
----------------------------------------------------------------------
## CIP: Authority metadata for non-human parties
CIP: TBD
Layer: Daml
Title: Authority metadata for non-human parties
Author: NodeAxis AI (Don Johnson)
Status: Draft
Type: Standards Track
Created: 2026-08-20
License: CC0-1.0
## Abstract
Software agents already settle value on Canton: since 2026-08-03 an agent can call the CC
Space API and pay per request in Canton Coin with no signup and no API key. The ledger
record of that action is indistinguishable from a person's. Nothing says the party was
software, nothing names who is answerable for it, and nothing shows that a rule was checked
before it acted.
This CIP defines five optional metadata keys in the records CIP-0056 already provides. They
let a party declare how it is operated and who is accountable for it, and let a single
action carry proof that a named, versioned authority policy was evaluated — without putting
that policy's contents on ledger. No protocol change, no Daml interface change, no new
package.
## Copyright
Licensed under CC0-1.0:
[Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
## Motivation
Canton is precise about *which party* authorized an action, and silent on what kind of
principal that party is and on whether anything was evaluated before it acted. For
human-driven applications that silence was harmless: the control sat in the operating
entity's change process. Autonomous operation removes what made it harmless — the control
that used to sit between intent and action now sits inside the software that forms the
intent. Three things become unreadable on ledger: **attribution** (did a person instruct
this, or software under standing authority, or software on its own?), **accountability**
(which entity answers for a party operated by software?), and **evidence of control** (was a
mandate or limit actually evaluated?).
**The gap is live.** The Canton Foundation's outreach channel announced on 2026-08-03 that
"CC Space API now speaks x402 … Any agent can call our API and settle per request in CC,
without signup or API key needed, with spend caps you set yourself."
([forum.canton.network/t/9033](https://forum.canton.network/t/cf-outreach-canton-network-data-just-got-directly-acce/9033))
Read as a control model, that is settlement by an unenrolled principal under a self-declared
limit.
**Why existing mechanisms do not cover it.** Party IDs identify a party, not how it is
operated. CNS entries name parties for human readability. CIP-0056 provides the carrier and
defines no keys for this. Off-ledger attestation works bilaterally and does not compose.
Application-specific controls are invisible outside the application. Value crosses trust
domains — an asset issued by one registry, allocated by one wallet and settled at a venue
passes through three — and a disclosure only one of them understands assures the other two
of nothing.
## Specification
### 1. Namespace
**The prefix is an open item, left unresolved deliberately.** CIP-0056 requires a key's
prefix to identify the organisation that defines the key; its own keys carry
`splice.lfdecentralizedtrust.org/` because they are defined as part of Splice. These keys
would be defined by a CIP rather than by Splice, so which organisation owns them is for the
editorial process to settle explicitly rather than for the author to guess. The keys are
written `/` throughout; only the five name segments are put forward as
substantive. The author does not propose a NodeAxis-controlled prefix and does not want one:
a vendor prefix would defeat a vocabulary whose only value is that different trust domains
read it the same way.
Keys follow CIP-0056 key syntax. All keys are **optional**, and absence carries no meaning —
it MUST NOT be read as a claim that a party is human-operated.
### 2. Party-level disclosure
Carried in the `meta` record of a party's CNS entry per CIP-0056, and in the `meta` field of
any interface view that surfaces it.
CNS 1.0 has no native metadata support; CIP-0056's convention is to treat the entry's
free-text `description` field as a JSON object holding a `meta` record, read back through
Scan at `/v0/ans-entries/by-party/`. This proposal adds keys to that record and
changes nothing about the encoding. A CNS entry is therefore readable by anyone who can
reach a Scan endpoint, so **everything in §2 is public by construction** — which is why no
policy content appears at party level (§6). If a future CIP adds native CNS metadata, these
keys move to it unchanged.
#### 2.1 `/actor-autonomy`
How actions attributed to this party are initiated. Value MUST be one of:
| Value | Meaning |
|---|---|
| `human` | Every action is initiated by a natural person at the time of the action. |
| `human-approved` | Software proposes; a natural person approves each action before submission. |
| `delegated` | Software initiates under a standing authority granted by a person or legal entity, without per-action approval. |
| `autonomous` | Software initiates and also determines the intent, with no standing per-action authority. |
`delegated` versus `autonomous` decides a counterparty's recourse position, and no current
field captures it.
#### 2.2 `/accountable-principal`
The entity answerable for the party's actions, as a URI. RECOMMENDED forms, in decreasing
order of preference: `party:` (an on-ledger party with its own CNS entry);
`lei:<20-character LEI>`; `https://` (a stable published statement of responsibility).
SHOULD be present whenever `actor-autonomy` is `delegated` or `autonomous`. A declaration of
autonomy with no named principal is of little use to a counterparty.
### 3. Action-level attestation
Carried in the `meta` map of choice arguments on standard workflows — the token standard's
transfer and allocation choices, for example — and echoed in choice results where the
implementation evaluates the policy itself. The goal: a third party can verify **that a
control was evaluated, which version of it, and that the same control held across a set of
actions**, without its contents being disclosed on ledger.
- **`/authority-policy-uri`** — a URI naming the authority policy that governed this action.
It MAY be non-dereferenceable by the public; it is a stable name, resolvable under whatever
bilateral or regulatory arrangement applies.
- **`/authority-policy-digest`** — a digest of the exact policy document in force at the
time of the action, as `:` (e.g. `sha256:9f86d081…`). `sha256` MUST be
supported; other algorithms MAY be used and MUST be named in the `` position.
(That is the digest algorithm label, unrelated to the key prefix of §1.) This is the
load-bearing field: it lets a counterparty confirm that the policy shown to them later is
the one that was in force, and that it did not silently change between two actions.
- **`/authority-decision-id`** — an opaque identifier, unique within the issuing system, for
the evaluation that permitted this action. It correlates the action with the issuer's own
control record for audit, and reveals nothing on its own.
### 4. Conformance
An implementation conforms if: (1) keys it emits use the syntax and value forms above;
(2) `accountable-principal` is present whenever it declares `delegated` or `autonomous`;
(3) `authority-policy-digest`, where emitted, is the digest of the policy actually evaluated
for that action; and (4) it emits neither `authority-policy-digest` nor
`authority-decision-id` for actions where no policy was evaluated.
Point 4 is the substantive obligation: an empty field is honest, a populated one
corresponding to nothing is worse than silence. These keys are claims by the emitting party,
not guarantees by the network.
### 5. What this CIP does not propose
No change to the Canton protocol, to Daml interfaces, or to any Splice package. No
on-ledger enforcement — nothing here blocks, gates or reverses an action. No registry of
agents, no identity issuance, no accreditation scheme, and no new role for the Global
Synchronizer Foundation or for Super Validators. No obligation on any party to publish
anything.
### 6. Security and privacy considerations
Every key here is an **unverified assertion by the emitting party**. The ledger does not
check them and this CIP proposes no mechanism by which it could.
- **Misattribution.** An `autonomous` party can declare itself `human` and nothing detects
it. The key makes a false declaration a specific, attributable misstatement rather than an
absence of information.
- **Naming a principal who did not agree** — the most plausible abuse. A party SHOULD NOT
name an `accountable-principal` that has not agreed. The `party:` form is RECOMMENDED
because a named on-ledger party can rebut; consumers SHOULD treat an unacknowledged
reference as weaker than an acknowledged one.
- **What a digest proves.** Only that the emitter possessed a specific document — not that it
was a policy, that it was evaluated, or that the action complied with it.
- **Guessable policies.** A digest of a templated policy — `limit: 1000 USD, counterparties:
any` — is a small search space, and an observer who guesses the template can confirm it by
comparing digests. Emitters SHOULD include a high-entropy salt in the policy document.
- **Correlation.** `authority-decision-id` MUST be opaque: a monotonic ID leaks activity
volume, and a URI like `https://example.com/policies/client-42/tier-3` discloses the
organisational structure the digest exists to protect.
- **Visibility asymmetry.** §2 keys are public to anyone with Scan access; §3 keys are
visible only to parties to the transaction. Implementors SHOULD NOT move §3 keys into a CNS
entry.
## Rationale
- **Keys rather than a Daml interface.** An interface would make disclosure structurally
enforceable, but it needs a new package and an upgrade path, so it cannot be adopted
incrementally. CIP-0056 provides for keys to be introduced by CIP, and that path is
reversible if the vocabulary proves wrong.
- **Disclosure rather than enforcement.** Enforcement would require specifying what an
acceptable control *is* — a policy question that varies by jurisdiction, instrument and
counterparty, and that no CIP should settle.
- **A digest rather than the policy.** Publishing policy content would leak limits,
counterparty lists and thresholds to everyone with visibility. A digest gives
tamper-evidence and continuity while disclosing nothing.
- **`delegated` separate from `autonomous`.** An earlier draft used one `automated` flag,
which collapsed the two cases a counterparty most needs to distinguish.
### Prior art and adjacent work
- **CIP-0056** — the mechanism this builds on. This CIP adds keys; it changes nothing in it.
- **CIP-0112** — authorization within an account or custody structure. This is the nature of
the principal invoking it. Complementary, non-overlapping.
- **Signature-binding work** (e.g. the FTP team's "verify before sign" Dev Fund proposal) —
whether what a signer approved is what their key signed. This addresses what authority the
signer held. Neither substitutes for the other.
- **Identity and party-metadata discussion on cip-discuss** — the closest active workstream.
It answers "who is this party"; this answers "what kind of principal is it, and under what
authority did it act". The author would prefer these keys folded into that work.
### Evidence of consensus
**There is none yet.** This draft is introduced to cip-discuss to find out whether the
problem is recognised by the operators and application providers who would populate the keys.
A case-insensitive search of the 113 published documents in the `cips` repository as of
2026-08-20 finds **no occurrences of "autonomous" or "non-human"**; four incidental hits for
"AI" (company names or quotations); and two for "agent", both meaning *transfer agent*. That
establishes an absence in the published corpus under those terms and nothing more. Private
work, enterprise controls, application-layer solutions, roadmap items, or the same problem
under different terminology would all be better outcomes than this CIP, and the author would
like to be told about them.
Two objections the author expects and cannot fully answer: *voluntary disclosure will be
populated by those who least need watching* (probably true — a vocabulary is a precondition
for any later requirement, not a substitute for one), and *the keys are unverifiable claims*
(true, and stated in §4).
## Backwards compatibility
None required. Every key is an optional addition to metadata maps that already exist and are
already required to tolerate unknown keys. No package, interface, protocol message or wire
format changes, so there is no upgrade sequencing. Absence carries no meaning (§1), so no
existing party is retroactively worse off.
## Reference implementation
**None exists yet.** Per CIP-0000 a reference implementation must be complete before a
Standards Track CIP reaches `Final` but is not required for acceptance. The author will build
one against whatever specification survives discussion, and would prefer to co-develop it
with an implementor who operates one of these workflows. It must contain: a validator for the
key syntax and value forms; worked examples populating the party-level keys in a CNS entry
and the action-level keys on a token standard transfer choice, with a consumer that reads
them back; a digest-continuity checker; and tests for the §4 negative cases.
## Author
Don Johnson, NodeAxis AI. NodeAxis AI is building policy-control software for autonomously
operated systems and therefore has an interest in this vocabulary existing; that is disclosed so
readers can weigh it. Nothing here is advantaged by any NodeAxis implementation: every key is
optional, the namespace is proposed as ecosystem-owned rather than vendor-owned (§1), and the
specification is CC0. NodeAxis AI has no deployment, pilot, customer or production
implementation of anything described here.
## Changelog
- 2026-08-20 — Initial draft (3,932 body words).
- 2026-08-20 — Pre-submission review against CIP-0000 and the published corpus. Preamble
corrected to observed convention (`Layer: Daml`; `Org (Person)` author form per CIP-0103).
§1 rewritten: the `splice.lfdecentralizedtrust.org/` prefix is Splice's and is now
*requested* rather than assumed. §2 states the CNS 1.0 encoding and its public visibility.
New §6 on security and privacy. Corpus search restated with its limits.
- 2026-08-20 — Readability pass. 3,932 → 2,115 body words, a 46% reduction. No change to the
specification: the keys, values, conformance rules and non-goals in §§1–6 are unchanged in
substance. Cuts fall on connective prose, duplicated statements of the same limit, and
rationale scaffolding; §3 and the Rationale were converted from prose sections to lists.
For calibration, the median document in this repository is 690 body words.
- 2026-08-20 — **Two changes on written guidance from the Canton Foundation** (Dr. Amanda L.
Martin, COO and CIP editor, replying to our pre-submission contact-information mail to
`operations@...`, 13:21Z). (1) Preamble `CIP: ?` → `CIP: TBD`: authors do not
self-assign CIP numbers, an editor assigns one during the editorial process. (2) §1 no
longer *requests* the Splice prefix — per her steer, prefix ownership is left as an explicit
open item rather than guessed, and the five keys read `/` throughout §2–§3.
No change to the name segments, their values, or any normative requirement.
- 2026-08-20 — Both editorial corrections **independently corroborated against CIP-0000**
and confirmed still in force in this file. `cip-0000.md:49` — a draft is "named with an
alias … until an editor has assigned it a CIP number (**authors must not self-assign CIP
numbers**)", which is `CIP: TBD` and this filename. `cip-0056.md:328` assigns a key prefix
to the organisation that *defines* the key, which is the question §1 now leaves open.
Length frozen at this revision by board ruling: **2,117 body words raw / 2,048 with URLs
and markdown punctuation stripped**, `## Abstract` through `## Changelog`, measured — not
estimated — by `measure-body-words.py` in this directory. No specification change.
- 2026-08-23 — Two presentational corrections against `cip-XXXX/cip-XXXX.md`, the repository's
own new-CIP template. The heading was the filename alias and is now the human title in the
template's form (`## CIP: