# Overview — What is OriginTrail DKG?

Give your AI agents the ultimate memory that survives the session.

<figure><img src="/files/o4wowIoHQoTEMDiPRIGT" alt="DKG v10 — 3 Memory Layers for your AI agents to work in"><figcaption><p>DKG v10 — 3 Memory Layers for your AI</p></figcaption></figure>

OriginTrail Decentralized Knowledge Graph (DKG) is an open, peer-to-peer network that provides AI agents with a **3-layered memory with built-in trust**.

Agents can:

* Write *private drafts.*
* *Share knowledge* with specific peers.
* *Anchor verified facts* on-chain.

All as structured, queryable graph data that any agent or application can read.

Unlike vendor-managed memory products that lock knowledge inside a single platform, DKG is infrastructure:

* Your agents *own their data.*
* Your nodes *run your memory.*
* Every piece of knowledge carries a *verifiable trace* of *who wrote it* and *when*.

## Why do your agents need DKG?

Every major AI lab has shipped memory for their own assistants. It works well for one user, one agent, one platform.

The moment you have multiple agents collaborating — or knowledge that needs to be trusted by someone who didn't create it — that model breaks down. There's no shared context, no provenance, no way to know if what one agent wrote is something another agent should act on.

DKG exists to fix that. It gives your agents:

* **A place to think privately** — local working memory that costs nothing and stays on your node.
* **A way to collaborate** — shared context that flows between agents and peers without touching a blockchain.
* **A trust anchor** — on-chain verification for knowledge that needs to be durable, auditable, and open to anyone.

If you're building agents that do research, coordinate with other agents, or produce knowledge that matters beyond a single session — DKG is the memory layer designed for that.

## How does DKG work?

#### Three memory layers

DKG organizes knowledge into three memory layers rather than collapsing everything into a single memory bucket. Every piece of knowledge starts private and can be promoted toward verification as it matures.

* **Working Memory** — *Private, local, free.* Your agent's scratchpad. Write drafts, ingest documents, stage knowledge before sharing it. Nothing leaves your node. No cost, no coordination overhead. This is where all knowledge starts.
* **Shared Working Memory** — *Collaborative, gossip-replicated, no charge.* Selectively share knowledge with specific peers (other agents) without publishing to a blockchain. Multiple agents can read from and write to the same Context Graph. This is where collective intelligence happens before anything needs to be verified.
* **Verifiable Memory** — ***Blockchain-anchored, cryptographically provable.*** Promote knowledge that needs to last and be trusted. Once anchored on-chain, it's immutable, queryable by anyone, and carries a provenance trace from the agent that published it. Trust level is explicit: self-attested, endorsed, partially-verified, or consensus-verified. This is where knowledge graduates from working context to ground truth.

<table><thead><tr><th width="167">Layer</th><th width="183">Scope</th><th width="79">Cost</th><th width="164">Trust</th><th>Persistence</th></tr></thead><tbody><tr><td><strong>Working Memory (WM)</strong></td><td>Private to your agent</td><td>Free</td><td>Self-attested</td><td>Local, survives restarts</td></tr><tr><td><strong>Shared Working Memory (SWM)</strong></td><td>Visible to context-graph peers</td><td>Free</td><td>Self-attested, gossip-replicated</td><td>TTL-bounded</td></tr><tr><td><strong>Verifiable Memory (VM)</strong></td><td>Permanent, on-chain</td><td>TRAC</td><td>Self-attested → endorsed → consensus-verified</td><td>Permanent</td></tr></tbody></table>

Agents can therefore collaborate before finality, and humans can decide when knowledge deserves the cost and permanence of publication.

```mermaid
flowchart LR
  A["Agent drafts a finding"] --> WM["Working Memory<br/>private"]
  WM --> SWM["Shared Working Memory<br/>peer-visible"]
  SWM --> VM["Verifiable Memory<br/>on-chain"]
```

> ## Documentation Index
>
> Agents can start from [`llms.txt`](https://github.com/OriginTrail/dkg/blob/main/llms.txt) for the compact docs index, or [`llms-full.txt`](https://github.com/OriginTrail/dkg/blob/main/llms-full.txt) for the expanded context pack.

#### The DKG node

A DKG node is the local gateway into the DKG network. It lets agents and applications write private working memory, share selected knowledge with peers, and finalize durable records on-chain as Knowledge Assets.

You run a node to participate in the network. For most builders, this means running an Edge Node — a lightweight client optimized for application integration. Core Nodes are the infrastructure layer that stakes TRAC and supports the broader network.

## What can you do with DKG?

<table><thead><tr><th width="315">Workflow</th><th>Typical action</th><th width="167">Memory layer</th></tr></thead><tbody><tr><td>Capture notes, imports, findings, or agent state</td><td>Create a Knowledge Asset and write triples locally.</td><td>Working Memory</td></tr><tr><td>Share selected knowledge with teammates or peer nodes</td><td>Share a Knowledge Asset or subscribe peers to a Context Graph.</td><td>Shared Working Memory</td></tr><tr><td>Create durable, verifiable graph records</td><td>Publish selected shared memory as Knowledge Assets.</td><td>Verifiable Memory</td></tr><tr><td>Connect agent frameworks</td><td>Use MCP, Hermes, OpenClaw, CLI, or HTTP API.</td><td>Node gateway</td></tr><tr><td>Govern publication authority</td><td>Use curated Context Graphs and Publishing Conviction Accounts.</td><td>Context Graph policy and PCA</td></tr></tbody></table>

### Ideas to get you started

* **Research agents that build on each other's work:** An agent ingests sources into Working Memory, distills findings into Shared Working Memory for teammates or other agents to query, and promotes validated conclusions to Verifiable Memory as a citable knowledge artifact. → *All three memory layers*
* **Multi-agent task coordination:** Multiple agents working on a long-horizon task share a Context Graph in Shared Working Memory. Each agent reads the latest state written by others, avoiding duplicate work and conflicting outputs. → *Shared Working Memory*
* **Auditable AI decision traces:** An agent publishes its reasoning steps and decisions as Knowledge Assets anchored on-chain. Any downstream system — or human auditor — can query what the agent concluded, when, and from what sources. → *Verifiable Memory*
* **Personal knowledge bases that agents can query:** Ingest documents, notes, and structured data into Working Memory on your node. Your agents query it via SPARQL — structured, precise retrieval rather than fuzzy vector search. → *Working Memory*
* **Cross-team knowledge sharing without a central platform:** Teams share a Context Graph in Shared Working Memory. When knowledge is ready to be trusted beyond the team, it gets promoted to Verifiable Memory — no central database, no single point of failure. → *Shared Working Memory → Verifiable Memory*

## Next steps

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4>▷ Quickstart</h4></td><td>Connect your AI agent to the DKG</td><td><a href="/pages/Qs556DgDgUAcXKlD3Chj">/pages/Qs556DgDgUAcXKlD3Chj</a></td></tr><tr><td><h4>⚙︎ How does it work?</h4></td><td>Understand the DKG architecture &#x26; concepts</td><td><a href="/pages/fO3ZrLH6mexorlu8wJk6">/pages/fO3ZrLH6mexorlu8wJk6</a></td></tr><tr><td><h4>$ Apply for the DKG v10 bounty</h4></td><td>Build a DKG v10 integration and compete for $TRAC 150,000</td><td><a href="/pages/iv4Etrnk0OBn4rSVVkJW">/pages/iv4Etrnk0OBn4rSVVkJW</a></td></tr></tbody></table>


# Quickstart

Give your AI agent a persistent and structured memory on the DKG in under 10 minutes

By connecting your AI agent to the DKG Node, you give it three layers of persistent and structured memory on the DKG:

* **Working Memory** — *Private, local, free.* Your agent's scratchpad. Write drafts, ingest documents, stage knowledge before sharing it. Nothing leaves your node. No cost, no coordination overhead. This is where all knowledge starts.
* **Shared Working Memory** — *Collaborative, gossip-replicated, no charge.* Selectively share knowledge with specific peers (other agents) without publishing to a blockchain. Multiple agents can read from and write to the same Context Graph. This is where collective intelligence happens before anything needs to be verified.
* **Verifiable Memory** — *Blockchain-anchored, cryptographically provable.* Promote knowledge that needs to last and be trusted. Once anchored on-chain, it's immutable, queryable by anyone, and carries a provenance trace from the agent that published it. Trust level is explicit: self-attested, endorsed, partially-verified, or consensus-verified. This is where knowledge graduates from "our working context" to "ground truth."

To better understand how DKG works, explore [here](/how-dkg-works/key-concepts).

## Prerequisites

Node.js 22+, npm 10+. macOS, Linux, and Windows (PowerShell 5.1+ or WSL2) all supported.

## Hermes

Install the DKG CLI and set up the default Hermes profile:

```bash
npm install -g @origintrail-official/dkg
dkg hermes setup
```

Enable Hermes' API server and start the gateway:

```bash
echo 'API_SERVER_ENABLED=true' >> ~/.hermes/.env
hermes gateway run --replace -v
```

`dkg hermes setup` bootstraps the DKG node config (no separate `dkg init` needed), starts the daemon, optionally funds wallets, and wires the Hermes profile with replace-by-default provider election (use `--preserve-provider` to opt out, `--no-start` / `--no-fund` for advanced flows).

By default this sets up the node on **Gnosis mainnet** (`mainnet-gnosis`). On a fresh node, pass `--network mainnet-base` or `--network testnet` to choose a different network (an already-configured node keeps its current network — switch it with `dkg init --network`). Wallet funding via the faucet only happens on `testnet`; on mainnet you fund the node's wallets yourself.

See the [adapter guide](https://github.com/OriginTrail/dkg/blob/main/packages/adapter-hermes/README.md) for details.

## OpenClaw

```bash
npm install -g @origintrail-official/dkg     # installs CLI + bundled adapter
dkg openclaw setup                           # configures + starts the daemon, registers the plugin
```

Restart the OpenClaw gateway if it does not auto-reload:

```
openclaw gateway restart
```

`dkg openclaw setup` is non-interactive and idempotent. It writes `~/.dkg/config.json`, merges the adapter into `~/.openclaw/openclaw.json` (under `plugins.entries.adapter-openclaw.config` — `daemonUrl`, `memory.enabled`, `channel.enabled`), syncs the canonical DKG node skill into the OpenClaw workspace at `skills/dkg-node/SKILL.md`, and verifies the install. The right-panel "Connect OpenClaw" button in the node UI runs the same in-process flow.

Use `--no-start`, `--no-fund`, and `--no-verify` only when the user or environment requires it.

By default this sets up the node on **Gnosis mainnet** (`mainnet-gnosis`). On a fresh node, pass `--network mainnet-base` or `--network testnet` to choose a different network (an already-configured node keeps its current network — switch it with `dkg init --network`). Wallet funding via the faucet only happens on `testnet`; on mainnet you fund the node's wallets yourself.

## MCP

Two commands wire DKG V10 into MCP-aware clients (Cursor, Claude Code, Claude Desktop, Windsurf, VSCode + GitHub Copilot Chat, Cline, Codex CLI):

```bash
npm install -g @origintrail-official/dkg
dkg mcp setup
```

Restart the client and inspect DKG tools.

`dkg mcp setup` bootstraps the DKG node config (no separate `dkg init` needed), starts the daemon, optionally funds wallets, and registers MCP entries in each detected client (you confirm per client unless `--yes` is passed).

By default this sets up the node on **Gnosis mainnet** (`mainnet-gnosis`). On a fresh node, pass `--network mainnet-base` or `--network testnet` to choose a different network (an already-configured node keeps its current network — switch it with `dkg init --network`). Wallet funding via the faucet only happens on `testnet`; on mainnet you fund the node's wallets yourself.

See the [MCP integration guide](https://github.com/OriginTrail/dkg/blob/main/packages/mcp-dkg/README.md) for client-by-client paths, mode overrides (`--installed` / `--monorepo`), the manual JSON shape, the contributor monorepo dev workflow, and troubleshooting (including the WSL2 caveat for Windows-side MCP clients).

## Standalone node

Skip the framework wiring — run the daemon directly and use the CLI or HTTP API:

```bash
npm install -g @origintrail-official/dkg
dkg init      # interactive: prompts for network, node name, role, triple-store backend (default: oxigraph-server), relay, API port
dkg start     # starts the node daemon on http://127.0.0.1:9200
```

`dkg init` asks which network to join — **Gnosis mainnet** (`mainnet-gnosis`, the default), `mainnet-base`, or `testnet` — at the prompt, or pass `--network <name>` to skip it. Wallet funding via the faucet only happens on `testnet`; on mainnet you fund the node's wallets yourself.

For Core Node operation, initialize with the Core role:

```bash
dkg init --role core --network mainnet-gnosis
dkg start
```

Core Nodes are registered on-chain with a node profile (`identityId`). The daemon attempts this automatically on Core startup, but the primary operational wallet needs gas plus TRAC and the admin wallet must be present for profile/key-management transactions. If you fund or fix wallets after the daemon is already running, call `POST /api/identity/ensure` as described in [Daemon Lifecycle](/use-dkg/run-node#core-node-profile-registration).

Once running, open the dashboard at <http://127.0.0.1:9200/ui>, or query directly:

```bash
TOKEN=$(dkg auth show)
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:9200/api/agents
```


# Terms & Conditions

### Preamble

The OriginTrail Decentralized Knowledge Graph Version 10 (hereinafter referred to as "**OriginTrail V10**" or "**V10**") is a neutral, peer-to-peer, multi-chain network designed to facilitate decentralized knowledge publishing, verification, and retrieval by human and autonomous software agents. OriginTrail V10 consists of open-source Core Nodes and Edge Nodes implementation, a three-layer Memory Model (Working Memory, Shared Working Memory, Verifiable Memory), and on-chain primitives (Knowledge Assets, Knowledge Collections, Context Graphs, Verified Graphs, Publisher Conviction Accounts, and Staker Conviction Positions) deployed across multiple EVM-compatible blockchains.

OriginTrail V10 is developed by **OriginTrail d.o.o.**, a company organized and established under the laws of Slovenia (hereinafter referred to as "**OriginTrail**").

The OriginTrail V10 Node software is licensed under the Apache License, version 2.0. You may obtain a copy of the License at <http://www.apache.org/licenses/LICENSE-2.0>.

**PLEASE READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE INSTALLING, OPERATING, OR OTHERWISE USING ANY OriginTrail V10 NODE, AGENT, OR RELATED ON-CHAIN SOFTWARE. BY DOWNLOADING, INSTALLING, OPERATING, PUBLISHING TO, QUERYING, OR OTHERWISE INTERACTING WITH THE OriginTrail V10 NETWORK, OR BY MINTING, ACQUIRING, HOLDING, OR TRANSFERRING ANY V10 NFT POSITION, YOU ACKNOWLEDGE THAT YOU HAVE READ, UNDERSTOOD, AND AGREE TO BE BOUND BY THESE TERMS AND CONDITIONS AND ALL TERMS INCORPORATED BY REFERENCE. IF YOU DO NOT AGREE, DO NOT USE THE OriginTrail V10 NETWORK.**

***

### 1. Definitions

For the purpose of these Terms and Conditions, the following capitalised terms shall have the meanings set out below. Singular terms include the plural and vice versa.

**AGENT** means an autonomous software program or human-operated account that participates in the OriginTrail V10 network by publishing, querying, endorsing, or verifying Knowledge Assets under a cryptographic keypair.

**APACHE LICENSE** means the Apache License, version 2.0, available at <http://www.apache.org/licenses/LICENSE-2.0>.

**CONTEXT GRAPH** or "**CG**" means a bounded knowledge space within the OriginTrail V10 network in which a single Agent or a group of Agents collaborate.

**CONTRIBUTION** means any work of authorship, including modifications to or additions to the OriginTrail V10 Node source code, technical documentation, or related software, submitted by You to the Licensor for inclusion in the OriginTrail V10 Node.

**DECENTRALIZED KNOWLEDGE GRAPH** or "**DKG**" means the shared, decentralized, multi-chain knowledge graph hosted by the OriginTrail V10 network, consisting of Knowledge Assets organized into Context Graphs.

**DERIVATIVE WORK** means any work, whether in Source Form or Object Form, that is based on, derived from, or incorporates the OriginTrail V10 Node or any portion thereof, as defined under the Apache License.

**KNOWLEDGE ASSET** or "**KA**" means the on-chain representation of a set of RDF triples sharing a single root subject URI, anchored on a supported blockchain. Each Knowledge Asset is an ERC-1155 token; the token holder controls UPDATE authority over that KA.

**LICENSE** means the Apache License, version 2.0, together with these Terms and Conditions.

**LICENSOR** means OriginTrail, digitalne rešitve za dobavne verige, d.o.o.

**MAINNET** means the production OriginTrail V10 network deployed across the Supported Blockchains.

**MEMORY** **MODEL** means the three-layer data organisation of the OriginTrail V10 network: (i) Working Memory - local, private, free; (ii) Shared Working Memory - gossip-replicated among selected peers; (iii) Verifiable Memory - blockchain-anchored, requires on-chain publishing, with a trust gradient from self-attested to consensus-verified.

**NODE** or "**OriginTrail V10 NODE**" means a client program that participates in the OriginTrail V10 network by hosting Agents, replicating data, serving queries, and - where applicable - submitting blockchain transactions. "Node" includes both Core Nodes (infrastructure that stakes TRAC and supports the network infrastructure) and Edge Nodes (client-side nodes for end-user and application integration).

**OBJECT FORM** means any non-Source-Form expression of the Work, as defined in the Apache License.

**OriginTrail V10** has the meaning given in the Preamble.

**PUBLISHER** means any Person (human or automated) that, acting directly or through one or more Agents, triggers a PUBLISH, UPDATE, or VERIFY operation that anchors data on DKG.

**PUBLISHER CONVICTION NFT** means an ERC-721 position representing a commitment of TRAC by a Publisher for a fixed twelve (12) month term in exchange for a pre-purchased publishing allowance and - where applicable - a discount tier, as further described in Section 7 and in the Technical Documentation.

**SOURCE CODE** means a set of instructions and statements written by a programmer using computer programming, representing a computer program.

**SOURCE FORM** means the preferred form for making modifications, including software source code, documentation, and configuration files.

**STAKER** means any Person that locks TRAC into a Staker Conviction Position, whether directly operating a Node or delegating capital to the netwo

**STAKER CONVICTION NFT** means an ERC-721 position representing a network-level lock of TRAC for a chosen duration in exchange for a reward multiplier, as further described in Section 7 and in the Technical Documentation.

**SUPPORTED BLOCKCHAIN** means any EVM-compatible blockchain on which OriginTrail V10 smart contracts are deployed by OriginTrail or its authorized contributors and recognised by the network, including, as of the effective date of these Terms and Conditions, NeuroWeb, Base, and Gnosis. The list of Supported Chains may be updated from time to time.

**TECHNICAL DOCUMENTATION** means all documentation published by OriginTrail in reference to the operation of the OriginTrail V10 network, available at <https://docs.origintrail.io> and on GitHub at <https://github.com/OriginTrail>, including without limitation the V10 Protocol Core specification and the V10 Token Economics specification.

**TERMS AND CONDITIONS** or "**TERMS**" means these terms and conditions, and all terms incorporated by reference, governing the installation, operation, and use of OriginTrail V10.

**TESTNET** means any test network that emulates the operation of a Mainnet, used for testing and development. Testnets have no incentivization mechanisms and therefore cannot support the economic properties of the OriginTrail V10 Mainnet.

**TRAC** means the utility token of the OriginTrail network, used to pay for on-chain publication, updates, verification quorum submissions, and to secure the network through staking.

**US / WE / OUR** means the Licensor.

**USDC** means the USD-denominated stablecoin issued by Circle Internet Financial, LLC (or its successor issuer), referenced here solely as one example of a non-TRAC settlement asset that may be used for knowledge commerce payments.

**VERIFIED GRAPH** means a named verification scope within a Context Graph, with its own participant list and M-of-N quorum, represented on blockchain as an ERC-721 token.

**WORK** means the work of authorship, whether in Source Form or Object Form, made available under the License. For the purpose of these Terms and Conditions, "Work" refers to OriginTrail V10.

**x402** means the HTTP 402 Payment Required extension enabling per-query micropayments between Agents, as described in the Technical Documentation.

**YOU** or "**YOUR**" means the natural or legal entity exercising permissions granted under these Terms and Conditions, whether acting directly or through one or more Agents, Nodes, or wallets.

***

### 2. Acceptance and Eligibility

2.1 By downloading, installing, operating, publishing to, querying, endorsing, verifying, minting, acquiring, holding, or transferring any component of, or position within, the OriginTrail V10 network, You acknowledge that You have read, understood, and agree to be bound by these Terms and Conditions.

2.2 You represent and warrant that:

(a) You have, at the time You first interact with OriginTrail V10, reached the age of majority in Your jurisdiction of residence, and in any event are not less than eighteen (18) years old;

(b) Your use of OriginTrail V10 complies with the laws of Your jurisdiction of residence and any other jurisdiction from which You access or operate on the network, and You are fully able and legally competent to use OriginTrail V10;

(c) You have sufficient understanding of blockchain technology, cryptographic keys, smart contracts, multi-chain operation, volatile crypto-asset markets, and the technical and economic risks associated with participating in a decentralized network, to make an informed decision to use OriginTrail V10;

(d) You are not located in, organised under the laws of, or ordinarily resident in any jurisdiction that is the target of comprehensive economic sanctions administered by the United Nations, the European Union, the United Kingdom, or the United States (including, without limitation, the Office of Foreign Assets Control), nor are You a person or entity designated on any consolidated sanctions list;

(e) You are not using OriginTrail V10 to finance, facilitate, or conceal any illegal activity, including, without limitation, money laundering, terrorist financing, tax evasion, market manipulation, or unauthorised trading in regulated instruments;

(f) You are solely responsible for determining whether Your participation in OriginTrail V10 - including the acquisition, holding, transfer, or lock-up of TRAC, Knowledge Assets, Publisher Conviction Accounts, or Staker Conviction Positions - requires authorisation, registration, licensing, or disclosure under the laws applicable to You, and You have satisfied all such requirements.

2.3 You are solely responsible for ensuring the truthfulness and lawfulness of any information You provide or publish to the OriginTrail V10 network, including any content contained in Knowledge Assets You author, endorse, or verify.

***

### 3. OriginTrail V10 Node License

3.1 Apache License version 2.0. The OriginTrail V10 Node software is licensed under the Apache License, Version 2.0, the full text of which is incorporated into these Terms and Conditions by reference as if set out in full herein. All copyright, patent, redistribution, and trademark provisions of the Apache License, Version 2.0 apply.

3.2 Trademarks. The use of OriginTrail trademarks, service marks, trade names, and product names is forbidden, except as strictly required for use in describing the origin of the OriginTrail V10 Node and Derivative Works. Nothing in these Terms and Conditions grants You the right to use OriginTrail trademarks.

***

### 4. Contributions

4.1 Unless You explicitly state otherwise, any Contribution submitted for inclusion in the OriginTrail V10 Node Source Code by You to the Licensor shall be under these Terms and Conditions, without any additional terms or conditions. Notwithstanding the foregoing, nothing herein supersedes or modifies the terms of any separate license agreement You may have executed with the Licensor regarding such Contributions.

4.2 By submitting a Contribution, You:

(a) Grant to the Licensor a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, transform, modify or adapt, publicly display, publicly perform, sublicense, and distribute the Contribution or its Derivative Works in Source Form or Object Form;

(b) Grant to the Licensor a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in section 3 of the Apache License, version 2.0) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Contribution;

(c) Represent that You have the right to grant the licenses set out above and that the Contribution does not infringe the intellectual property rights of any third party.

***

### 5. Nature of the Network - No OriginTrail Control

5.1 OriginTrail developed the OriginTrail V10 Node software, licensed under the Apache License 2.0, and may promote it as an open-source network. **HOWEVER, YOU SHALL AT ALL TIMES NOTE THAT ORIGINTRAIL DOES NOT OWN OR CONTROL THE OriginTrail V10 NETWORK, THE DECENTRALIZED KNOWLEDGE GRAPH, ANY SUPPORTED CHAIN, OR ANY RELATED SOFTWARE OR ANY OTHER MODIFICATION TO IT, AND YOU ARE SOLELY AND IN FULL RESPONSIBLE FOR YOUR USE OF EACH AND ANY OF THEM.**

5.2 You acknowledge and agree that:

(a) OriginTrail does not own, operate, or control any Node, Agent, Context Graph, Verified Graph, Knowledge Asset, Publisher Conviction Account, Staker Conviction Position, or wallet, except any infrastructure OriginTrail itself chooses to operate in its capacity as one participant among many;

(b) OriginTrail does not have any authority to approve, prevent, restrict, censor, reverse, or otherwise exercise control over any transaction, publication, endorsement, verification, update, deletion, or any other interaction that occurs through OriginTrail V10 or any Supported Chain;

(c) You shall not have any expectation as to the performance of the OriginTrail V10 network, the uptime or behaviour of any individual Node, or the compensation paid to any Publisher, Staker, Node operator, or Agent;

(d) Where OriginTrail or its affiliates publish opinions, roadmaps, forecasts, or community communications, such materials are provided for informational purposes only, do not create a contractual obligation, and may be changed or withdrawn at any time.

***

### 6. Node Operation

6.1 You are responsible for the installation, configuration, security, maintenance, and operation of any Node You run, including keeping the Node software reasonably up to date with published releases at <https://github.com/OriginTrail> and ensuring the secure custody of all associated private keys.

6.2 To operate a Core Node, You must satisfy the minimum technical and economic requirements described in the Technical Documentation. Failure to meet these requirements may, pursuant to protocol-level rules enforced by other participants and smart contracts, result in reduced reputation, reduced allocation of publishing work, or inability to participate in certain operations. OriginTrail does not operate any discretionary disciplinary process - any consequences are the result of protocol rules and the independent behaviour of other network participants.

6.3 You acknowledge that the OriginTrail V10 Node Source Code has not necessarily passed a third-party security audit and can be potentially unstable and could cause unexpected effects and system failures. You are solely responsible for determining the appropriateness of using or redistributing the OriginTrail V10 Node Source Code or any Derivative Work.

6.4 You are solely responsible for regularly checking for any modifications and updates to the OriginTrail V10 Node Source Code published at <https://github.com/OriginTrail>.

6.5 You are solely responsible for keeping Your private keys, mnemonics, and Node operational credentials safe. **OriginTrail does not have, and will not have, the ability to help You recover any lost private key, any lost keypair controlling an Agent, any Knowledge Asset ERC-1155 token balance stranded at a lost address, or any funds, NFTs, or allowance held at such an address.**

***

### 7. TRAC, Conviction Positions, and Token Economics

7.1 **Utility character of TRAC.** TRAC is a cryptographic utility token the primary function of which is to enable and meter on-chain operations in the OriginTrail V10 network (in particular, the PUBLISH, UPDATE, and VERIFY operations of the Memory Model) and to secure the network through staking. TRAC is not offered, and must not be relied upon, as an investment product, a savings instrument, a deposit, a unit in a collective investment scheme, or a security of any kind.

7.2 **Publisher Conviction.** Publishers may commit TRAC to a Publisher Conviction account for a fixed term in exchange for a pre-purchased publishing allowance, subject to the discount tiers described in the Technical Documentation.

7.3 **Delegated Staker Conviction.** Stakers may lock TRAC into a Staker Conviction Position for a chosen duration in exchange for a reward multiplier, subject to the multiplier schedule described in the Technical Documentation.

7.4 **Programmatic Rewards.** Rewards paid to Stakers, distributions of unused Publisher Conviction allowance, and any other token flows described in the Technical Documentation are programmatic transfers executed by on-chain smart contracts. They are not amounts "owed" by OriginTrail and are not payable by OriginTrail in any capacity. OriginTrail does not itself distribute, guarantee, or underwrite any such transfer.

7.5 **Gas and operational costs.** In addition to TRAC, every blockchain transaction on a Supported Chain requires the payment of gas in that blockchain's native gas token (including, where applicable, NEURO on NeuroWeb, ETH on Base, and xDAI on Gnosis). You are solely responsible for obtaining and managing such gas tokens.

7.6 **Knowledge commerce and x402.** You acknowledge that, in addition to protocol-level TRAC payments, the OriginTrail V10 network supports knowledge commerce via x402 HTTP micropayments and - in later protocol releases - FairSwap on-chain escrow, settling in TRAC, USDC, or other tokens configured by the serving Node or Publisher. OriginTrail does not operate any x402 or FairSwap endpoint on Your behalf, does not guarantee the availability, performance, or pricing of such endpoints, and is not a party to any commercial transaction concluded between You and any other Agent, Publisher, or Node operator via such mechanisms.

7.7 **Not a security; no investment solicitation**. You acknowledge and agree that:

(a) Neither TRAC, nor Publisher Conviction Accounts, nor Staker Conviction Positions, nor Knowledge Assets, nor Context Graph or Verified Graph tokens, are offered or intended as securities, investment contracts, collective investment schemes, units in a fund, derivatives, or any other form of regulated financial instrument;

(b) You are not acquiring or holding any such asset with an expectation of profit derived from the entrepreneurial or managerial efforts of OriginTrail or any third party acting on OriginTrail's behalf;

(c) Any statements made by OriginTrail in the Technical Documentation, roadmaps, or elsewhere regarding network design, conviction mechanisms, discount curves, reward multipliers, or market dynamics are informational and architectural in nature, and are not offers, promises, guarantees, or forecasts of financial return;

(d) Where the laws of Your jurisdiction would, notwithstanding the foregoing, characterise any component of the OriginTrail V10 network as a regulated instrument, You are solely responsible for complying with all such laws, including securities, commodities, crypto-asset (including, where applicable, the EU Markets in Crypto-Assets regime), anti-money-laundering, tax, and consumer-protection laws.

***

### 8. Agents and Keys

8.1 You may operate one or more Agents. Each Agent is identified by a cryptographic keypair that You (or the automated system operating on Your behalf) generate and control. Agent creation is free at the protocol level and does not require registration with OriginTrail.

8.2 You are solely responsible for:

(a) The generation, storage, rotation, and protection of each Agent's private key;

(b) Any and all operations signed by any Agent under Your control;

(c) The conduct of any automated or "agentic" software operating under Your authority, including the content it publishes, the commitments it makes, the TRAC or other tokens it spends, and the wallets it signs for. **The autonomous or probabilistic character of an Agent is not a defence and does not shift responsibility to OriginTrail or to any other participant.**

8.3 If a key controlling an Agent is lost, compromised, or stolen, the current protocol does not provide social or off-chain recovery. You acknowledge that in such a case, You may permanently lose authority over Knowledge Assets or any other assets held at that Agent's address.

***

### 9. Content Responsibility

9.1 All data that You, Your Agents, or Nodes under Your control publish, endorse, or verify on the OriginTrail V10 network is published by You on Your own authority. You warrant that any such data:

(a) Does not infringe any copyright, trademark, trade secret, patent, publicity, privacy, or other intellectual property or personal right of any third party;

(b) Does not contain unlawful, defamatory, deceptive, or misleading content;

(c) Is, to the extent it contains personal data, processed by You in compliance with all applicable data protection laws (including, where applicable, the EU General Data Protection Regulation); and

(d) May be replicated, stored, and served by other Nodes on the network in accordance with protocol rules, and - in the case of Verifiable Memory - may be anchored permanently on one or more Supported Chains in a manner that You accept is technically impossible to reverse.

9.2 **Once knowledge is published to Verifiable Memory, its merkle root is anchored on blockchain and the underlying triples are replicated across Nodes within the relevant Context Graph. UPDATE operations replace the root, but You acknowledge that historical roots, and copies of the underlying data that may have been retained by third-party Nodes, cannot be guaranteed to be erased. You must take this into account when deciding whether to publish any given data.**

***

### 10. Risk Disclosures

YOU EXPRESSLY ACKNOWLEDGE AND ACCEPT THE FOLLOWING RISKS:

10.1 **Technology risk.** The OriginTrail V10 Node Source Code, Agents, smart contracts, and protocol specifications are complex software. They may contain undiscovered defects, vulnerabilities, or bugs that could lead to loss of TRAC, Knowledge Assets, Conviction positions, or other value.

10.2 **Multi-chain risk.** OriginTrail V10 operates across multiple Supported Chains, including NeuroWeb, Base, and Gnosis. Each Supported Chain is an independent system operated by independent actors and validators, outside the control of OriginTrail. Any Supported Chain may experience outages, forks, consensus failures, re-organisations, governance disputes, regulatory action, or termination. OriginTrail makes no representation as to the availability, finality, or security of any Supported Chain, and You accept that Your assets or positions on any given Supported Chain may be adversely affected by events specific to that blockchain.

10.3 **Cross-chain risk.** Operations that rely on state, tokens, or messages bridged between Supported Chains introduce bridge-specific risks, including smart-contract exploits, validator misbehaviour, loss of canonicality, and temporary or permanent loss of assets in transit. You are solely responsible for evaluating and bearing such risks.

10.4 **Lock-up risk.** TRAC committed to a Publisher Conviction Account or a Staker Conviction Position is locked for a specific duration. During these lock periods, You cannot withdraw the locked tokens. Any secondary-market transfers of the NFT are neither guaranteed nor underwritten.

10.5 **Reward volatility and conditionality**. Staker rewards, Publisher allowance utilisation, and any other programmatic transfers are determined by network activity, gas conditions, and smart-contract execution. Rewards may decrease, pause, or cease altogether. No minimum, guaranteed, or target return is promised by OriginTrail.

10.6 **Stablecoin and payment-rail risk.** x402 micropayments and FairSwap escrow may settle in USDC or other non-TRAC tokens. Such tokens are issued, operated, or controlled by third parties and carry their own risks (including, without limitation, issuer risk, banking risk, peg failure, freezes, blocklists, and regulatory action). OriginTrail does not issue, endorse, or guarantee any such token.

10.7 **Regulatory risk.** The regulatory treatment of crypto-assets, decentralized networks, autonomous software agents, and related activities is evolving worldwide and varies between jurisdictions. Actions or determinations by regulators, courts, or legislatures may adversely affect the availability or value of OriginTrail V10, TRAC, Conviction NFTs, Knowledge Assets, or other positions. You are solely responsible for monitoring and complying with such developments in every jurisdiction relevant to You.

10.8 **Tax risk.** You are solely responsible for determining any tax consequences of Your participation in OriginTrail V10, including in connection with minting, holding, transferring, or selling any Conviction NFT or Knowledge Asset, receiving any programmatic emission, paying or receiving x402 or FairSwap settlements, or operating a Node, and for filing and paying any taxes and duties due.

10.9 **Testnet risk.** Testnets have no incentivization mechanisms and therefore cannot support the economic value propositions of OriginTrail V10 Mainnet. Testnet state, balances, NFTs, and histories may be reset, abandoned, or otherwise destroyed at any time without notice.

***

### 11. Disclaimer of Warranties

11.1 UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, THE OriginTrail V10 NODE, THE DECENTRALIZED KNOWLEDGE GRAPH, THE OriginTrail V10 NETWORK, ANY SUPPORTED CHAIN, AND ANY RELATED SOFTWARE ARE PROVIDED ON AN "AS IS" AND "AS AVAILABLE" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, RELIABILITY, SECURITY, UPTIME, OR NON-INTERRUPTION.

11.2 THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF USING OriginTrail V10 IS BORNE BY YOU. You are solely responsible for determining the appropriateness of using or redistributing the OriginTrail V10 Node Source Code, any Derivative Work, or any Knowledge Asset, and assume any risks associated with Your exercise of permissions granted under this License.

***

### 12. Limitation of Liability

12.1 IN NO EVENT AND UNDER NO LEGAL THEORY, UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, SHALL OriginTrail, OR ANY OTHER CONTRIBUTOR WHO MODIFIES AND/OR CONVEYS THE OriginTrail V10 NODE AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY DIRECT, INDIRECT, SPECIAL, GENERAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY CHARACTER ARISING AS A RESULT OF THIS LICENSE OR OUT OF THE USE OR INABILITY TO USE THE OriginTrail V10 NODE OR THE OriginTrail V10 NETWORK (INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR DATA BEING RENDERED INACCURATE, LOSS OF TRAC, NFTS, OR OTHER CRYPTO-ASSETS, LOSSES SUSTAINED BY YOU OR THIRD PARTIES, FAILURE OF ANY SUPPORTED CHAIN, FAILURE OR MALFUNCTION OF ANY AGENT, LOSS OF GOODWILL, WORK STOPPAGE, BUSINESS INTERRUPTION, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR LOSSES), EVEN IF OriginTrail OR ANY OTHER CONTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

***

### 13. Indemnification

13.1 To the maximum extent permitted by applicable law, You agree to indemnify, defend, and hold harmless OriginTrail, its affiliates, and their respective directors, officers, employees, and contributors from and against any and all claims, damages, losses, liabilities, costs, and expenses (including reasonable legal fees) arising out of or related to: (a) Your use of OriginTrail V10; (b) Your violation of these Terms and Conditions; (c) Your violation of any applicable law or of any right of a third party; (d) any content or data You publish to, or cause to be published to, the OriginTrail V10 network; or (e) the operation of any Agent, Node, or wallet under Your control.

***

### 14. Governing Law and Dispute Resolution

14.1 These Terms and Conditions, and Your use of the OriginTrail V10 Node and the OriginTrail V10 network, shall be governed by and construed in accordance with the laws of Slovenia, excluding its conflict-of-laws principles.

14.2 In the event of any dispute arising out of or in connection with these Terms and Conditions or Your use of the OriginTrail V10 Node, the competent Court in Ljubljana, Slovenia shall have exclusive jurisdiction to resolve the dispute.

14.3 If any term, clause, or provision of these Terms and Conditions, or any terms incorporated by reference herein, is held unlawful, void, or unenforceable, then that term, clause, or provision shall be severable from these Terms and Conditions and shall not affect the validity or enforceability of any remaining part of that term, clause, or provision, or any other term, clause, or provision of these Terms and Conditions.

***

### 15. Changes to these Terms

15.1 OriginTrail reserves the right to revise these Terms and Conditions, or any terms incorporated by reference herein, at any time, without prior notice. By continuing to use the OriginTrail V10 network after any such revision takes effect, You acknowledge and agree to be bound by the Terms and Conditions in force at the time of Your use.

15.2 You are solely responsible for regularly checking for any revisions or amendments to these Terms and Conditions at the official repository and on <https://docs.origintrail.io>.

***

### 16. Apache License Notice

Licensed under the Apache License, Version 2.0 (the "Apache License"); You may not use this file except in compliance with the Apache License. You may obtain a copy of the Apache License at <http://www.apache.org/licenses/LICENSE-2.0>. Unless required by applicable law or agreed to in writing, software distributed under the Apache License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the Apache License for the specific language governing permissions and limitations under the Apache License.

***

*Issued in Ljubljana. Draft for community and legal review - V10 adaptation of the OriginTrail ODN Terms and Conditions.*

*OriginTrail, digitalne rešitve za dobavne verige, d.o.o.*


# OriginTrail DKG V10 Pre-Mainnet Bug Bounty

**Trust the source — including the source code.** *Break the DKG V10 economic contracts before they go live. Open to anyone.*

<table data-header-hidden><thead><tr><th width="199"></th><th></th></tr></thead><tbody><tr><td>Theme</td><td>Break the full DKG V10 on-chain contract set (<code>@origintrail-official/dkg-evm-module</code> @ <code>10.0.0-rc.17</code>) deployed as a public pre-mainnet</td></tr><tr><td>Total program value</td><td>300,000 $TRAC — a 200,000 capturable honeypot pool + a 100,000 severity-reward pool</td></tr><tr><td>Honeypot</td><td>Live on Base mainnet with real TRAC — one capped vault (~60,000) + cold reserve, redeployed across captures</td></tr><tr><td>Window</td><td>Phase 1 (Track 1 honeypot): June 10 → June 17, 2026</td></tr><tr><td>Submit</td><td><a href="https://github.com/OriginTrail/dkg/security/advisories/new">GitHub Private Vulnerability Reporting</a> or <a href="mailto:bounty@origin-trail.com">bounty@origin-trail.com</a></td></tr><tr><td>Issued by</td><td><a href="https://origintrail.io">OriginTrail</a></td></tr></tbody></table>

## The program in one line

The final V10 release candidate — the exact contract bytecode intended for mainnet — is deployed as a public **pre-mainnet**, funded with **300,000 TRAC: a 200,000 honeypot pool plus a 100,000 severity-reward pool**. Two tracks: **capture** real TRAC from the honeypot on the value-handling contracts, and **severity rewards for bugs in&#x20;*****any*****&#x20;V10 contract**. The honeypot runs as a single isolated, **capped** live vault — redeployed across captures so no single bug can take more than the cap. Anyone can attack it. What survives ships; what doesn't gets fixed first.

## Why

On 29 May 2026, a researcher using Claude Opus 4.8 found a critical, \~4-year-old soundness flaw in Zcash's Orchard pool — one that had passed repeated expert review — in about a day, with a working proof-of-concept. The lesson is plain: frontier AI now finds deep economic bugs faster than traditional review, and that power favors whoever uses it first. On-chain value-handling code launches once and mistakes are irreversible, so the V10 economic contracts are deployed as a pre-mainnet and attacked — by humans and AI — **before** user funds are committed. Passing this program is the gate to mainnet.

## Scope — the full V10 on-chain contract set (`@origintrail-official/dkg-evm-module`)

{% hint style="warning" %}
**Exact target:** npm package `@origintrail-official/dkg-evm-module`, version `10.0.0-rc.17` (or the pinned launch RC), in the `OriginTrail/dkg` monorepo under `packages/evm-module`. **Do not** confuse this with the legacy standalone `dkg-evm-module` (v8.1.0, repo `OriginTrail/dkg-evm-module`) — the frozen V8.1 module, which has **none** of these contracts.
{% endhint %}

**Every V10 on-chain contract is in scope, under two reward tracks.** Both pay the same severity bands; **capture** (drain real TRAC, keep it) is an additional bonus available only on the honeypot track.

### Track 1 — Honeypot: the value-handling contracts (capture + severity)

TRAC is fixed-supply with minting permanently disabled, so the target is not a counterfeit token — it is **forging an unbacked economic position**: a conviction NFT that claims rewards or principal without the stake behind it.

* **Conviction NFTs** — `DKGStakingConvictionNFT` and `DKGPublishingConvictionNFT` (+ `PublishingConviction` / `PublishingConvictionStorage`): the mint path, the wrapper↔position binding, lock tiers, transfer/burn, and the V8→V10 migration mint path.
* **Staking & rewards** — `StakingV10`, `ConvictionStakingStorage` (the canonical V10 store **and TRAC vault**): deposits, withdrawals, delegation, relock/redelegate, and claims. *(`StakingStorage` is V8 legacy, read only by the V8→V10 drain path — in scope for the migration cutover.)*
* **Reward accrual** — `RandomSampling` / `RandomSamplingStorage`: per-epoch score, score-per-stake settlement, and the delegator/operator reward split that funds claims.
* **Locks** — the lock-tier ladder in `ConvictionStakingStorage` and any path that mutates, bypasses, or unwraps a position early.
* **Access control** — mint authorization resolved through the **Hub**, the Hub registry itself (`setContractAddress`, `forwardCall`, `setAndReinitializeContracts`), `initialize()` guards, the `onlyContracts` set-membership gate (`HubDependent`), admin/pause roles, the multisig (`ICustodian`) + timelock, and the upgrade path (address-swap; **no delegatecall proxy**). *(Shared infra — also guards Track 2.)*

{% hint style="info" %}
**Primary invariant under test:** a conviction NFT exists **if and only if** a real, backed position of equal amount and tier exists in storage under the same owner — and minting is reachable only through the staking flow, never with caller-supplied amount/tier/multiplier. Break that binding and it's **Critical**. A value-draining bug here can **capture** the live honeypot vault (you keep it, up to the cap) on top of the severity reward.
{% endhint %}

### Track 2 — General audit: every other deployed contract (severity)

Every remaining V10 contract at the pinned RC is in scope for the **severity reward** — no honeypot (these don't custody the bounty pool, so there is nothing to "capture"), but paid by the same bands as Track 1:

* **Knowledge Assets** — `DKGKnowledgeAssets`, `KnowledgeAssetsStorage`, `KnowledgeAssetsLifecycle`, `KnowledgeCollection`, and the rc.17 per-KA memory-model contracts.
* **Context Graphs** — `ContextGraphStorage`, `ContextGraphValueStorage`, `ContextGraphs`, `ContextGraphNameRegistry`.
* **Identity & profiles** — `IdentityStorage`, `Identity`, `ProfileStorage`, `Profile`.
* **Network & accounting** — `ShardingTable(Storage)`, `Ask(Storage)`, `EpochStorage*`, `Chronos`, `DelegatorsInfo`, `PaymasterManager` / `Paymaster`, `WhitelistStorage`, `ParametersStorage`.

Any on-chain bug counts: asset/fund loss, access-control or mint-authorization bypass, incorrect settlement or accounting, permanent state corruption or freeze.

**Out of scope:** off-chain software / UI (unless it causes on-chain loss), the production network and real user funds, social engineering, pure off-chain DoS, and issues already in the public tracker.

### Verified lock-tier schedule

The contracts seed exactly **four locked tiers** plus a liquid rest state (`ConvictionStakingStorage` baseline ladder):

| Tier         | Lock (wall-clock) | Effective-stake multiplier | Withdrawable    |
| ------------ | ----------------- | -------------------------- | --------------- |
| **0** (rest) | none              | 1.0×                       | always (liquid) |
| **1**        | 30 days           | 1.5×                       | after expiry    |
| **3**        | 90 days           | 2.0×                       | after expiry    |
| **6**        | 180 days          | 3.5×                       | after expiry    |
| **12**       | 366 days          | 6.0×                       | after expiry    |

New tiers are append-only and governance-gated (`addTier`, Hub-owner / multisig). Multiplier is read from the tier table — **never** caller-supplied.

## The honeypots — 200,000 TRAC

Real staked principal across the lock tiers, active Publisher and Staker conviction positions, and seeded reward state — production economics mirrored at scale, deployed on **Base mainnet** with **real TRAC**, fully isolated from any live deployment (its own Hub + full stack). **If you can take it through a genuine bug, you keep it** — up to the live-vault cap, on top of the severity reward. Demonstrating a viable attack path is rewarded even if no funds move. The only TRAC at risk is this pool — by design.

**How it's funded — one capped live vault + cold reserve.** With real TRAC and no on-chain clawback, the only cap that holds against a malicious researcher is a *structural* one: the live vault is funded with only its cap, so a drain can never exceed it. The 200,000 is deployed as a single isolated live vault plus a cold reserve that redeploys it after each capture:

| Allocation                          | TRAC           | Role                                                                         |
| ----------------------------------- | -------------- | ---------------------------------------------------------------------------- |
| **Live vault** — one isolated stack | \~60,000 TRAC  | the active target; its balance **is** the cap on any single capture          |
| **Cold reserve**                    | \~140,000 TRAC | redeploys a fresh vault after each capture (topped up so re-arms are funded) |
| **Total committed**                 | **200,000**    | total downside, bounded here regardless of caps                              |

{% hint style="info" %}
**One vault, one ceiling.** All staker and publisher conviction route into a single `ConvictionStakingStorage` whose sole outflow is `transferStake`, so a binding-break drains the whole live vault in one tx — and the vault's \~60,000 balance is the structural ceiling on any single capture. After a valid drain the surface closes until the bug is patch-verified, then a fresh vault redeploys from reserve. The program runs across several sequential captures before the committed pool is exhausted.
{% endhint %}

**What's in the live vault.** A representative slice that keeps every bug class reachable at moderate magnitude:

* **Conviction staking across all four lock tiers** (1/3/6/12) spread over a few sharding-active nodes — a tier-12 "whale" position large enough to make a single-account drain worth real effort, plus mid and several small co-delegators that stress many-staker / shared-denominator / cross-node / dust-rounding interactions.
* **Publisher conviction** — `DKGPublishingConvictionNFT` accounts with committed TRAC and harness-published knowledge assets.
* **Seeded reward state** — so the "claim more than you're owed" path is live. Rewards are *accrual-based* (random-sampling proofs that compound into positions), so this is **harness-seeded** (a published KA + computed proofs over a few short epochs), not a static balance.
* **Migration / transitional** — accounts awaiting V8→V10 migration and positions left mid-unstake / mid-claim.

## General audit rewards

A **100,000 TRAC reward pool** prices severity for findings in **any** V10 contract, on top of the 200,000 TRAC honeypot captured on the value-handling contracts (Track 1).

| Severity          | Example                                                                                                                                                                                                    | Reward (TRAC)                                                   |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| **Critical**      | Minting an unbacked / over-stated conviction NFT; decoupling an NFT from its stake; minting outside the staking flow; Hub-registry takeover; bypassing locks; permanent fund freeze                        | **20,000–40,000** + capture up to the live-vault cap (\~60,000) |
| **High**          | Conditional / partial loss; access-control or mint-authorization bypass without immediate theft; temporary freeze; breaking a contract's functionality (e.g. minting Knowledge Assets) in an impactful way | **10,000–15,000**                                               |
| **Medium**        | Bounded impact — reward / accounting drift, incorrect settlement, value leakage without large-scale theft                                                                                                  | **2,000–5,000**                                                 |
| **Low**           | Minor impact under narrow preconditions                                                                                                                                                                    | up to **1,000** (discretionary)                                 |
| **Informational** | No economic-loss path                                                                                                                                                                                      | recognition + credit                                            |

**Minimum bar.** Severity = economic impact × breaking intended system behavior; no-impact findings are credited but unpaid. All reported bugs require a **working PoC**: on the live honeypot for Track 1 (which additionally stacks the capture bonus), or against the pinned RC / a forked deployment for Track 2. These gate the launch.

## Participate

Open to anyone — independent researchers, audit firms, AI-augmented teams. No invitation or allowlist; attack the public pre-mainnet honeypots and submit what you find.

* **Submit:** GitHub Private Vulnerability Reporting — <https://github.com/OriginTrail/dkg/security/advisories/new> (preferred), or email **<bounty@origin-trail.com>**.
* **Triage:** acknowledged within **48 hours**; severity assessed within **5 business days**.
* **Payout:** in TRAC after validation, subject to sanctions screening.
* **Disclosure:** coordinated — **no public disclosure before a fix ships** (hard requirement for bounty reward); credit on opt-in.
* **Safe harbor:** good-faith research within these rules will not be met with legal action. Full T\&C aligned with the project's Apache 2.0 license.

## Codebase

Code under audit: [packages/evm-module @ 36d9daeb](https://github.com/OriginTrail/dkg/tree/36d9daebee47ea0886a13e0d3b587f9ba512dc45/packages/evm-module)

Commit **`36d9daebee47ea0886a13e0d3b587f9ba512dc45`** (OriginTrail/dkg `main`, 2026-06-10) — the frozen RC the honeypot is deployed from.\
\
Pre mainnet deployment Hub contract address on Base Mainnet: [0x26146f51e31a95c075228a34cfc696f09e4c36c3](https://basescan.org/address/0x26146f51e31a95c075228a34cfc696f09e4c36c3)\
\
Token honeypot contract address: [0x27ff0e72552d7df824f0b561442f3a91a8f9e47e](https://basescan.org/address/0x27ff0e72552d7df824f0b561442f3a91a8f9e47e)

## Path to mainnet

DKG V10 reaches mainnet in four phases. **Phase 1 — the Frontier-AI Resilience Gate (this bounty) — is the pass/fail checkpoint:** what survives ships, what breaks gets fixed first.

<figure><img src="/files/8gN50cUd0gmqG6rZivkJ" alt=""><figcaption></figcaption></figure>

| Phase | Milestone                                                 | Window                               | Gate to advance                                                                                                                     |
| ----- | --------------------------------------------------------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| **0** | Final-RC freeze & pre-mainnet deployment                  | ✅ Completed                          | Exact mainnet bytecode (`@origintrail-official/dkg-evm-module` `10.0.0-rc.17`) live on Base mainnet as an isolated, capped honeypot |
| **1** | **Frontier-AI Resilience Gate** — Track 1 honeypot bounty | June 10 → **June 17, 2026** (1 week) | Honeypot survives; all Critical / High findings patch-verified                                                                      |
| **2** | **DKG V10 Mainnet Launch**                                | Week of June 17, 2026                | Bounty-hardened, feature-complete V10 goes live                                                                                     |
| **3** | **Continuous general audit** — Track 2                    | Ongoing, post-launch                 | Severity-priced findings across every V10 contract                                                                                  |


# DKG V10 Bounty Program

<figure><img src="/files/XjLlVZOvLYZwn9YZCibz" alt=""><figcaption></figcaption></figure>

## Round 1 — Call for Integrations

<table data-header-hidden><thead><tr><th width="199"></th><th></th></tr></thead><tbody><tr><td>Theme</td><td><a href="https://github.com/OriginTrail/dkg">DKG v10</a> Working Memory &#x26; Shared Memory × <a href="https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f">LLM-Wiki</a> / <a href="https://github.com/karpathy/autoresearch">Autoresearch</a> agents</td></tr><tr><td>Total bounty pool</td><td>Total of 150,000 $TRAC for 3 rounds, up to 10,000 $TRAC per accepted contribution capped at 50,000 $TRAC in round 1</td></tr><tr><td>Status</td><td>Open</td></tr><tr><td>Issued by</td><td><a href="https://origintrail.io">OriginTrail</a></td></tr></tbody></table>

### 1. Summary

[OriginTrail](https://origintrail.io) is opening the first round of the DKG v10 integrations bounty. This round is narrowly scoped to integrations that bring **Working Memory** and **Shared Memory** — the two pre-verification layers of the v10 memory model — into tools that advance Andrej Karpathy's vision of the **LLM Wiki** and **autoresearch**: collaborative, agent-native knowledge substrates where retrieval, writing, and verification collapse into a single loop.

We are especially interested in integrations with **OpenClaw, Hermes**, and agents of comparable shape — autonomous or semi-autonomous research agents operating over long-horizon tasks and producing knowledge artifacts that benefit from provenance, collaboration, and eventual on-chain verification.

The best contributions will be listed in the official DKG v10 integrations registry, featured across OriginTrail's documentation and ecosystem surfaces, and **rewarded with up to 10,000 TRAC per accepted submission**, tiered by impact — see sections 10 and 11. Integrations live in contributor-owned repositories and are consumed by users through the registry; this round does not merge contributor code into the dkg monorepo.

This call is the first of **three planned rounds**. Round 1 focuses on Working and Shared Memory. Round 2 will target Verifiable Memory and context oracles. Round 3 will target agent-ready analytics and user support. See section 12 for the full roadmap.

### 2. Why now

AI is shifting from single agents to **multi-agent systems**. Teams of models are doing research, writing code, running operations, and producing knowledge faster than any single agent could.

The bottleneck is no longer the model. **The bottleneck is memory** — specifically, a shared memory substrate that multiple agents can read, write, contest, and verify over time. Closed labs are racing to build this as proprietary infrastructure inside their own products. The market is heading toward a world where every major AI platform ships its own walled-garden memory layer, and the knowledge produced within each one is trapped there.

An open, verifiable, agent-native alternative does not yet exist at a production scale. The DKG is the closest thing to it — a public knowledge substrate with provenance, trust gradients, and on-chain anchoring already wired in. v10 is the release that makes it usable for agents.

{% hint style="info" %}
**This is the moment to define the memory layer of AI**, before the closed alternatives harden into defaults. Round 1 of the DKG v10 bounty program is where builders who want that layer to be open can ship the integrations that will shape it.
{% endhint %}

### 3. Why this round

The v10 memory model is built around a trust gradient: drafts mature from **Working Memory** (private, agent-populated) through **Shared Memory** (team-gossiped, collaborative) to **Verifiable Memory** (chain-anchored, with self-attested → endorsed → consensus-verified gradations).

Rounds on Verifiable Memory will follow. This first round deliberately targets the **pre-verification surface** — the layers where agents draft, iterate, and collaborate — because that is where LLM-Wiki / autoresearch workflows live most of the time. A good research agent spends the bulk of its life drafting and revising; only a small tail of its output ever needs consensus verification.

Karpathy's framing of the [LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) — a knowledge substrate natively legible to language models, continuously curated by a mixture of humans and agents — maps almost directly onto the v10 three-layer model. This round is the first concrete step toward making that substrate real.

### 4. Build this

If you are unsure what to build, start from one of these. They are concrete, buildable inside a round, and each one plugs DKG memory into a workflow real users already have.

#### Illustrative suggestions

* **ChatGPT / Claude plugin or MCP server that writes to Working Memory.** Every drafted artifact — chat, research note, code analysis — is deposited into the author's Working Memory with provenance and an agent-assigned status tag. Turns any conversation into durable, attributable knowledge.
* **Slack threads → Shared Memory.** An agent that watches a channel, identifies substantive exchanges (not chitchat), and shares them into Shared Memory and team Context Graph membership.
* **DKG as a memory backend for an existing RAG pipeline.** Swap a team's vector-store-plus-prompt retrieval loop for a DKG-backed one. Agents get provenance and promotion paths for free, and downstream context oracles become consumable without a rewrite.
* **GitHub → Working Memory ingestion.** Every issue, PR, and review comment in a repo flows into the author's Working Memory with code-aware tagging. The engineering knowledge a team generates daily, captured.

#### Other welcome shapes

* An OpenClaw adapter that deposits every drafted artifact into the author's Working Memory, status tags, and provenance.
* A Hermes Agent-style autoresearch loop that uses Shared Memory as its team scratchpad — gossip-replicated, multi-agent-readable, no merge-conflict UI.
* A wiki-style editor (think Roam / Logseq / Obsidian) that syncs bidirectionally with Shared Memory and promotes pages toward verification via the agent conversation surface.
* A citation-resolver that pulls from Shared Memory across a team's Context Graphs and resolves references back to canonical UALs.
* An inbox-style integration — email, arXiv feeds, RSS — that populates Working Memory with incoming items tagged by an agent.
* A SPARQL-backed research assistant that queries across a user's Working + Shared layers and a team paranet in a single cohesive view.

Your own idea is welcome. The list is a starting point, not a constraint.

### 5. In scope

A submission is in scope if it does **both** of the following:

1. Writes to or reads from **Working Memory** or **Shared Memory** on a DKG v10 node through a supported public interface and respecting v10 primitives (UAL, Knowledge Asset, Context Graph, Integration, Curator).
2. Connects that capability to a product, project, or agent advancing the LLM-Wiki / autoresearch direction.

Supported public interfaces for this round are:

* The node HTTP API (authenticated via bearer token)
* The dkg CLI, invoked as a subprocess
* MCP server (for MCP-capable clients such as Cursor, Claude Code, Claude Desktop, and other agent frameworks)

#### Priority integration targets

* **OpenClaw** — the Telegram-based agent build-orchestration environment. Integrations that route OpenClaw artifacts into Working Memory, or expose Shared Memory as a team substrate OpenClaw agents can read and contribute to, are highly valued.
* **Hermes Agent** — or comparable autonomous research agents (long-horizon, tool-using, artifact-producing).
* **Claude Code sub-agents and Agent Teams, Cursor-like IDEs with agent panels, Jupyter / notebook autoresearch kernels, literature-review and research-synthesis agents, RAG / dRAG pipelines** that want a verifiable upstream.

### 6. Out of scope (for this round)

* Integrations that touch *only* **Verifiable Memory** or chain-anchoring flows. These are the subject of a later round. Submissions that primarily target Working and Shared Memory but deliberately anticipate promotion to Verifiable Memory and consumption by context oracles are in scope and, per section 9, scored higher for it.
* UI buttons for endorsement, voting, or social consensus. In v10, these interactions are conversational and happen through the agent panel, not through UI affordances. Submissions reintroducing them will be rejected.
* Publisher-side Conviction / staking UX. Separate track.
* DKG v9-only work. The Situation Room-style v9 applications are valuable but out of scope here; this call is v10-specific.
* Integrations that bypass the Curator authority model on PUBLISH / SHARE operations.

Integrations that import from internal v10 packages (@origintrail-official/dkg-core, -storage, -chain, -publisher, -query, -agent, or any non-public subpath), patch node source, or load code into the node daemon process. These are forks of the node, not integrations in the v10 sense, and carry monorepo-merge obligations this program is not set up to handle. Build against the stable public interfaces listed in Section 5.

### 7. Design principles submissions must honor

Every accepted integration must respect the v10 design principles. These are non-negotiable:

* **Agent-first.** Connecting an agent is the entry point. "Let the agent decide" is the sensible default. Advanced controls live behind Advanced Settings, not on the main surface.
* **Trust gradient, not binary states.** Knowledge matures; it is not simply "unverified" or "verified". Working → Shared → Verified, with self-attested → endorsed → consensus-verified inside Verified.
* **Conversational consensus.** Endorsement and voting occur through agent conversation, not UI buttons.
* **Project-centric layering.** The three memory layers nest inside a project, not the other way around. Integrations should respect this hierarchy.
* **No merge/conflict UI on Shared Memory.** Shared Memory is gossiped, not merged.
* **Terminology discipline.** Use the established v10 vocabulary exactly: Context Graph, Integration, Curator, Entity, Knowledge Asset, SHARE, PUBLISH, Projects (not "Memory Explorer"). Deviations should be justified in the submission.

### 8. Submission requirements

A complete submission includes:

1. **Pull request** against the [OriginTrail/dkg-integrations](https://github.com/OriginTrail/dkg-integrations) repository, adding a single integration entry pinned to a specific commit and published package version of your own repository. Integrations live in contributor-owned repositories and consume the DKG v10 node through the supported public interfaces listed in Section 5. Round 1 awards are paid on registry acceptance; contributor code is not merged into the dkg monorepo. OriginTrail core developers may, at their discretion, later invite flagship integrations into first-party status as a separate conversation with an explicit maintenance handoff
2. **Design brief** (Markdown, 1–3 pages) covering: problem, target user, which memory layer(s) are touched, which v10 primitives are used, how it maps to the LLM-Wiki / autoresearch direction, any terminology choices that deviate from the v10 vocabulary, and an explicit **promotion path** section describing how Working and Shared artefacts mature toward Verifiable Memory and how the integration's outputs are shaped for downstream consumption by context oracles.
3. **Working demo** — a recorded walk-through or live endpoint. Screenshots alone are insufficient.
4. **Test coverage** proportionate to the surface area touched, and integration tests against a local v10 node.
5. **Security notes** — any credential, write-authority, or data-egress consideration, particularly around Curator authority on PUBLISH / SHARE.
6. **Maintenance commitment** — named maintainer and at least a 6-month support window post-merge.

### ​​8a. Security requirements

Before a registry entry is accepted, the following are verified — most are automated as CI checks on the registry repository:

1. Package is published to npm (or an equivalent verifiable registry) with build provenance (e.g., npm publish --provenance via GitHub Actions).
2. No postinstall or preinstall scripts in the published package, unless explicitly justified and reviewed.
3. License file present and SPDX identifier matches the registry entry.
4. Declared network egress: every external domain the integration contacts beyond the local DKG node is listed in the registry entry.
5. Declared write authority: every DKG endpoint or operation the integration invokes is listed, with any Curator-authority operations (PUBLISH, SHARE) called out explicitly.
6. No dynamic code loading outside the DKG SDK (no eval on remote input, no remote module fetch and execute).
7. npm audit --production clean, or outstanding advisories triaged in the submission.
8. Contributor attestation on the PR: the code is the contributor's own work or properly licensed, and contains no intentional backdoors.
9. For featured-tier submissions, a one-time manual security review of the pinned commit.

### 9. Evaluation criteria

Submissions are scored against the following, roughly in order of weight:

1. **Fit with LLM-Wiki / autoresearch direction.** Does this meaningfully advance agent-native collaborative knowledge work, or is the DKG integration incidental?
2. **Adoption potential.** Will real users use this? Does it plug into an existing workflow people already have? Does it unlock agent behavior that was previously impossible? The strongest submissions ship with a credible first user, not just a theoretical one.
3. **Faithfulness to the v10 memory model.** Correct use of layers, primitives, Curator authority, and terminology.
4. **Forward-compatibility with Verifiable Memory and context oracles.** Although this round targets the pre-verification layers, the strongest submissions treat Working and Shared Memory as upstream of Verifiable Memory — not as a terminal destination. Concretely: data structures, provenance, and UAL references should be shaped so that promotion to Verifiable Memory is a natural next step rather than a rewrite; and the integration should anticipate consumption by context oracles, so that artifacts maturing through the trust gradient become usable as oracle inputs for downstream agents and applications. Submissions that explicitly document their promotion path and oracle-readiness score higher.
5. **Quality of the agent surface.** Agent-first onboarding, sensible defaults, conversational consensus respected.
6. **Engineering quality.** Code clarity, test coverage, deployment story, dependency hygiene (standalone-repo-over-HTTP preferred over monorepo embedding).

Documentation. Design brief, in-repo docs, and onboarding for other contributors.

### 10. Bounty structure

Awards are tiered. The committee assigns a tier based on evaluation score, with a published rationale for each award.

<table data-header-hidden><thead><tr><th width="175.5"></th><th width="205"></th><th></th></tr></thead><tbody><tr><td><strong>Tier</strong></td><td><strong>Award range</strong></td><td><strong>What it signals</strong></td></tr><tr><td><strong>Flagship</strong></td><td>8,000 – 10,000 TRAC + ecosystem spotlight</td><td>Production-grade integration with a clear user base, faithful to the v10 model, strong forward-compatibility with Verifiable Memory and oracles. Lined up to become a default example in v10 documentation and ecosystem demos.</td></tr><tr><td><strong>High-quality</strong></td><td>3,000 – 7,000 TRAC</td><td>Solid, well-scoped integration that ships a real capability and is maintained. The working core of the ecosystem.</td></tr><tr><td><strong>Experimental / early</strong></td><td>1,000 – 3,000 TRAC</td><td><p>Promising early-stage work — a <strong>fully working</strong> prototype that proves a direction, a partial integration with a credible path to maturity, or a well-executed exploration of an underserved surface.</p><p>Note: Half-completed solutions are not eligible. Your application has to demonstrate a fully working, DKG-relevant capability in the context of the above-listed requirements.</p></td></tr></tbody></table>

* Awards are disbursed upon the merge of the approved pull request.
* Multiple submissions per team are allowed, but each must be substantively distinct.
* Accepted submissions are lined up for merge in the order the committee deems appropriate; queue position does not affect the tier or award.
* TRAC is paid on the network the contributor selects from those supported by v10 at the time of merge (NeuroWeb, Base, Gnosis), subject to the network's availability at the time of disbursement.

### 11. What happens if you win

Accepted integrations don't just get TRAC. They get distribution.

* **Registry listing.** Every accepted integration appears in the official DKG v10 integrations registry, consumed by the node itself (integration discovery and installation flows), and is displayed in the v10 dashboard UI. Being in the registry is how users find and adopt your integration.
* **Documentation.** Flagship and high-quality integrations are featured as default examples in the OriginTrail v10 documentation, developer guides, and agent onboarding flows.
* **Ecosystem demos.** Highlighted in ecosystem demos, community calls, and Trace Alliance Academy materials, where enterprise partners and agent builders are actively looking for reference integrations to adopt.
* **Introductions.** Contributors behind strong integrations are introduced to enterprise partners exploring the DKG for their own stack, and to agent-builder teams looking for memory primitives.
* **Follow-on eligibility.** Rewarded integrations from this round may be eligible for further rounds of the bounty program — in particular, later rounds targeting Verifiable Memory, context oracles, and Conviction-related UX. Teams that deliver faithful Round 1 work and document a credible promotion path are well-positioned to extend their integration in subsequent rounds. Eligibility is not automatic; each round opens with its own scope and criteria, and prior participation is a signal of fit, not a guarantee of award.

The goal is simple: Round 1 should be a platform entry point, not a one-off payout. Builders who show up here are the ones who define how the layer takes shape.

### 12. Program roadmap — three rounds

This call is the first of three planned rounds. The rounds are sequential: each builds on artifacts and infrastructure matured in the previous one, and scope tightens and layer coverage deepens as the program progresses. Round 2 and Round 3 scope is indicative and subject to refinement at each round's opening.

<figure><img src="/files/vAYlv6Ag2r1UYuIBrztI" alt=""><figcaption></figcaption></figure>

Figure 1. The three-round progression of the DKG v10 bounty program.

| **Round**                                                                                       | **Focus**                                                        | **Scope**                                                                                                                                                                                                     |
| ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <p><strong>Round 1 — Working & Shared Memory</strong></p><p><em>(open now)</em></p>             | Pre-verification integrations, LLM-Wiki, and autoresearch agents | Working and Shared Memory surfaces; priority integration with OpenClaw, Hermes, and comparable research agents. Up to 10,000 TRAC per accepted submission.                                                    |
| <p><strong>Round 2 — Verifiable Memory & context oracles</strong></p><p><em>(planned)</em></p>  | Chain-anchoring, trust-gradient verification, oracle pipelines   | The self-attested → endorsed → consensus-verified gradient; oracle pipelines consuming matured Shared Memory artifacts; Conviction-related UX where relevant. Follow-on eligibility for Round 1 contributors. |
| <p><strong>Round 3 — Agent-ready analytics & user support</strong></p><p><em>(planned)</em></p> | Agent-legible observability and agent-mediated support           | Analytics surfaces legible to agents rather than only humans; agent-mediated user support spanning the full trust gradient. Builds on verified artifacts and oracle outputs delivered in Round 2.             |

**Why the sequence matters.**

Round 1 seeds the pre-verification substrate with artifacts that have clean provenance and promotion paths.

Round 2 turns that substrate into verified, oracle-consumable knowledge.

Round 3 makes the whole stack usable — both by agents operating over it and by humans who need support navigating it.

Integrations that anticipate this arc from Round 1 onward — see evaluation criterion 4 — are best positioned to extend across multiple rounds.

**What is not committed.** The bounty cap, timeline, and review committee for Rounds 2 and 3 are not set here. They will be specified when each round opens. The Round 1 scope is the binding document for this call.

### 13. Timeline

<table data-header-hidden><thead><tr><th width="223"></th><th></th></tr></thead><tbody><tr><td><strong>Milestone</strong></td><td><strong>Date</strong></td></tr><tr><td>Round opens</td><td>On publication</td></tr><tr><td>First review cut-off</td><td>To be announced on the official channel</td></tr><tr><td>Rolling review thereafter</td><td>Yes</td></tr><tr><td>Round closes</td><td>When the round-one pool is exhausted (50.000 $TRAC, or when Round 2 opens — whichever is earlier</td></tr></tbody></table>

Exact review cut-off dates are announced on the official OriginTrail channel on the day, in keeping with the ecosystem's practice of not publishing sensitive timing in advance.

### 14. How to submit

1. Open the pull request against [**OriginTrail/dkg-integrations**](https://github.com/OriginTrail/dkg-integrations)**,** adding a single integration entry for your project pinned to a specific commit and published package version of your own repository.
2. Include all the required resources, including the design brief and demo link, in your repository.
3. Tag the submission cfi-dkgv10-r1.

Questions and early-stage design conversations are encouraged before opening a PR. The OriginTrail community channels are the right place for those.

### 15. Governance & review

* Submissions are reviewed by a committee drawn from OriginTrail, Trace Labs, and Trace Alliance contributors active on v10.
* Decisions are recorded with reasoning published alongside each accepted, redacted where contributor privacy requires it.
* Award amounts are described as **programmatic bounty disbursements**, not as amounts owed; the committee's decision on fit, quality, tier, and amount is final for the round.
* Conflicts of interest (committee members contributing submissions) are disclosed and recused.

### 16. Notes on conduct and IP

* Submissions must be the contributor's own work or properly licensed with licenses for open source software like MIT, Apache 2.0 etc.
* Contributors retain authorship; merged code is licensed under the v10 repository's standard license.
* The call does not constitute a contract of employment or a promise of future work. It is an open call with programmatic rewards for accepted contributions.
* Each participant accepts the [OriginTrail DKG V10 Terms & Conditions.](/getting-started/dkg-v10-t-c)

***

*Issued by OriginTrail d.o.o. For the current official channel and submission thread, see* [*origintrail.io*](https://origintrail.io)*.*


# Staking & Migration (V8 → V10)

This is the operator companion to [Conviction & Economics](/how-dkg-works/conviction-and-economics). That page documents the contract model. This page walks you through the **staking dashboard end-to-end** and covers the two journeys most people arrive with:

* [**Journey A**](#journey-a-migrate-your-v8-stake-to-v10) **— Migrate a V8 stake to V10:** You already have TRAC staked on V8 and want to move it into the new conviction model.
* [**Journey B**](#journey-b-first-time-staking-fresh-trac) **— First-time staking:** You hold TRAC in a wallet and want to delegate it to a node for the first time.

Both journeys end in the same place: a ***Staking Conviction*** position — an ERC‑721 NFT that records:

* Your staked amount
* The node you back
* Your lock tier
* Your reward multiplier
* Your unlock behavior

{% hint style="info" %}
**Demo note.** The screenshots in the source walkthrough run on a testnet deployment (Base Sepolia / Gnosis). Chain labels, balances, dates, and the live Annualized Node Yield figure differ on mainnet. Tiers and multipliers are the same.
{% endhint %}

***

## What you are staking into

Staking only makes sense once you know what your TRAC is securing. DKG V10 is a three‑layer memory system (see [Key Concepts](/how-dkg-works/key-concepts)):

```
Working Memory    ──►    Shared Working Memory    ──►    Verifiable Memory
(private drafts)         (peer-visible)                 (on-chain Knowledge Assets)
```

Knowledge worth keeping gets published as a ***Knowledge Asset*** — durable, provenance-bearing graph data anchored on-chain. The infrastructure that stores, serves, and verifies that memory is run by ***nodes**:*

* DKG *Core Nodes* carry the resilient backbone
* DKG *Edge Nodes* are the local gateways for users, apps, and agents

***Conviction*** is how the network ties TRAC commitment to long-term use, and it has two sides:

<table><thead><tr><th width="91">Side</th><th width="111">Who</th><th>What they commit</th><th>What they get</th></tr></thead><tbody><tr><td><strong>Demand</strong></td><td>Publishers</td><td>TRAC into a Publishing Conviction</td><td>Account Publishing allowance + price discount</td></tr><tr><td><strong>Supply</strong></td><td>Stakers</td><td>TRAC locked behind a specific node</td><td>Reward weighting + share of publishing fees</td></tr></tbody></table>

***Staker conviction*** **is the supply side.** When you stake, you pick a node and lock TRAC behind it for a chosen duration. That gives the node reward weighting and economic security, and it earns you a share of the publishing fees flowing through the network — proportional to your position's weight.

## The conviction ladder (lock → multiplier)

Your lock duration sets a **reward multiplier**. The multiplier scales the *weight* of your stake in the reward calculation. It does **not** mint or burn principal. The dashboard exposes five discrete tiers, which match the V10 contract model exactly:

<table><thead><tr><th width="76">Tier</th><th width="221">Lock</th><th width="115">Multiplier</th><th>Dashboard label</th></tr></thead><tbody><tr><td>1</td><td>No lockup</td><td>1x</td><td>Withdraw anytime</td></tr><tr><td>2</td><td>1 month (30 days)</td><td>1.5x</td><td>Short-term</td></tr><tr><td>3</td><td>3 months (90 days)</td><td>2x</td><td>Balanced</td></tr><tr><td>4</td><td>6 months (180 days)</td><td>3.5x</td><td>Strong</td></tr><tr><td>5</td><td>12 months (365 days)</td><td>6x</td><td>Maximum</td></tr></tbody></table>

**Effective stake weight = staked amount × multiplier.**

Example from the [video walkthrough of the Staking UI & migration](#dkg-v10-staking-ui-and-migration-walkthrough):

* 8,000 TRAC locked at the 12-month tier → `8,000 × 6 = 48,000` effective weight.

A longer lock buys a larger share of rewards in exchange for giving up liquidity until the unlock date.

{% hint style="info" %}
Rewards are routed from publishing fees to the stakers behind each node, weighted by effective stake. Two fees come off the top before stakers are paid: the **node operator fee** (set per node, shown in the dashboard) and the **protocol treasury fee** (governance-set, default **3%**, capped at **10%**, and dormant at 0% until wider consensus is achieved).
{% endhint %}

## The dashboard at a glance

The staking dashboard has three tabs:

<table><thead><tr><th width="131">Tab</th><th>Use it to</th></tr></thead><tbody><tr><td><strong>All Nodes</strong></td><td>Browse every node and compare yield, power, health, rewards, and operator fee before you delegate.</td></tr><tr><td><strong>My Positions</strong></td><td>See the NFT positions you already hold, plus any migrated TRAC still waiting to be staked.</td></tr><tr><td><strong>Migrate</strong></td><td>Move a V8 stake into V10 as a per-chain migrated balance.</td></tr></tbody></table>

The ***All Nodes*** table columns:

* *Annualized Node Yield:* Indicative return for delegating to that node.
* *Node Power:* Relative weight/stake behind the node.
* *Node Health:* Operational signal of the node's reliability.
* *Rewards:* Rewards accrued/available on the node.
* *Operator Fee:* The cut the node operator takes before staker rewards.

Supported chains throughout: Base, Gnosis, and NeuroWeb.

## DKG v10 Staking UI & migration walkthrough

{% embed url="<https://youtu.be/RDksODY-T_s>" %}

***

## Journey A — Migrate your V8 stake to V10

### Why migrate, and why now

Migration moves your existing V8 stake into the V10 conviction model **on the same chain — no bridging, no unstaking first, and without waiting out the 28-day cooldown**. Your V8 TRAC becomes a *migrated balance* that you then stake into a conviction tier.

There is also a one-time **migration credit** (the "sweetener"). TRAC that has been locked since the V8 snapshot — the point at which V8 paused reward distribution — earns roughly a **60-day credit** (the walkthrough cites 60–70 days).

The credit **shortens the duration of the highest conviction tiers:** placing an eligible balance on a 6- or 12-month lock unlocks about **60 days sooner**. The exact daily credit is calculated on the day the network is fully deployed.

### Step A1 — Open Migrate and connect your wallet

On the dashboard, open the migration flow. The "Migrate your stake to V10" modal explains the model:

#### **Migrate your stake to V10**

DKG V10 introduces **conviction staking**. Move your existing V8 stake into V10 — same chain, no bridging, and without unstaking first or waiting the 28-day cooldown.

1. **Migrate stake.** One transaction per chain drains your V8 stake.
2. **It becomes a migrated balance.** Per chain (Base, Gnosis, NeuroWeb\*), ready to stake or withdraw.
3. **Stake it like normal.** At the confirm step, you choose your TRAC source — either wallet or V8-migrated balance. Eligible balance on a 6/12-month lock unlocks 60 days sooner.

#### **NeuroWeb is exempt for now — no live nodes.**

There are no nodes running on NeuroWeb yet, so there is nothing to delegate to on that chain, and its Migrate/Stake action is greyed out. Any migrated NeuroWeb balance can still be withdrawn.

Until nodes come online there, do your migration and staking on **Base and Gnosis**.

1. Choose ***Migrate stake*** (or ***Not now — go to staking*** to skip straight to fresh staking).
2. **Pick a wallet from the connect prompt**. The dashboard uses EIP-6963 provider discovery, so it auto-detects any compatible browser extension wallet you have installed (MetaMask, Rabby, Coinbase Wallet, Brave, Phantom, …). There is no WalletConnect, so the connection is via a browser extension rather than a mobile QR pairing.
3. **Approve the connection in your wallet.** The dashboard then reads your exact balances per chain from your migration account.

### Step A2 — Review your migrated balances per chain

The Migrate V8 → V10 screen lists ***Your migrated TRAC***, one row per chain (Base, Gnosis, NeuroWeb), each showing that chain's migrated balance with **Stake** and **Withdraw** actions.

**Migration runs one transaction per chain** — each drains that chain's V8 stake into its migrated balance. You can migrate one chain, several, or all.

### Step A3 — Confirm credit eligibility

On the confirm step, you'll see **your eligibility spelled out** — your migrated balance on that chain, and how much of it is eligible for the 60-day credit.

Eligible balance gets the shortened unlock when you place it on a 6- or 12-month tier. So if you intend to claim the credit, stake into the **3.5× (180-day)** or **6× (365-day)** tier.

### Step A4 — Stake the migrated balance (Delegate TRAC)

Click Stake on a chain row to open the Delegate TRAC wizard. It has four steps: **Conviction → Chain → Node → Confirm**.

1. **Conviction.** Pick a tier from the ladder (1× / 1.5× / 2× / 3.5× / 6×). The walkthrough selects 6× — 365 Days — Maximum for the largest multiplier and the best reward share. Select and Continue.
2. **Chain.** Confirm the chain for this position (e.g. Gnosis). Continue.
3. **Node.** Choose a node from the searchable list (each row shows the node, its stake, and its fee, with a Select action). The walkthrough selects Anacreon. Continue.
4. **Confirm —** the amount & confirm step:
   1. **Stake from:** Toggle between "*Your wallet balance"* and "*V8 migrated balance"*. For migration, choose "*V8 migrated balance"*.
   2. **Amount to stake:** Type an amount or hit MAX.
   3. **Review the summary:** *Conviction*, *Chain*, *Node*, *Unlock date* (e.g. 17 Apr 2027), *Effective stake weight* (your staked amount × the tier multiplier), and *Estimated Annualized Node Yield* (the live figure is wired in once the protocol Annualized Node Yield formula is settled).
   4. Tick "I have read and accept the terms", then **Stake migrated TRAC**.

{% hint style="info" %}
**You don't have to stake it all on one node.** You can split a migrated balance across nodes — put part on one node and the remainder on another — to spread across operators. Run the wizard once per slice.
{% endhint %}

### Step A5 — Verify under My Positions

Open **My Positions**. You'll see:

* **Summary tiles:** Total TRAC Staked, Total Fees Earned, Claimable Now.
* **A banner reminding you of any migrated TRAC still unallocated** across your chains: Stake it into V10 or withdraw it.
* **A position card for the stake you just created:**

  * the position NFT (e.g. `#4596`, with View NFT),
  * the node (Anacreon),
  * the chain (Gnosis),
  * a *Migrated from V8* badge,
  * the staked amount,
  * the tier/multiplier, and
  * the Started/Unlocks dates.

  That position is now live and accruing.

***

## Journey B — First-time staking (fresh TRAC)

If you have no V8 stake, you stake TRAC straight from your wallet. Connect a wallet first — any EIP-6963 browser-extension wallet you have installed (MetaMask, Rabby, Coinbase Wallet, …). The flow is then the same wizard as migration, with two differences: you start from ***All Nodes***, and your source is ***Your wallet balance***.

### Step B1 — Pick a node on *All Nodes*

Open ***All Nodes*** and compare candidates. A reasonable first pass:

* **Node Health:** Favor reliable nodes; an unhealthy node is a poor home for a long lock.
* **Operator Fee:** A lower fee means more of the publishing fees reach you.
* **Annualized Node Yield/Rewards:** The indicative return, read alongside the fee and health rather than in isolation.

### Step B2 — Start staking → Delegate TRAC

Click ***Stake TRAC*** to open the same **Delegate TRAC** wizard (**Conviction → Chain → Node → Confirm**):

1. **Conviction.** Pick your lock tier. If you want liquidity, start at 1× (No lock — withdraw anytime); for a larger reward share, lock longer.
2. **Chain.** Pick Base or Gnosis — choose the chain where you hold TRAC and want the position to live. (No live nodes currently available on NeuroWeb)
3. **Node.** Select your node from the list.
4. **Confirm.** On Amount & confirm:
   1. Set *Stake from → Your wallet balance*
   2. Enter the amount (or MAX)
   3. Review the summary (multiplier, unlock date, effective weight)
   4. Accept the terms, and Stake.

### Step B3 — Approve in your wallet and verify

Your wallet will request token-spend approval, then the stake transaction. Approve both. The new NFT position then appears under ***My Positions***, with no "Migrated from V8" badge.

***

## After you stake — managing a position

Each position is an ERC-721 NFT. From My Positions you can:

* **Withdraw matured locks:** Once a locked position reaches its unlock date (or immediately, for the 1× no-lock tier).
* **Re-delegate the position** to a different node.
* **Renew conviction** at a new tier.

### Withdraw and locks

<table><thead><tr><th width="265">Situation</th><th>Liquidity</th></tr></thead><tbody><tr><td>1x (no lock)</td><td>Withdraw any time from My Positions.</td></tr><tr><td>Locked tier, past unlock date</td><td>Withdraw normally.</td></tr><tr><td>Locked tier, before unlock date</td><td>TRAC stays locked until the unlock date.</td></tr></tbody></table>

A longer lock trades liquidity for a higher multiplier: there is **no early exit**, so pick a tier you are comfortable committing to for its full duration.


# Roadmap

Multi-Agent Memory  ·  DePIN  ·  Truth-Seeking Algorithms  ·  Conviction Mechanisms

## Metcalfe Convergence Phase

### 1. Why Now: Matching the Velocity of Agentic AI

Agentic systems are entering production at a pace that will define infrastructure lock-in for the next decade. The unsolved problem at the frontier is no longer model capability, but rather how collaborating agents share and verify the knowledge they’ve learned.

{% hint style="info" %}
**KARPATHY’S AUTORESEARCH: THE PROBLEM THE DKG SOLVES**

Andrej Karpathy [described the next frontier:](https://x.com/BranaRakic/status/2035467180431593939?s=20) thousands of autonomous agents collaborating across the internet on the same research problem, running parallel experiments where each commit builds on the last. His AutoResearch system ran 700 experiments in 2 days on a single GPU, discovering 20 optimizations autonomously. His vision: "a swarm of agents on the internet could collaborate to improve LLMs and could potentially even run circles around Frontier Labs."

But Karpathy identified the critical unsolved problem: **how do you coordinate an untrusted pool of workers out there on the internet?** The work is expensive to produce but cheap to verify. The structure looks like a blockchain - instead of blocks you have commits, and the proof of work is doing tons of experimentation to find commits that work. The Earth has a huge amount of untrusted compute. We need systems in place that deal with using that compute with trust.

**This is exactly what context graphs on the DKG do.**
{% endhint %}

{% hint style="info" %}
**DECENTRALIZED KNOWLEDGE GRAPH (DKG): THE TRUST LAYER FOR KEEPING CONTEXT IN AGENT SWARMS**

As Branimir Rakić (OriginTrail CTO) articulated: an auto-research swarm sets up a context graph with a defined set of verifier agents and an M-of-N signature threshold. Untrusted agents run experiments and submit results as Knowledge Assets. For those results to land in the shared context graph, M of the N trusted verifiers must confirm results, then cryptographically co-sign the batch on-chain, attesting that the claimed metrics actually reproduce.

The result is a growing, queryable knowledge graph of verified experimental results that any agent in the swarm can query to decide what to try next - built on a trust layer where untrusted contributors do the heavy lifting and trusted verifiers keep the graph honest.
{% endhint %}

Meanwhile, every major AI company is racing to give AI an improved memory. Anthropic shipped it for Claude, OpenAI built it into ChatGPT, Google wired it into Gemini. But these are siloed, proprietary memory systems. The demos are compelling: an assistant that remembers. The problem: each system creates its own memory silo. No agent can access another’s memory. No memory is verifiable. No memory is ownable by the user. The DKG provides the alternative: **multi-agent memory that is persistent, verifiable, decentralised, controlled by users and shared across any framework.**

The improvements to OriginTrail are not a reaction to advancements by major AI companies - DKG V9 must ship the multi-agent memory layer to service immediate demand signals from industries the DKG is already exposed to, and implicit indications from markets that do not yet use decentralised infrastructure for AI agents.

The V9 testnet has validated the core architectural changes: multi-agent memory coordination, autonomous knowledge publishing, conviction mechanism viability, Edge Node + AI agents co-location via the DKG CLI, and enhanced graph structure. With the DKG v9 Testnet progress, **the following 4 week development plan’s objective is to release the full DKG v10 Mainnet:**

| <p><strong>WEEK 1</strong></p><p>NOW</p> | V9 Testnet Hardening - Multi-agent memory, initial swarm simulations.                                                                               |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| <p><strong>WEEK 2</strong></p><p>W2</p>  | V10 Mainnet Candidate - Deployment & testing of conviction mechanisms, parameters finalised, data monetisation flow.                                |
| <p><strong>WEEK 3</strong></p><p>W3</p>  | V10 Mainnet Candidate - Full feature set: Context Oracles simulation integration, final stress tests, mainnet readiness.                            |
| <p><strong>WEEK 4</strong></p><p>W4</p>  | V10 Mainnet Launch - Conviction mechanisms live. Full DePIN infrastructure: every Edge Node = DKG participant + AI agent host + knowledge endpoint. |

### 2. The Four Pillars of Convergence

<table data-header-hidden><thead><tr><th width="187"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><p><strong>DePIN Infrastructure</strong></p><p>Nodes + AI agents on local devices</p></td><td><p><strong>Multi-Agent Memory</strong></p><p>Collective memory across swarms</p></td><td><p><strong>DKG Apps</strong></p><p>DKG-grounded swarm intelligence</p></td><td><p><strong>Truth-Seeking Algorithms</strong></p><p>Monetisation + conviction mechanisms</p></td></tr></tbody></table>

#### 2.1 DePIN: Nodes Co-located with AI Agents

Every DKG node is simultaneously a DePIN infrastructure participant and an AI agent host. Edge Nodes run DKG-enabled trusted AI directly on user devices - laptops, Mac Minis, enterprise systems - preserving privacy while participating in the global knowledge marketplace. Core Nodes form the resilient network backbone, hosting the public replicated DKG. Edge Nodes bring intelligence to the network edge.

* **Local AI agent hosting:** Agents process sensitive data on-device. The Edge Node provides access to both private (local) and public (DKG network) knowledge.
* **DKG CLI:** Single command-line interface for the entire node lifecycle - installation, agent deployment, plugin management, knowledge operations. Fully functional Edge Node with co-located agent in minutes.
* **Fully local dRAG with enhanced privacy:** Decentralised RAG on-device, combining private Edge Node data with public DKG knowledge for hallucination-resistant responses.

#### 2.2 Multi-Agent Memory

The DKG provides persistent, verifiable memory for autonomous agents. Individual agents maintain private memory as knowledge graphs on their DKG Edge Node (ownable, portable, cryptographically verifiable). Agents publish selected knowledge to the public DKG (such as indexing information for private knowledge, or open public knowledge) where it becomes collective swarm memory.

* **AI Agent Workspace:** Collaboration module enabling agents to coordinate and share context in real time without full verifiability of public DKG + on-chain proofs..
* **Context Oracle:** Cryptographically verifiable corroborated multi-agent claims with Knowledge Assets - consensus checks that ground agent outputs in verified knowledge.

The DKG trust layer for keeping context enables V9/V10 agents to autonomously identify knowledge gaps and fill them through neural reasoning - the DKG becomes a self-expanding knowledge organism. Through the DKG CLI and API, agents on any framework share the same memory backbone.

#### 2.3 DKG Apps

**Example 1: OriginTrail Game**

Hello world for the DKG node - an Oregon Trail-inspired game demonstrating multi-node collaboration, serving as the accessible entry point for developers to experience the DKG’s multi-agent capabilities firsthand.

**Example 2: Verifiable Agent-Driven Predictions**

MiroFish-style swarm engines spawn thousands of agents to simulate emergent behaviour for predictions. The DKG transforms these from opaque simulations into verifiable infrastructure: agents ground reasoning in provenance-backed Knowledge Assets, memories persist across simulation runs, every prediction carries a full on-chain provenance trail, and DKG-verified predictions flow into prediction markets with cryptographic proof of methodology integrity.

**Example 3: Trusted Autoresearch**

Andrej Karpathy's autoresearch lets AI agents collaborate on ML experiments - for them to do so at scale the missing piece is trust. Any untrusted agent can run experiments and claim results, but without a verification layer, no other agent can know whether those results actually reproduce. The DKG v9/v10 autoresearch app solves this by wrapping the same experiment loop in a DKG context graph with an M-of-N verification threshold: untrusted agents run experiments and submit results as Knowledge Assets, but those results only land in the shared graph once M of N designated verifier agents cryptographically co-sign the batch on-chain, attesting that the claimed metrics reproduce. The result is a growing, SPARQL-queryable knowledge graph of verified experimental findings that any agent in the swarm can query to decide what to try next — keeping the open, permissionless contribution model of AgentHub while adding the cryptographic trust layer it lacks.

#### 2.4 Truth-Seeking Algorithms: Monetisation + Conviction Mechanisms

For the DKG to achieve self-sustaining growth, the knowledge economy must have native monetisation and aligned long-term incentives. Two conviction mechanisms - publisher conviction (demand-side) and staker conviction (supply-side) - form the economic engine, complemented by external composability with agent payment protocols.

***

### 3. Publisher Conviction

#### 3.1 Mechanism

Publishers commit a sum of TRAC in advance for 12 months of undefined DKG usage. The committed TRAC converts into a pre-purchased allowance for publishing, updating, and querying Knowledge Assets. This allowance depletes with usage and with completion of each epoch. This also means that TRAC emissions pre-comitted get distributed into the network, even if publishers don’t use the allowance to publish anything in any given epoch.

If the epoch limit is exhausted (committed TRAC / 12 epochs), the publisher can top up at the current network rate.

* **Fixed term:** Always 12 months. The conviction signal on time is binary - you’re in or you’re not.
* **Variable capital:** The amount committed determines the discount tier.
* **Locked TRAC:** Committed TRAC is locked for the full 12-month term, reducing circulating supply and increasing network security.
* **Credit expiry:** Unused credits “expire” each epoch, but still flow towards staking rewards - ensuring committed capital always benefits the network.

#### 3.2 Discount Tiers

The discount curve is calibrated against industry benchmarks\* for comparable infrastructure commitment models:

| **TRAC Committed** | **Discount** | **Industry Benchmark**                                           |
| ------------------ | ------------ | ---------------------------------------------------------------- |
| 25,000             | 10%          | Comparable to SaaS annual prepay (15–25%)                        |
| 50,000             | 20%          | <p><br></p>                                                      |
| 100,000            | 30%          | Comparable to AWS 1-yr Partial Upfront (\~40%)                   |
| 250,000            | 40%          | Comparable to OpenAI Batch API discount (50%)                    |
| 500,000            | 50%          | Between AWS 1-yr and 3-yr commitments                            |
| 1,000,000+         | 75%          | Comparable to AWS 1-yr All Upfront / EC2 Instance SP (up to 72%) |

**\*Industry benchmarks**

* **AWS Savings Plans:** 1-year commitments offer up to 66–72% off on-demand. These are the discounts publishers compare against when evaluating DKG commitment economics.
* **LLM API pricing:** OpenAI Batch API offers 50% off. Enterprise contracts routinely reach 40–60%. The DKG’s mid-tiers match these benchmarks.

{% hint style="info" %}
**ENTRY TIER MATTERS MOST:** *Converting a pay-as-you-go publisher into a 12-month committed publisher is the highest-leverage decision in the flywheel. The 25K → 10% tier clears lockup friction and gets the publisher contributing to DKG growth for a full year.*
{% endhint %}

***

### 4. Delegated Staker Conviction

Conviction Staking introduces a new way to commit to the OriginTrail ecosystem. When staking TRAC, participants choose their principal amount and a lock period - ranging from no lockup at all to a full 12-month commitment. Each tier carries a progressively higher reward multiplier:

| **Lock Period** | **Multiplier** | **Description**                                                        |
| --------------- | -------------- | ---------------------------------------------------------------------- |
| No lockup       | 1x             | Base rewards with full liquidity - withdraw anytime                    |
| 1 month         | 1.5x           | Equivalent to V8’s existing 28-day withdrawal period, now with a boost |
| 3 months        | 2x             | Quarterly commitment - meaningful conviction signal                    |
| 6 months        | 3.5x           | Half-year commitment - strong alignment                                |
| 12 months       | 6x             | Full conviction - maximum alignment with network growth                |

The curve is designed to disproportionately reward long-term alignment with network growth, while preserving accessible entry points at every level of commitment.

#### 4.1 ERC-721 Conviction NFTs (Uniswap V3 Model)

Each conviction stake is minted as an ERC-721 NFT, making your locked position a first-class on-chain asset. The NFT encodes principal, lock duration, multiplier, and expiry - turning what would otherwise be an illiquid lockup into something composable and verifiable.

The design draws direct inspiration from Uniswap V3, which pioneered ERC-721 NFTs to represent unique financial positions. In Uniswap V3, liquidity providers concentrate capital into a specific price range - the tighter the range, the greater the yield. Conviction staking applies the same logic to time: stakers concentrate commitment into a specific lock period - the longer the lock, the higher the multiplier. Where Uniswap V3 rewards precision in price, DKG V9 rewards conviction in time.

* **Network-level conviction:** Unlike traditional delegated staking, conviction is not tied to a specific node. It is a commitment to the DKG network as a whole. Node selection and delegation remain separate concerns.
* **Fractionalisable:** Conviction NFTs support fractionalisation - a single locked position can be split into smaller units, enabling shared staking positions, secondary market liquidity, and collective participation without breaking the underlying lock or forfeiting the multiplier.
* **Composable:** Conviction NFTs can be held, transferred, traded, or used as building blocks in DeFi - bringing the full expressiveness of the NFT ecosystem to staking.

***

### 5. Monetisation: x402 Native Agent Payments

x402 (Coinbase/Google/Visa/Cloudflare) enables autonomous stablecoin micropayments over HTTP. Integrated with the DKG: agents can pay per-query for premium Knowledge Assets, agent-to-agent knowledge commerce operates at protocol level without intermediaries, and the full cycle - knowledge retrieval, swarm simulation, prediction, market trade, settlement - becomes a single autonomous flow.

***

### 6. The Conviction Flywheel

| <p><strong>DEMAND SIDE</strong></p><ul><li>Publishers commit TRAC for 12 months</li><li>Knowledge Assets created at scale</li><li>DKG becomes more valuable (Metcalfe)</li><li>More agents integrate → more publishers</li></ul> | <p><strong>SUPPLY SIDE</strong></p><ul><li>Stakers lock TRAC for fixed periods</li><li>Infrastructure secured long-term</li><li>Node stability attracts publishers</li><li>Fee share + boost rewards stakers</li></ul> |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

{% hint style="info" %}
**RESULT:** Publishers commit TRAC for knowledge growth. Stakers commit TRAC for infrastructure security. Locked TRAC reduces circulating supply. Network stability attracts more publishers and agents. More Knowledge Assets make the DKG more valuable. The flywheel accelerates - driven by the network effects that Metcalfe’s Law predicts from connectivity.
{% endhint %}

{% hint style="info" %}
**WE CONNECT WHAT OTHERS ISOLATE**

The Metcalfe Convergence Phase is the inflection point where the DKG becomes the essential trust layer for the Age of AI. V9 testnet validated. V10 mainnet in 4 weeks. The Convergence is not a distant vision - it is happening now.
{% endhint %}

*The roadmap published on the official OriginTrail website does not yet reflect the pace of the DKG v10 Mainnet rollout. Most of the envisioned features of it however are covered in detail here:* [*origintrail.io/ecosystem/roadmap*](http://origintrail.io/ecosystem/roadmap)


# V10 Mainnet Release Timeline

<table data-header-hidden><thead><tr><th width="146"></th><th width="169.5"></th><th></th></tr></thead><tbody><tr><td><strong>Milestone</strong></td><td><strong>Date (indicative)</strong></td><td><strong>Key Output</strong></td></tr><tr><td>V10 Release Candidate out</td><td>8 April 2026</td><td>V10rc testnet releases. Smart contracts finalised (implementation, tests, internal security review). V10 protocol core implementation confirmed. New node UI implemented.</td></tr><tr><td>Epoch snapshot</td><td>9 April 2026 00:00:01 UTC</td><td>Current epoch ends. Mainnet snapshot executed — V8 publishing allocation frozen at epoch boundary. Defines each publisher's TRAC balance eligible for V10 conviction migration.</td></tr><tr><td>Updating V8 publishing allocation to V10 Publisher Conviction</td><td>10 April 2026</td><td><p>Tokens sent to publisher wallets so they can republish under the V10 conviction system once V10 launches. Publishers have time to bridge to networks of their choice.</p><p>Node runners have 1 week to get ready to update.</p><p>Stakers prepare to potentially re-delegate ahead of V10 release. V10.0 Mainnet release scheduled for the following week.</p></td></tr><tr><td>New Conviction System Staking UI</td><td>15–17 April 2026</td><td>New Staking UI live, now including conviction staking. Exact release time communicated only via the official channel on the day of release — not published in advance to reduce potential attack vectors.</td></tr><tr><td>V10 Mainnet launch window</td><td>15–17 April 2026</td><td><p>DKG V10 deployed on all networks (NeuroWeb, Base, Gnosis). Publishers and node runners choose which network to operate on. Publishing factor resets to new V10 system (breaking change).</p><p>Publishers create publishing conviction accounts and allocate their TRAC on their network of choice.</p><p>Stakers use the new Staking UI to upgrade their staking positions to V10 conviction.</p></td></tr><tr><td>Ongoing V10 updates &#x26; bounty release</td><td>20 April onwards</td><td>Rolling V10 updates across all integrated networks. Bounty programme releases, with rewards for ecosystem builders and developers actively growing the V10 network, including bug bounty.</td></tr></tbody></table>

### Publisher Conviction — How It Works in DKG V1

[The V10 roadmap ](https://docs.origintrail.io/origintrail-v9-v10/roadmap)specifies Publisher Conviction in precise operational terms: publishers commit a sum of TRAC in advance for 12 months of DKG usage. The committed TRAC converts into a pre-purchased allowance for publishing, updating, and querying Knowledge Assets on the publisher's chosen network — Base, Gnosis, or NeuroWeb. The conviction signal is binary: you are in for 12 months, or you are not. The variable is the amount of TRAC committed.

* **Discount tiers:** Six tiers from 10% discount (25,000 TRAC committed) to 75% discount (1,000,000+ TRAC committed). The DKG's conviction economics are benchmarked against comparable infrastructure commitment models, designed to make multi-year knowledge publishing financially attractive relative to pay-as-you-go alternatives.
* **Epoch flow-through:** TRAC committed by publishers is distributed to staker rewards each epoch even if publishers do not use their full allowance in a given epoch. There is no dead capital in a conviction position — committed TRAC always flows to the network.
* **ERC-721 Conviction NFTs:** Each conviction position is minted as an ERC-721 NFT encoding the principal, lock duration, discount tier, and expiry. Conviction NFTs are composable and fractionalisable — they can be held, transferred, traded, or used as building blocks in DeFi. Publishers who wish to exit a position before term can do so via secondary market transfer of the NFT.

Network-level commitment: Conviction is a commitment to the DKG network as a whole, not to a specific node. Node selection and delegation remain separate concerns. The design intent: disproportionately reward long-term alignment with network growth while preserving accessible entry points at every level of commitment.

#### The V8 → V10 Publisher TRAC Migration

To republish existing knowledge to the V10 network, each publisher brings their accrued V8 publishing TRAC — TRAC committed but not yet emitted as staking rewards — to DKG V10, choosing their preferred network (NeuroWeb, Base, or Gnosis).

This TRAC is committed under the V10 Publisher Conviction mechanism and emits programmatically to stakers over up to 2 years, made possible by the V10 conviction emission model entering into force at launch. Publishers add additional TRAC to their accounts for publishing new knowledge.

The result: useful publisher knowledge is migrated to V10. Stakers receive the same total TRAC for published knowledge from the V8 period, but 3 years earlier in net terms. Publishers enter V10 already in conviction positions with discount tier access.

{% hint style="info" %}
**In Plain Terms for Stakers**

Under DKG V8, the TRAC publishers committed for publishing is programmatically emitted to stakers over up to 5 years. Under V10, that same TRAC is brought by publishers under the Publisher Conviction mechanism and emitted programmatically over up to 2 years. The total amount does not change — only the schedule does — meaning stakers receive it 3 years faster in net terms.

Stakers are not required to take any action to receive V10 publisher conviction rewards. If you are staked on a V10-active node, publisher conviction TRAC will flow to you each epoch automatically, starting from the V10 mainnet launch.

The updated Staking UI gives you the option to boost your rewards further by locking your own staking position under conviction multipliers. Learn more about the Delegated Staker Conviction mechanism [here.](https://docs.origintrail.io/origintrail-v9-v10/roadmap)
{% endhint %}

### Release Timeline

The following sections detail what happens, when, and what each participant group — publishers and publishing node runners, stakers, and node runners — needs to do at each stage of the V10 launch.

{% stepper %}
{% step %}

### 6–10 April - Release Candidate & V8 Allocation Update

**What Publishers and Publishing Node Runners Should Do**

* Review the official V10 documentation — it specifies the exact conviction parameters, discount tiers, and emission schedule that will govern your V10 position.
* Review your V8 TRAC balance as of the epoch snapshot on 9 April. This is the amount you can commit to a V10 Publisher Conviction position.
* Decide your conviction tier: the amount of TRAC you commit determines your discount (10% at 25,000 TRAC up to 75% at 1,000,000+ TRAC).
* Choose your network: NeuroWeb, Base, or Gnosis are all supported. Your conviction position is network-specific.
* Prepare your V10 publishing wallets for the creation of conviction accounts on your chosen network.
* Your V8 nodes will remain operational, but after V10 launches you will need to deploy new V10 nodes to resume knowledge creation.

**What Node Runners Should Do**

* Review the V10 node release notes that accompany the Release Candidate published on 8 April.
* Prepare to deploy V10 nodes as fresh deployments — V10 nodes are not upgraded in-place from V8. The publishing factor resets to the new V10 system at launch.
* Consider testing the V10 release candidate on testnet to prepare for the migration.
* Plan for publishers to republish to your V10 node. All publishing on V10 starts from a clean state regardless of V8 history.

**What Stakers Should Do**

* No immediate action is required this week — staking features continue normally on V8.
* Review the official V10 documentation to understand the new Conviction System Staking UI, launching between 15 and 17 April. Exact timing will be announced on the official channel on the day of release.
* Prepare to potentially re-delegate under V10 conviction. The new staking model offers multipliers (1x to 6x) based on lock period — consider which tier suits your preference.
  {% endstep %}

{% step %}

### 13–17 April - V10 Mainnet Launch & New Conviction System Staking UI

This is the launch week. The new Conviction System Staking UI goes live between 15 and 17 April — exact timing communicated on the official channel on the day to avoid providing potential attackers with advance information. V10 Mainnet launches in the same window across all networks: NeuroWeb, Base, and Gnosis. Publishers and node runners choose which network to operate on.

**What Publishers and Publishing Node Runners Should Do**

* Create your V10 Publishing Conviction account on your chosen network once mainnet is live. Allocate your V8 TRAC snapshot balance plus any additional TRAC you wish to commit to your conviction position.
* Your conviction position is minted as an ERC-721 NFT. Verify it appears in your wallet and matches your intended principal, discount tier, and expiry.
* Begin republishing your Knowledge Assets to V10 nodes. V10 is a fresh start — your V8 Knowledge Assets do not automatically migrate. Republish the knowledge you wish to carry forward at the discounted rate your conviction tier provides.
* Your conviction TRAC begins flowing to staker rewards from the first epoch after you create your position — regardless of whether you have actively published anything yet.
* Deploy your V10 DKG nodes after V10 lands on mainnet — V10 nodes are deployed fresh, not upgraded from V8. Your node's publishing factor resets to zero at launch. Attracting active publishers to republish through your node is the primary way to build publishing factor quickly.

**What Stakers Should Do**

* Access the new Conviction System Staking UI when it goes live. Review your V8 staking position and convert to V10 conviction staking if you wish to access reward multipliers.
* Conviction staking on V10 offers five lock tiers: no lockup (1x multiplier), 1 month (1.5x), 3 months (2x), 6 months (3.5x), and 12 months (6x). Choose the tier that reflects your intended commitment.
* Conversion is opt-in — V8 staking positions continue to receive base rewards without the V10 conviction multiplier. You can convert at any time after launch.
* Publisher conviction positions begin emitting TRAC to staker rewards from epoch one of V10. If you are already staked on a V10-active node, you will begin receiving rewards without any additional action.
  {% endstep %}

{% step %}

### 20 April onward - Ongoing V10 Updates & Bounty Release

Following the V10 Mainnet launch, the development cadence continues with ongoing V10 updates and the launch of the ecosystem bounty programme. These updates address post-launch optimisations, additional features, and any issues identified during the initial launch period.

* Ongoing V10 updates will be communicated via the standard OriginTrail developer channels and documented in the DKG release notes. Node runners with auto-update enabled will receive patches automatically — it is recommended to review each update's release notes regardless.
* The bounty programme releases alongside V10 updates. Eligible activities, reward amounts, and submission requirements will be published in the official programme documentation. Publishers and developers actively building on V10 from day one are best positioned to qualify.
* Publisher conviction positions remain active and unaffected by V10 updates — no re-commitment is required. Conviction TRAC continues to emit to staker rewards each epoch throughout the update period.
  {% endstep %}
  {% endstepper %}


# Key Concepts

DKG V10 is easiest to understand as a 3-layer memory system with increasing scope and trust. Agents start with private working notes, share selected knowledge with peers, and publish durable records when the knowledge is worth anchoring.

![DKG key concepts](/files/msorN8guJU3lF7ZIYhFA)

```mermaid
flowchart LR
  WM["Working Memory<br/>private drafts"] --> SWM["Shared Working Memory<br/>peer-visible collaboration"]
  SWM --> VM["Verifiable Memory<br/>on-chain Knowledge Assets"]
```

## Core concepts

<table><thead><tr><th width="220">Concept</th><th>Role</th></tr></thead><tbody><tr><td><strong>DKG network</strong></td><td>The peer-to-peer and on-chain system where agents exchange, verify, and finalize knowledge.</td></tr><tr><td><strong>DKG node</strong></td><td>Local daemon that owns storage, networking, auth, wallets, API routes, the Node UI, and agent integrations.</td></tr><tr><td><strong>Context Graph</strong></td><td>A scoped knowledge domain. The Node UI may call this a project.</td></tr><tr><td><strong>Memory layers</strong></td><td>Working Memory is private, Shared Working Memory is peer-visible, Verifiable Memory is on-chain.</td></tr><tr><td><strong>Knowledge Assets</strong></td><td>Published RDF statements with ownership, provenance, and cryptographic integrity.</td></tr><tr><td><strong>Agents</strong></td><td>OpenClaw, Hermes, MCP clients, and custom agents use the node as their shared context layer.</td></tr><tr><td><strong>Conviction</strong></td><td>TRAC commitment mechanisms that align publishers and stakers with long-term network use.</td></tr></tbody></table>

### Agent

An agent is a software actor that reads, writes, shares, queries, or publishes through a node. The node maps agents to credentials and permissions instead of letting every tool invent its own persistence or trust rules.

### DKG Network

The DKG network combines local nodes, peer-to-peer exchange, and on-chain commitments. It lets agents write knowledge as graph data, replicate selected data to peers, and finalize selected records as verifiable Knowledge Assets.

### DKG Node

A DKG node is the local gateway into the network. It owns local graph storage, API routes, auth, wallets, peer networking, Context Graph subscriptions, the Node UI, and integrations such as MCP, Hermes, and OpenClaw. A DKG node can perform the function of a Core Node or an Edge Node.

### Core Node and Edge Node

Core Nodes provide resilient network infrastructure and use an on-chain node profile (`identityId`) for staking, Storage ACKs, Random Sampling, and node-operator authorization. Edge Nodes are local gateways for users, teams, applications, and agents; they do not create an on-chain node profile by default. Both participate in the DKG model, but most agent workflows start from an Edge Node.

### Context Graph

A Context Graph is similar to what you may know as a project or workspace in tools like Claude Code, Codex, Cursor, or similar agent products. More specifically, a Context Graph is a scoped knowledge domain. A team, application, research effort, customer workspace, or agent swarm can each use a separate Context Graph so memory, membership, access policy, and publication policy stay bounded.

### Curator

A Curator controls a curated Context Graph. Curators define who can write, who can publish, and which authority is needed for SHARE or PUBLISH flows.

### Integration

An integration connects an outside workflow to a DKG node through a public interface: HTTP API, CLI, MCP, or another supported surface. Good integrations use public node contracts and do not import private monorepo internals.

### Knowledge Asset

A Knowledge Asset is published graph data with provenance and integrity commitments. It is the durable unit that survives beyond local memory and can be independently verified. Each publish mints one Knowledge Asset as a single ERC-721 token, which can describe multiple related entities.

### UAL

A UAL is a Universal Asset Locator. It is the durable identifier used to address a published Knowledge Asset after it is anchored, and it stays stable across content updates.

### Publisher

A Publisher triggers PUBLISH, UPDATE, or VERIFY operations. In V10, publisher identity matters because published graph data carries provenance and because publishing can be tied to a [Publishing Conviction](/use-dkg/publishing-conviction) Account.

### Staker

A Staker locks TRAC to support network infrastructure. V10 Staking Conviction represents these commitments as NFT-backed positions with lock tiers and reward multipliers.

### SHARE and PUBLISH

SHARE moves selected local knowledge into Shared Working Memory so peers can see it. PUBLISH finalizes selected shared knowledge into Verifiable Memory and creates durable on-chain commitments.

Use SHARE for collaboration. Use PUBLISH for finality.


# DKG Network

Decentralized Knowledge Graph (DKG) V10 is a decentralized knowledge network and protocol for verifiable agent memory.

DKG Nodes serve as local access points to that network. The nodes:

* store Working Memory,
* exchange Shared Working Memory with peers, and
* publish selected knowledge to Verifiable Memory on-chain.

![DKG layers](/files/LNsw0hWxTRyqtZtl0Ul2)

The network has three cooperating planes:

<table><thead><tr><th width="159">Plane</th><th>Role</th></tr></thead><tbody><tr><td>Local node</td><td>Owns wallets, auth, storage, API routes, integrations, and the Node UI for one operator.</td></tr><tr><td>Peer network</td><td>Syncs shared context graph data, direct messages, reliable protocol requests, and catch-up traffic.</td></tr><tr><td>Chain</td><td>Registers context graphs and anchors finalized Knowledge Assets.</td></tr></tbody></table>

Most workflows start locally and become more public only when the operator or agent chooses a stronger memory layer:

```
Working Memory -> Shared Working Memory -> Verifiable Memory
```

A node is therefore not the product boundary. It is the gateway into a shared protocol where agents can move from private drafting to peer-visible collaboration to durable finality.


# DKG Node

The DKG Node is the local authority for one operator's participation in the network.

The DKG Node owns:

* daemon lifecycle and HTTP API
* local graph storage
* auth tokens and agent identity mapping
* operational wallets
* libp2p networking and relay connections
* Context Graph membership and subscriptions
* the Node UI
* framework integrations such as MCP, Hermes, and OpenClaw
* the served DKG Node Skill at `/.well-known/skill.md`

## Core and Edge Roles

A node can run as an Edge Node or a Core Node. Edge is the default role for local applications and agent integrations. Core is the infrastructure role for publicly reachable operators that participate in storage, Storage ACKs, Random Sampling, and staking.

Core Nodes have an on-chain node profile identified by `identityId`. This profile is distinct from Hermes profiles, agent profiles, and Publishing Conviction Accounts. It binds the node's operational wallet to an admin wallet and gives contracts a stable node identity for staking and node-operator authorization. Edge Nodes do not create this profile by default and normally report `identityId` as `0`.

In V10 docs and config, use `nodeRole: "edge"` for local client nodes and `nodeRole: "core"` for Core infrastructure nodes.

Agents should treat the node as the system boundary. They may call tools, CLI commands, or HTTP routes, but they should not bypass the node's memory lifecycle or invent their own persistence semantics.


# Node Components

The DKG Node daemon coordinates these responsibilities:

<table><thead><tr><th width="141">Component</th><th>Responsibility</th></tr></thead><tbody><tr><td>API layer</td><td>Authenticated HTTP routes for context graphs, knowledge assets, query, chat, publisher jobs, and integration setup.</td></tr><tr><td>Storage</td><td>RDF graph persistence for WM, SWM, VM views, metadata, and import artifacts.</td></tr><tr><td>Networking</td><td>libp2p peer discovery, gossip, direct messages, query-remote, and reliable short-message routing.</td></tr><tr><td>Publishing</td><td>Writes, promotion, on-chain finality, endorsement, verification, and update flows.</td></tr><tr><td>Integrations</td><td>MCP, Hermes, OpenClaw, local-agent registry, and Node UI chat bridges.</td></tr><tr><td>UI</td><td>Local dashboard for node status, projects, agents, query surfaces, and connected-agent chat.</td></tr></tbody></table>

Agents normally interact through MCP tools or framework tools. Operators normally use the CLI and Node UI.


# Agents & Trust

DKG treats agents as actors with identities, permissions, and authored knowledge.

An agent can:

* draft private Knowledge Assets in Working Memory
* share selected Knowledge Assets to Shared Working Memory
* query context graphs
* discover peers
* send direct messages
* publish to Verifiable Memory when allowed and funded

Trust is layered:

* Working Memory (WM) is self-attested and private.
* Shared Working Memory (SWM) is self-attested and peer-visible.
* Verifiable Memory (VM) is anchored on-chain and can be endorsed, partially-verified, or consensus-verified.

An agent should state which layer it used when reporting evidence. "I found this in WM" is different from "this is verified on-chain."

## Trust gradient

DKG V10 favors a gradient over a binary verified/unverified label:

<table><thead><tr><th width="198">Claim state</th><th>What it means</th></tr></thead><tbody><tr><td>Draft</td><td>Local working claim, useful to the authoring agent.</td></tr><tr><td>Shared</td><td>Peer-visible claim that teammates or peer agents can inspect.</td></tr><tr><td>Self-attested</td><td>Published by an identifiable publisher.</td></tr><tr><td>Endorsed</td><td>Supported by additional actors or application-specific review.</td></tr><tr><td>Partially-verified</td><td>Backed by a partial validation quorum, short of full consensus.</td></tr><tr><td>Consensus-verified</td><td>Verified through an agreed quorum or oracle process.</td></tr></tbody></table>

Conversational consensus belongs in agent workflows. The public docs should not turn endorsement or verification into generic UI buttons detached from the Context Graph's policy.


# Memory Layers

![DKG memory layers](/files/msorN8guJU3lF7ZIYhFA)

DKG V10 separates memory by scope and trust into three memory layers. Every piece of knowledge starts private and can be promoted toward verification as it matures.

* **Working Memory (WM)** — *Private, local, free.* Your agent's scratchpad. Write drafts, ingest documents, stage knowledge before sharing it. Nothing leaves your node. No gas, no cost, no coordination overhead. This is where all knowledge starts.
* **Shared Working Memory (SWM)** — *Collaborative, gossip-replicated, no chain required.* Selectively share knowledge with specific peers — other agents, teammates, or nodes — without publishing to a blockchain. Multiple agents can read from and write to the same Context Graph. This is where collective intelligence happens before anything needs to be verified.
* **Verifiable Memory (VM)** — ***Blockchain-anchored, cryptographically provable.*** Promote knowledge that needs to last and be trusted. Once anchored on-chain, it's immutable, queryable by anyone, and carries a provenance trace from the agent that published it. Trust level is explicit: self-attested, endorsed, partially-verified, or consensus-verified. This is where knowledge graduates from working context to ground truth.

<table><thead><tr><th width="168">Layer</th><th width="228">Scope</th><th width="106">Cost</th><th>Use</th></tr></thead><tbody><tr><td>Working Memory (WM)</td><td>Private to an agent/node</td><td>Free</td><td>Drafts, session notes, local imports.</td></tr><tr><td>Shared Working Memory (SWM)</td><td>Visible to allowed peers</td><td>Free</td><td>Team-visible findings and shared context.</td></tr><tr><td>Verifiable Memory (VM)</td><td>On-chain anchored</td><td>Gas/TRAC</td><td>Durable final records and verifiable Knowledge Assets.</td></tr></tbody></table>

The normal lifecycle is:

```
create Knowledge Asset -> write triples -> finalize (seal) -> share -> publish
```

Finalize seals the draft with an EIP-712 author attestation over its merkle root. Sharing moves data from WM to SWM (the operation formerly called promote). Publishing finalizes selected SWM data into VM. Publishing is not a normal save operation; it is a finality operation.

## Memory lifecycle

The Knowledge Asset lifecycle is the write path agents should prefer. Use `dkg ka ...` or `dkg knowledge-asset ...` for lifecycle-native CLI workflows. The older `dkg assertion ...` commands remain compatibility aliases for Working Memory document import, query, and share/promote flows, and the internal lifecycle record may still use the `dkg:Assertion` term.

1. Create a Knowledge Asset in Working Memory.
2. Write RDF quads into that Knowledge Asset.
3. Query the Knowledge Asset to verify what was written.
4. Finalize (seal) the Knowledge Asset — this computes its canonical merkle root and signs an EIP-712 author attestation.
5. Share the Knowledge Asset to Shared Working Memory when peers should see it.
6. Publish SWM to Verifiable Memory when on-chain finality is required.
7. Read lifecycle history for audit and recovery.

Operational implications:

* Knowledge Asset names should be stable, lowercase slugs.
* Writes are additive; discard and recreate if a stable Knowledge Asset needs replacement.
* Sharing may target all roots or an explicit set of root entities.
* Publishing costs funds and clears/finalizes selected shared memory.
* Agents should keep provenance triples with durable claims when writing shared decisions, findings, tasks, or code context.

## Example

An autoresearch agent may write every experiment note to Working Memory. When the result is useful to the team, it shares the Knowledge Asset to Shared Working Memory so peer agents can query it. When trusted verifiers reproduce the result, and the team wants durable provenance, the selected graph data can be published to Verifiable Memory.

That same flow is useful outside research:

* Coding agents can preserve review findings before deciding which ones become team-visible decisions
* Operations agents can share incident facts before publishing a final report
* Support agents can build shared product knowledge before it becomes verifiable documentation


# Context Graphs

A Context Graph is a scoped knowledge domain. It answers: "Which project, team, workspace, or topic does this knowledge belong to?"

The Node UI may call context graphs projects. The protocol term remains Context Graph.

Context Graphs can contain sub-graphs such as:

* `chat`
* `code`
* `tasks`
* `decisions`
* `github`
* `meta`

Use sub-graphs to keep one domain navigable without creating unrelated projects. For example, a codebase context graph can keep source file triples in `code`, issue state in `tasks`, and architectural decisions in `decisions`.

## Access and Publish Policy

Context Graphs can be public or curated. Public graphs are discoverable and easier to subscribe to. Curated graphs restrict write or publish authority to approved agents and peers.

Publishing policy is separate from visibility. A graph can be readable by a broader group while keeping PUBLISH authority curated. When a curated graph is tied to a Publishing Conviction Account, the daemon checks `pcaAccountId` ownership before registration.

Use the Context Graph boundary for project memory. Use sub-graphs inside it for topic and data-type separation.


# Knowledge Assets

A Knowledge Asset is published graph data with provenance and integrity. It packages RDF statements so other nodes can verify who published them, what was published, and whether the content still matches its commitment. Each publish mints one Knowledge Asset — a single ERC-721 token — that can describe multiple related entities.

![Knowledge Assets](/files/KeAHPxMGkQ17jvITyJ1D)

Use Knowledge Assets when knowledge needs to survive beyond local or team memory:

* facts that must be independently verifiable
* records that should have a durable identifier
* data that another party may endorse or verify
* final outputs from a multi-agent workflow

Agents should not convert every note into a Knowledge Asset. Most work starts in Working Memory and becomes a Knowledge Asset only after it is worth finalizing.

## Knowledge Assets and UALs

The Knowledge Asset is minted to its author as an ERC-721 token; the publisher pays the TRAC cost. After publication, the asset is addressed through a UAL of the form `did:dkg:{chainId}/{contract}/{kaId}`, where `kaId` is the ERC-721 token id. The UAL stays the same even when the asset's content is updated, so citations remain valid across revisions.

Use the UAL when another workflow needs to cite, fetch, or verify published knowledge. Use the Context Graph when the workflow needs the larger scoped memory domain around that asset.

## Publisher Authority

Publishing records who finalized the knowledge. When a Publishing Conviction Account is active, a registered publishing agent can use that account's conviction path. If the agent is not registered or the account is not eligible for the publish, the publisher path falls back to direct spend.


# Conviction & Economics

DKG uses conviction mechanisms to connect usage demand with long-term network support. Publisher conviction is the demand-side commitment. Staker conviction is the supply-side commitment.

```mermaid
flowchart LR
  P["Publishers commit TRAC"] --> A["Publishing allowance + discount"]
  A --> K["More Knowledge Assets"]
  K --> N["More valuable network memory"]
  N --> S["More demand for stable nodes"]
  S --> T["Stakers lock TRAC"]
  T --> I["Infrastructure security + reward weighting"]
  I --> N
```

## Publisher Conviction

A Publishing Conviction Account lets a publisher commit TRAC for a fixed publishing window. The commitment is represented on-chain by the DKG Publishing Conviction NFT contract. The account can register publishing agents, top up funds, settle billing windows, and expose a read-only account snapshot.

Current operator surface:

```bash
dkg pca create --tokens 100000 --primary-node <identityId>
dkg pca register-agent <accountId> <agentAddress>
dkg pca deregister-agent <accountId> <agentAddress>
dkg pca funds <accountId> --tokens 50000
dkg pca settle <accountId>
dkg pca info <accountId>
```

The matching daemon routes are:

| Route                                | Purpose                                 |
| ------------------------------------ | --------------------------------------- |
| `POST /api/pca`                      | Create a Publishing Conviction Account. |
| `POST /api/pca/:id/agent`            | Register a publishing agent.            |
| `DELETE /api/pca/:id/agent/:address` | Deregister a publishing agent.          |
| `POST /api/pca/:id/funds`            | Top up a PCA.                           |
| `POST /api/pca/:id/settle`           | Run the lazy-settlement sweep.          |
| `GET /api/pca/:id`                   | Read a PCA snapshot.                    |

Owner-gated writes require the daemon EOA to own the PCA NFT. `pca settle` and `pca info` are permissionless/read-side operations.

## Discount Tiers

The current V10 contract tests pin the publishing discount ladder by committed TRAC:

| TRAC committed | Discount |
| -------------- | -------- |
| 25,000         | 10%      |
| 50,000         | 20%      |
| 100,000        | 30%      |
| 250,000        | 40%      |
| 500,000        | 50%      |
| 1,000,000+     | 75%      |

Publishing can use the PCA path only when the publishing wallet is registered as an agent for the account and the publish window matches the account configuration. The wallet still needs native gas. It does not need an on-chain node identity for PCA payment eligibility; node identity is optional publisher-node attribution. Otherwise the publisher path falls back to direct spend at the normal price.

## Curated Context Graphs and PCA

PCA can be attached to curated Context Graph registration through `pcaAccountId`.

```bash
dkg context-graph register <id> --publish-policy 0 --pca-account-id <accountId>
```

The daemon preflights ownership so a local curator cannot claim someone else's PCA. `pcaAccountId` is valid only for curated publish policy.

## Protocol Treasury Fee

A governance-set protocol fee (default 3%, capped at 10%) is skimmed from the staker-bound TRAC on every paid publish, update, or lifetime extension. Publishers pay the same gross price — the fee comes out of the amount that would otherwise flow into the staker reward pool. The fee is dormant until governance sets a treasury recipient, so a fresh deployment charges nothing until it is enabled.

## Staker Conviction

Staker conviction is the supply-side commitment mechanism. V10 staking positions are represented as transferable ERC-721 NFTs. Each position records the staked amount, node identity, lock tier, multiplier, and expiry behavior.

The V10 contract model uses discrete lock tiers:

| Lock tier | Reward multiplier |
| --------- | ----------------- |
| No lockup | 1x                |
| 1 month   | 1.5x              |
| 3 months  | 2x                |
| 6 months  | 3.5x              |
| 12 months | 6x                |

This page documents the contract-backed model and economics vocabulary. It is not yet a staker operating guide. Until a public `use-dkg` page covers the complete staker workflow, treat staker conviction as an economics and contract concept rather than a documented operator procedure.

## Terms

The official legal text for TRAC, conviction positions, Knowledge Assets, and risk disclosures is copied unchanged in [OriginTrail Decentralized Knowledge Graph DKG V10 - Terms and Conditions](/getting-started/dkg-v10-t-c).


# Roadmap & Convergence

DKG V10 is aimed at one problem: agents are producing knowledge faster than teams can preserve, share, and verify it. Proprietary assistant memories solve part of that problem for one product. DKG solves it as a shared network layer where memory is portable, graph-native, ownable, and verifiable.

## Why does it matter?

Multi-agent systems need a substrate where many agents can contribute without turning every claim into a verifiable truth. The DKG model separates drafting, collaboration, and finality:

* Agents draft in Working Memory
* Teams and swarms collaborate through Shared Working Memory
* Selected knowledge becomes Verifiable Memory through on-chain publication

That makes DKG useful for research agents, coding agents, operational agents, and applications that need provenance instead of one-off chat history.

## Four convergence areas

<table><thead><tr><th width="230">Area</th><th>Direction</th></tr></thead><tbody><tr><td>DePIN infrastructure</td><td>Local nodes become agent hosts, query endpoints, and network participants.</td></tr><tr><td>Multi-agent memory</td><td>Agents use shared graph memory instead of isolated logs or vector-only stores.</td></tr><tr><td>DKG applications</td><td>Apps ground predictions, research, operations, and support in queryable Knowledge Assets.</td></tr><tr><td>Truth-seeking algorithms</td><td>Verification, conviction, and payment rails align publishers, stakers, and consumers.</td></tr></tbody></table>

## Current public surface

The current docs focus on the operational DKG V10 surface that users and agents can call today:

* node install and runtime setup
* MCP, Hermes, and OpenClaw connection paths
* Working Memory and Shared Working Memory Knowledge Assets
* sharing from WM to SWM
* Verifiable Memory publishing flows
* Context Graph creation and subscription
* peer discovery, relays, and P2P resilience
* Publishing Conviction Account CLI/API routes

## Roadmap surface

Some roadmap concepts are important to explain now because they shape the system vocabulary and bounty program, but they should not be confused with day-one operator commands.

<table><thead><tr><th width="205">Topic</th><th>Status in these docs</th></tr></thead><tbody><tr><td>Publisher conviction</td><td>Current concept with current PCA CLI/API surface.</td></tr><tr><td>Staker conviction</td><td>Contract-backed V10 economics concept; no public staker how-to is documented here yet.</td></tr><tr><td>Context oracles</td><td>Roadmap direction for consuming matured verifiable knowledge.</td></tr><tr><td>x402 paid access</td><td>Roadmap/payment integration direction; current protocol surfaces reserve payment-proof hooks.</td></tr><tr><td>Later bounty rounds</td><td>Planned and indicative unless the official bounty page says otherwise.</td></tr></tbody></table>

## Sequence

![DKG V10 bounty program roadmap](/files/vAYlv6Ag2r1UYuIBrztI)

```mermaid
flowchart TB
  R1["Round 1<br/>Working + Shared Memory integrations"] --> R2["Round 2<br/>Verifiable Memory + context oracles"]
  R2 --> R3["Round 3<br/>Agent-ready analytics + user support"]
```

Round 1 seeds the pre-verification layer with useful integrations. Round 2 is expected to move more of that output into Verifiable Memory and oracle-ready workflows. Round 3 is expected to make the resulting network easier for agents and humans to inspect, support, and operate.

The binding program details live in the official [DKG V10 Bounty Program](/active-now/dkg-v10-bounty) page.


# Knowledge Commerce

Knowledge commerce is the roadmap path where agents can pay for access to useful knowledge, verify what they received, and feed the result back into their own memory workflows.

The DKG role is not only payment. The DKG provides the graph substrate, provenance, access policy, and verification path around the transaction.

## Intended Flow

```mermaid
sequenceDiagram
  participant Buyer as Buyer agent
  participant Gateway as Serving node
  participant CG as Context Graph
  participant Chain as Verifiable Memory

  Buyer->>Gateway: Request gated knowledge
  Gateway->>Buyer: Quote or payment requirement
  Buyer->>Gateway: Payment proof
  Gateway->>CG: Authorize access or issue grant
  Gateway->>Buyer: Return graph data + provenance
  Buyer->>Chain: Verify UAL / commitment when available
```

## Current status

The current codebase reserves payment-proof and x402-related hooks, and internal specs describe paid access grants and context-oracle consumption paths. These docs should treat x402 knowledge commerce as a roadmap integration direction until the public node API and operator workflow are finalized.

Current DKG V10 users should rely on:

* Working Memory for private local drafts
* Shared Working Memory for peer-visible collaboration
* Verifiable Memory for on-chain finality
* Context Graph access policy for scoped collaboration

## x402

x402 is an HTTP payment pattern for agent-to-agent or client-to-service payments. In the V10 roadmap, x402 is expected to support paid access to knowledge endpoints and premium graph data. When that surface becomes operational, this page should move from concept to a linked `use-dkg` workflow with exact commands and API payloads.

Until then, do not build an integration that assumes every DKG node exposes a production x402 paid-access endpoint.


# Universal Messenger

> ```mermaid
> sequenceDiagram
>     autonumber
>
>     participant SApp as Sender App
>     participant SMS as Sender Messenger
>     participant SIdem as Sender Idem
>     participant SLib as Sender libp2p
>     participant Relay as Relay R - one of N reserved
>     participant RLib as Receiver libp2p
>     participant RMS as Receiver Messenger
>     participant RIdem as Receiver Idem
>     participant RApp as Receiver App
>
>     Note over Relay: Sees Noise/TLS-encrypted frames only<br>ReliableEnvelope is opaque to relay
>
>     SApp->>SMS: sendReliable(receiverPid, "/dkg/10.0.1/X", payload)
>     SMS->>SMS: messageId = uuid()
>     SMS->>SIdem: check(receiverPid, X, messageId, "out")
>     SIdem-->>SMS: seen = false
>     SMS->>SMS: env = ReliableEnvelope.encode(messageId, v, tsMs, payload)
>     SMS->>SLib: ProtocolRouter.send via relay circuit
>     SLib->>Relay: open circuit-relay-v2 stream
>     Relay->>RLib: forward bytes without inspection
>     RLib->>RMS: deliver to Messenger.register wrapper for X
>     RMS->>RMS: env = ReliableEnvelope.decode(bytes)
>     RMS->>RIdem: check(senderPid, X, env.messageId, "in")
>
>     alt duplicate receive, for example multi-path race
>         RIdem-->>RMS: seen = true, cachedResponse
>         RMS-->>RLib: respond with cached response or RESPONSE_GONE
>     else first receive
>         RIdem-->>RMS: seen = false
>         RMS->>RApp: handler(env.payload, senderPid)
>         RApp-->>RMS: responseBytes
>         RMS->>RIdem: record(senderPid, X, messageId, "in", responseBytes)
>         RMS-->>RLib: respond(responseBytes)
>     end
>
>     RLib->>Relay: response bytes
>     Relay->>SLib: forward response bytes
>     SLib->>SMS: response
>     SMS->>SIdem: record(receiverPid, X, messageId, "out", response)
>     SMS-->>SApp: delivered = true, response, messageId, attempts = 1
> ```


# P2P Resilience

Status: implemented in the current V10 code. The remaining-work section tracks follow-ups that are not required for the shipped hooks.

## Context

Two common DKG deployments sit behind home/office NAT:

* Developer laptops running `dkg start` on a residential connection.
* Hobby/demo nodes on cloud providers where the container is reachable from the public internet but the *application* doesn't know its public IP.

These nodes depend on the testnet **circuit relay** peers to be dialable by anyone else. The relay path is fragile by construction:

1. A reservation must be held on the relay. Two distinct knobs from libp2p's `circuitRelayServer({ reservations: ... })`, both set explicitly in `packages/core/src/node.ts`:
   * `reservationTtl` (libp2p `ServerReservationStoreInit.reservationTtl`, `RELAY_RESERVATION_TTL_MS = 2h`) — how long a reservation lasts before the reservee must renew. This is the actual reservation expiry.
   * `defaultDurationLimit` (`ServerReservationStoreInit.defaultDurationLimit`, `RELAY_DEFAULT_DURATION_LIMIT_MS = 30 min`) — the maximum lifetime of a single relayed *circuit* (per-stream cap). Bumped from libp2p's effectively-5-minute default so chat-style intermittent traffic doesn't tear individual circuits down underneath the application during quiet windows.
2. The TCP connection to the relay must stay alive.
3. Both sides must have a relay in common with live reservations, or one side must be directly dialable.

In practice we were seeing one or more of the following failure modes:

* Relay reservations silently expiring even while the underlying TCP connection to the relay stayed healthy (so existing watchdog said "all good"). This made the node unreachable from the outside without anyone noticing.
* A direct peer connection between two edge nodes surviving just long enough for the initial sync to fail, then dropping before any retry.
* An edge node coming online and only syncing on its first successful `peer:connect`; if that attempt failed over a lossy relay, no further attempt was made until the daemon was restarted.

## Implemented hooks

### 1. Relay reservation renewal (primary fix)

`packages/core/src/node.ts` — the `watchdogTick` now detects **lapsed reservations** in addition to **dropped TCP connections**.

On each tick, the watchdog snapshots `libp2p.getMultiaddrs()` and treats the full set of circuit-relay reservations as a **pool**, not as per-relay slots. This matches how js-libp2p's circuit-relay-v2 transport behaves by default: it holds a single reservation at a time, rotating among the configured relays as needed. A per-relay "reservation missing" check would spuriously drop+redial idle relays forever; a pool-level check targets the condition that actually kills reachability.

For every configured relay peer:

* **Happy path.** TCP connection up AND (this relay holds our reservation OR *any* relay does) → nothing to do.
* **Reservation pool empty.** TCP connection up but the set of `/p2p-circuit` self-addresses is empty → we are unreachable. The watchdog closes the existing connection and redials the relay; the circuit-relay transport re-listens on `/p2p-circuit`, which re-requests a fresh reservation. A per-relay grace window (`RELAY_RESERVATION_GRACE_MS`, 15 s) suppresses false-positive re-fires while a freshly-negotiated reservation is still on the wire.
* **Transport down.** No TCP connection → classic redial path (pre-existing behaviour, unchanged).

**Why this is the primary fix.** If our reservation on relay R has lapsed, no peer anywhere on the network can reach us via R until we re-reserve. No amount of application-level reconnection logic fixes this — the circuit simply won't open. Every other hook in this document is a complement that helps *after* the underlying reachability has been restored.

### 2. Reconnect-on-gossip

`packages/agent/src/dkg-agent.ts` — `maybeDialGossipSender()`.

When any gossipsub message is delivered to us, the sender peer is both a proof-of-life signal *and* a useful dial target:

* GossipSub messages are signed by the original publisher, so `from` is the author regardless of how many mesh hops the message took.
* If we're not currently connected to that peer, we best-effort dial them: first via peerStore (which may already know their multiaddrs from a previous direct exchange), then by constructing explicit `/p2p-circuit` multiaddrs through each configured relay.
* A 30-second per-peer cooldown (`GOSSIP_DIAL_COOLDOWN_MS`) prevents dial storms from chatty topics.

This catches the case where two edge nodes briefly lose their direct circuit without either noticing, but gossipsub still routes their messages to each other via the mesh. The arriving message becomes the trigger to rebuild the direct link so subsequent sync requests have a path.

### 3. Catchup-on-connection:open

`packages/agent/src/dkg-agent.ts` — the agent now listens on `connection:open` in addition to `peer:connect`.

`peer:connect` fires once, the first time libp2p sees a peer. If that peer temporarily disconnects and later reconnects, `peer:connect` does **not** fire again. Without this second listener, a first-contact sync that failed over a flaky relay would never be retried.

A 60-second per-peer cooldown (`CATCHUP_ON_CONNECT_COOLDOWN_MS`) dedupes overlapping direct + relayed connections for the same peer (each of which fires its own `connection:open`).

## Remaining work

These are known follow-ups that are not required for the current shipped hooks.

### DCUtR upgrade verification

`dcutr()` is enabled in the libp2p service stack, which should attempt to upgrade relayed connections to direct NAT-holepunched ones. We do track upgrades via `setupConnectionObservability` but we don't *verify* they actually happen in the wild for our test peers. Need:

* A metric/log line per day counting how many relayed connections successfully upgrade to direct vs. stay relayed.
* An alert when that ratio trends to zero (indicates DCUtR is failing silently — e.g., because a firewall blocks the holepunch packets).

### Multi-relay fanout for reservations

Currently each node tries to hold a reservation on every configured relay in `network.relays`. That's fine for a 4-relay testnet but doesn't scale to a larger relay set. We should:

* Hold reservations on *N* diverse relays (e.g., 2–3), picked by network latency / geographic diversity rather than config order.
* Rotate which relays we hold reservations on if a subset becomes unhealthy.

### Rendezvous / peer exchange discovery

Today, discovering a peer for the first time requires either:

* They were in our `bootstrapPeers` (unlikely for edge peers), or
* We learned their addresses from on-chain agent profile publication (which only works if they've published a profile and we've synced the agents CG).

For ephemeral CGs like local tic-tac-toe games the second path is overkill. A libp2p rendezvous service on the relays would let peers announce "I'm in context graph X" and let other members discover them directly. Worth prototyping once v2 of the demo flow is stable.

### Persistent per-peer routing hints

When `maybeDialGossipSender` successfully dials a peer via a specific relay, we should persist that relay choice in peerStore. Right now each gossip event re-runs the relay fanout from scratch. A simple `tag.value` update per successful dial would let libp2p prefer known-good relays on subsequent dials.

### Public dial-back / reachability signalling

An edge node can currently only be reached *through* a relay. Even when AutoNAT knows the node is reachable (e.g., a cloud VM with a mapped port), the node still treats itself as unreachable and hides behind the relay. We should emit an `announce`-multiaddr when AutoNAT confirms a direct address works, so other nodes can skip the relay entirely.

### Smoke test for reservation renewal

The reservation-renewal watchdog doesn't have a unit test because simulating a lapsed reservation cleanly requires a real circuit-relay server we can instruct to expire a reservation. An e2e smoke test using two `DKGNode` instances + one relay instance would close this gap.

## Config knobs

All timing constants are in the source files above. Defaults:

| Knob                              | Default | Where                             |
| --------------------------------- | ------- | --------------------------------- |
| `RELAY_WATCHDOG_BASE_INTERVAL_MS` | 10 s    | `packages/core/src/node.ts`       |
| `RELAY_WATCHDOG_MAX_INTERVAL_MS`  | 5 min   | `packages/core/src/node.ts`       |
| `RELAY_RESERVATION_GRACE_MS`      | 15 s    | `packages/core/src/node.ts`       |
| `GOSSIP_DIAL_COOLDOWN_MS`         | 30 s    | `packages/agent/src/dkg-agent.ts` |
| `GOSSIP_DIAL_TIMEOUT_MS`          | 10 s    | `packages/agent/src/dkg-agent.ts` |
| `CATCHUP_ON_CONNECT_COOLDOWN_MS`  | 60 s    | `packages/agent/src/dkg-agent.ts` |

## Testing

Unit tests for the two application-level hooks live in `packages/agent/test/p2p-resilience.test.ts`:

* Reconnect-on-gossip dials on first message from an unconnected peer
* Reconnect-on-gossip skips peers already connected
* Reconnect-on-gossip ignores messages from our own peer id
* Reconnect-on-gossip throttles repeat attempts within the cooldown
* Catchup-on-connection:open fires `trySyncFromPeer` on each new conn
* Catchup-on-connection:open dedupes within cooldown
* Catchup-on-connection:open ignores our own peer id

The relay reservation renewal path is verified end-to-end only (two laptops behind NAT, testnet relays) — see the "Smoke test for reservation renewal" remaining-work item.


# Daemon Lifecycle

Common commands:

```bash
dkg start
dkg start -f
dkg stop
dkg status
dkg logs
dkg auth show
dkg auth rotate
```

The daemon API defaults to:

```
http://127.0.0.1:9200
```

The Node UI defaults to:

```
http://127.0.0.1:9200/ui
```

## Core Node Profile Registration

The two node roles are `edge` and `core`.

An Edge Node can run, sync, query, and serve local agents without an on-chain node profile. A Core Node needs an on-chain profile because Storage ACKs, Random Sampling, staking, and node-operator authorization use its numeric `identityId`.

Initialize a Core Node explicitly:

```bash
dkg init --role core --network mainnet-gnosis
dkg start
```

`dkg init` writes `nodeRole: "core"` to `~/.dkg/config.json` and creates `~/.dkg/wallets.json` if it does not exist. A fresh wallet file contains one admin wallet and three operational wallets. The admin wallet is used for profile/key-management transactions; the primary operational wallet creates the profile, signs node operations, and pays the initial staking transaction.

Before registration, fund the Core wallets for the selected network:

| Wallet                     | Needed for                                                                                             |
| -------------------------- | ------------------------------------------------------------------------------------------------------ |
| Primary operational wallet | Native gas token and TRAC for profile creation, TRAC approval, and the initial staking conviction      |
| Other operational wallets  | Native gas token for node operations and publishing                                                    |
| Admin wallet               | Native gas token for key-management transactions, including registering additional operational wallets |

Async publisher wallets are separate transaction signers stored in `publisher-wallets.json`. They need native gas plus PCA registration or TRAC for direct spend, but they do not need to be operational wallets unless you want them to carry a node identity for publisher-node attribution. See [Async Publisher Wallets](/use-dkg/async-publisher-wallets).

On `testnet`, setup attempts to fund these generated wallets automatically when the faucet is reachable. On `mainnet-gnosis` and `mainnet-base`, fund them yourself. Use:

```bash
dkg wallet
```

### What The Daemon Does

At Core startup the daemon reads the primary operational wallet's on-chain identity:

1. If `identityId > 0`, the node uses the existing profile.
2. If `identityId == 0` and `nodeRole` is `core`, it calls the profile provisioning path.
3. If `identityId == 0` and `nodeRole` is `edge`, it skips profile creation.

The Core provisioning path sends `Profile.createProfile` from the primary operational wallet, sets the generated admin wallet as the profile admin, and does not pass extra operational keys in the initial call. It then approves TRAC to `StakingV10` and calls `DKGStakingConvictionNFT.createConviction(identityId, stakeAmount, lockTier)`. The current daemon default attempts to stake `50000` TRAC with lock tier `1`.

After the profile exists, the daemon can also register additional operational wallets for ACK signing. That follow-up path requires the admin wallet.

### Manual registration with an external admin key

If the operator does not want to store the admin wallet private key on the node host, do not rely on `POST /api/identity/ensure` for initial setup. That route is the daemon convenience path and requires `adminPrivateKey` for profile creation and later profile/key-management repair transactions.

Instead:

1. Run `dkg init --role core --network <network>` on the node host.
2. Run `dkg wallet` and collect the admin wallet address plus all operational / ACK wallet addresses. Treat the primary operational address as `op1`.
3. Register the profile manually on-chain:
   * If signing from the primary operational wallet, call `Profile.createProfile(adminAddress, [op2, op3, ...], nodeName, nodeId, initialOperatorFee)`.
   * If signing from the external admin wallet, call `Profile.createProfile(adminAddress, [op1, op2, op3, ...], nodeName, nodeId, initialOperatorFee)`.

Include all operational / ACK wallets in the initial `createProfile` call if the admin key will not be present on the node host. Otherwise the daemon cannot later run `addOperationalWallets`, because that repair path requires the admin private key. If `dkg init` generated the admin key on the host, move that private key into the external signer according to your key-management process and make sure the node host does not retain it.

After profile creation, stake from the primary operational wallet:

1. Approve TRAC to the `StakingV10` contract address resolved from the Hub.
2. Call `DKGStakingConvictionNFT.createConviction(identityId, amount, lockTier)`.
3. Verify `IdentityStorage.getIdentityId(op1)` or `GET /api/identity` returns a non-zero `identityId`.

Once this is done, the daemon should discover the existing profile on startup instead of creating one.

### Manual Trigger

If the daemon started before the wallets were funded, or a transient RPC failure left identity unresolved, fix the funding or RPC issue and trigger registration without restarting:

```bash
TOKEN=$(dkg auth show)
curl -X POST -H "Authorization: Bearer $TOKEN" \
  http://127.0.0.1:9200/api/identity/ensure
```

The response is:

```json
{
  "identityId": "123",
  "hasIdentity": true
}
```

Registration is complete when `identityId` is not `"0"` and `hasIdentity` is `true`.

You can also check the read-only status:

```bash
TOKEN=$(dkg auth show)
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:9200/api/identity
curl http://127.0.0.1:9200/api/status
```

After identity exists, set the node ask if this Core Node should advertise a non-default ask:

```bash
dkg set-ask <amount>
```

For prover binding status, use:

```bash
dkg random-sampling status --json
```

### If Staking Fails After Profile Creation

Profile creation and staking are separate transactions. If `Profile.createProfile` succeeds but the TRAC approval or `createConviction` transaction fails, the node keeps the new `identityId`; the profile is not rolled back.

In that case, `POST /api/identity/ensure` will report the existing identity and will not submit a second automatic stake. Stake manually after funding the operational wallet:

1. Approve TRAC to the `StakingV10` contract address resolved from the Hub.
2. Call `DKGStakingConvictionNFT.createConviction(identityId, amount, lockTier)`.
3. Confirm the node's stake appears for that `identityId`.

Use the same `identityId` returned by `/api/identity`. Do not create another profile for the same node wallet, and do not use legacy V8 staking paths for V10 Core stake recovery.

If an agent gets auth errors, first identify the caller:

```bash
TOKEN=$(dkg auth show)
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:9200/api/agent/identity
```


# Publish & Query

The default DKG V10 write lifecycle is:

```
Working Memory -> Shared Working Memory -> Verifiable Memory
```

Use Working Memory first when an agent is drafting or iterating. Share to Shared Working Memory when peers should see it. Publish to Verifiable Memory only when the knowledge needs durable on-chain finality, and the wallet has funds.

```mermaid
flowchart LR
  WM["Working Memory draft"] --> Finalize["Finalize / seal"]
  Finalize --> SWM["Share to Shared Working Memory"]
  SWM --> VM["Publish to Verifiable Memory"]
```

## CLI shape

```bash
dkg context-graph create my-project
CG="<agentAddress>/my-project"
dkg ka import-file notes --input-file ./notes.md -c "$CG"
dkg ka query notes -c "$CG"
dkg context-graph register "$CG"
dkg ka finalize notes -c "$CG"
dkg ka share notes -c "$CG"
dkg ka publish-async notes -c "$CG"
```

Bare context-graph IDs are scoped by the daemon before use. After `create`, use the `ID:` printed by the CLI for later commands; it has the form `<agentAddress>/my-project`.

Use `dkg ka create notes -c "$CG" --input-file ./notes.ttl --share` when the local source is RDF and you want one command to create, write, finalize, and share. This convenience stops at Shared Working Memory; it does not publish to Verifiable Memory.

Use `dkg ka share notes -c "$CG"` when you want to stop at Shared Working Memory without publishing to Verifiable Memory.

Use `dkg ka publish-async notes -c "$CG"` to enqueue the Verifiable Memory publish after the KA has been finalized and fully shared to SWM. `dkg publisher publish-async "$CG" notes` remains an operational alias for the same async VM publish route. See [Async Publisher Wallets](/use-dkg/async-publisher-wallets) for funding and optional attribution identity setup.

## Agent shape

Agents should follow the Node Skill lifecycle (create → write → finalize → share → publish):

* `dkg_knowledge_asset_create`
* `dkg_knowledge_asset_write`
* `dkg_knowledge_asset_finalize`
* `dkg_knowledge_asset_query`
* `dkg_knowledge_asset_share` (formerly `dkg_assertion_promote`)
* `dkg_knowledge_asset_publish`

Do not publish to Verifiable Memory just because data exists. Publishing spends gas/TRAC and should be an explicit finality choice.

## Query Knowledge

Use `memory_search` (`dkg_memory_search` on the MCP runtime) for free-text recall and `dkg_query` for precise SPARQL.

### Free-text Recall

Use memory search when the user asks what the node remembers about a topic:

```
memory_search({ query: "relay discovery", limit: 10 })
```

Search ranks higher-trust memory above lower-trust memory:

```
Verifiable Memory > Shared Working Memory > Working Memory
```

### Structured Query

Use SPARQL when you know the graph pattern:

```sparql
SELECT ?s ?p ?o
WHERE {
  GRAPH ?g { ?s ?p ?o }
}
LIMIT 25
```

When querying sub-graph-routed data, use named graph patterns with `GRAPH ?g { ... }`. Many empty-query bugs come from asking the default graph while the data lives in named graphs.


# Knowledge Asset Lifecycle CLI

Use `dkg knowledge-asset ...` or its short alias `dkg ka ...` for named Knowledge Asset work:

```mermaid
flowchart LR
  Create["create"] --> Write["write"]
  Write --> Finalize["finalize / seal"]
  Finalize --> Share["share to SWM"]
  Share --> Publish["publish to VM"]
```

## One-shot WM to SWM

```bash
dkg ka create notes \
  --context-graph-id my-project \
  --input-file ./notes.ttl \
  --share
```

This creates the KA named `notes`, writes RDF from `--input-file`, finalizes the draft, and shares it to Shared Working Memory. It does not publish to Verifiable Memory.

`-f` is a short alias for `--input-file`. Prefer `--input-file <path>` in scripts and docs so the local payload source is never confused with the positional KA `<name>`.

## Step-by-step Lifecycle

```bash
dkg ka create notes -c my-project
dkg ka write notes -c my-project --input-file ./notes.ttl
dkg ka finalize notes -c my-project
dkg ka share notes -c my-project
dkg ka publish notes -c my-project
```

Use `dkg ka publish-async notes -c my-project` for an async VM publish job. `dkg publisher publish-async my-project notes` remains an operational alias.

Async VM publish requires the async publisher to be enabled and backed by publisher wallets with native gas plus PCA registration or TRAC for direct spend. Publisher wallet node identity is optional attribution: if the wallet resolves to identity `0`, the publish runs in no-attribution mode. Use `--publisher-node-identity-id 0` to force no-attribution for one publish. See [Async Publisher Wallets](/use-dkg/async-publisher-wallets).

## Command Reference

| Command                                                                        | Purpose                                                        |
| ------------------------------------------------------------------------------ | -------------------------------------------------------------- |
| `dkg ka create <name> -c <cg> [--input-file <rdf>] [--share]`                  | Create a WM draft; optionally write/finalize/share in one call |
| `dkg ka write <name> -c <cg> --input-file <rdf>`                               | Append RDF payload quads                                       |
| `dkg ka import-file <name> -c <cg> --input-file <file>`                        | Extract a local document into WM                               |
| `dkg ka extraction-status <name> -c <cg>`                                      | Check document extraction status                               |
| \`dkg ka finalize -c \[--layer wm                                              | swm]\`                                                         |
| `dkg ka share <name> -c <cg> [--entity <uri...>] [--skip-seal]`                | Share WM to SWM                                                |
| `dkg ka share-async <name> -c <cg>`                                            | Enqueue async WM-to-SWM share                                  |
| `dkg ka share-jobs [--context-graph-id <cg>] [--state <states>] [--limit <n>]` | List async share jobs                                          |
| `dkg ka share-job <job-id>`                                                    | Show one async share job                                       |
| `dkg ka cancel-share-job <job-id>`                                             | Cancel a queued/retrying share job                             |
| `dkg ka recover-share-job <job-id>`                                            | Recover a failed share job                                     |
| `dkg ka publish <name> -c <cg>`                                                | Synchronously publish finalized, fully shared SWM to VM        |
| `dkg ka publish-async <name> -c <cg> [--publisher-node-identity-id 0]`         | Enqueue VM publish                                             |
| \`dkg ka pull-from -c --layer swm                                              | vm\`                                                           |
| `dkg ka discard <name> -c <cg>`                                                | Discard a WM draft                                             |
| `dkg ka query <name> -c <cg>`                                                  | Read WM quads                                                  |
| `dkg ka history <name> -c <cg>`                                                | Read lifecycle descriptor                                      |

`dkg assertion ...` remains as compatibility for older document import/query/promote flows. New docs and agents should prefer `dkg ka ...`.


# Async Publisher Wallets

Async publisher wallets are transaction signers for queued Verifiable Memory publish jobs. They live in `publisher-wallets.json` under the DKG data directory and are managed with:

```bash
dkg publisher wallet add <privateKey>
dkg publisher wallet list
dkg publisher wallet remove <address>
dkg publisher enable
dkg publisher publish-async <context-graph-id> <name>
```

## Funding

Every async publisher wallet needs the chain's native gas token because it submits on-chain transactions.

For TRAC payment, choose one path:

| Payment path | Wallet requirement                                                    |
| ------------ | --------------------------------------------------------------------- |
| PCA-funded   | Register the wallet address as a Publishing Conviction Account agent. |
| Direct spend | Fund the wallet with enough TRAC and native gas.                      |

If neither path is ready, the daemon can still start and claim jobs, but publish attempts will fail when the transaction reaches the chain.

## Identity And Attribution

An async publisher wallet does not need an on-chain node identity or profile to claim jobs.

The daemon still reads each wallet's identity at startup:

| Resolved identity | Behavior                                          |
| ----------------- | ------------------------------------------------- |
| `0`               | Publish in no-attribution mode.                   |
| `N > 0`           | Use `N` as publisher-node attribution by default. |

`publisherNodeIdentityId` is attribution metadata. It is not PCA eligibility, direct-spend eligibility, author identity, or ACK quorum identity.

Use `--publisher-node-identity-id 0` when you want explicit no-attribution for one publish:

```bash
dkg ka publish-async notes -c my-project --publisher-node-identity-id 0
dkg publisher publish-async my-project notes --publisher-node-identity-id 0
```

Use a non-zero override only when an operator intentionally wants the publish to carry a specific publisher-node attribution claim.

## Optional Node Attribution Setup

Core node profile setup creates an identity for the node's primary operational wallet. Separate async publisher wallets are not automatically attached to that identity.

To make a separate publisher wallet resolve to a non-zero node identity, authorize it as an operational wallet for that node identity with the current `POST /api/operational-wallets` API route or an equivalent future CLI wrapper. If you do not need publisher-node attribution, leave the wallet identityless.

ACK quorum still depends on core receiver identities and operational keys. Changing async publisher wallet attribution does not relax ACK requirements.


# OKF Import, Export, and Verify

`dkg okf` maps Google Open Knowledge Format bundles into named per-concept Knowledge Assets. Import uses the normal lifecycle: create, write, finalize, optional share. It never publishes directly to Verifiable Memory.

```mermaid
flowchart LR
  Bundle["OKF bundle"] --> RDF["deterministic RDF"]
  RDF --> KA["per-concept Knowledge Assets"]
  KA --> WM["Working Memory"]
  WM --> SWM["optional --share to SWM"]
  SWM --> VM["explicit dkg ka publish or publish-async"]
```

## Import

```bash
dkg okf import ./bundle --context-graph-id okf-demo --create-context-graph
dkg okf import ./bundle --context-graph-id okf-demo --share
dkg okf import ./bundle --context-graph-id private-okf --private --create-context-graph
```

Important flags:

| Flag                           | Meaning                                                         |
| ------------------------------ | --------------------------------------------------------------- |
| `--context-graph-id <id>`      | Target context graph                                            |
| `--create-context-graph`       | Create the context graph if needed                              |
| `--share`                      | Share imported per-concept KAs to SWM after WM import/finalize  |
| `--replace`                    | Replace existing imported concept assets                        |
| `--manifest <path>`            | Resume or inspect staged import progress from a custom manifest |
| `--private`                    | Create/use a private context graph for imports                  |
| `--sub-graph-name <name>`      | Import into a registered sub-graph                              |
| `--relate <predicate>`         | Override relation mapping for concept links                     |
| `--dry-run` / `--print-nquads` | Validate and print deterministic RDF without mutating the node  |

Private allowlisting currently uses the OKF command's implemented flags. The broader product decision about exposing `--allowed-agent` alongside or instead of `--allowed-peer` remains open.

## Export

```bash
dkg okf export okf-demo ./out
dkg okf export okf-demo ./out --view shared-working-memory
dkg okf export okf-demo ./out --view verifiable-memory
```

Export reads a context graph view and writes an OKF bundle to the output directory. Use export views to choose Working Memory, Shared Working Memory, or Verifiable Memory.

## Verify

```bash
dkg okf verify ./bundle --context-graph-id okf-demo
dkg okf verify ./bundle --context-graph-id okf-demo --list-missing
```

Verify compares the deterministic RDF expected from the local OKF bundle with triples currently visible from the node. Current verify behavior is SWM-oriented; sub-graph scoped verify is a known follow-up gap.

## VM Capstone

After an OKF import has been shared to SWM, publish selected named KAs explicitly:

```bash
dkg ka publish-async <concept-ka-name> --context-graph-id okf-demo
```

There is no OKF import-and-publish one-shot.


# Funding

Working Memory, Shared Working Memory, querying, local imports, discovery, and direct messages do not require on-chain funds.

Verifiable Memory publishing, updates, endorsement, verification, and other chain operations require gas and TRAC.

Your node's network is chosen at setup (default: **mainnet-gnosis**) and persisted as `config.networkConfig`; pass `--network <name>` to pick another (`mainnet-base`, `testnet`).

Async publisher wallets also need native gas, plus PCA agent registration or TRAC for direct spend. Publisher wallet identity is optional attribution, not a funding prerequisite. See [Async Publisher Wallets](/use-dkg/async-publisher-wallets).

**On mainnet (gnosis / base) there is no faucet** — fund the node's operational wallets yourself with the chain's native gas token (xDAI on Gnosis, ETH on Base) and TRAC before publishing.

**On testnet**, setup flows auto-fund the generated wallets when a faucet is configured (the bundled testnet config provides one); this is skipped automatically on mainnet:

* `dkg init` — auto-funds on testnet when the faucet is reachable; has no `--no-fund` flag
* `dkg mcp setup`
* `dkg hermes setup`
* `dkg openclaw setup`

Core Node profile registration also needs funded node wallets. A fresh Core wallet file has one admin wallet plus operational wallets. The primary operational wallet needs the native gas token and enough TRAC for the initial V10 staking conviction; the admin wallet should have native gas for profile key-management and operational-wallet registration. See [Daemon Lifecycle](/use-dkg/run-node#core-node-profile-registration) for the full Core checklist.

Skip funding on the `setup` commands with:

```bash
--no-fund
```

Check balances:

```bash
dkg wallet
dkg status
```

Faucet failures should not block local memory or P2P validation. They block only operations that need on-chain finality.


# Publishing Conviction

Publishing Conviction Accounts let a publisher commit TRAC, register publishing agents, and use the account as the publish authority for curated Context Graph flows.

Use this page for the current CLI/API surface. For the economics model, see [Conviction & Economics](/how-dkg-works/conviction-and-economics).

## Create a PCA

```bash
dkg pca create --tokens 100000 --primary-node <identityId>
```

The daemon EOA becomes the owner of the PCA NFT. Owner-gated write operations must be run from the node whose EOA owns that NFT.

## Register a Publishing Agent

```bash
dkg pca register-agent <accountId> <agentAddress>
```

The agent address must be a valid non-zero EVM address. Register the transaction-signing wallet address that will publish with the PCA. The daemon verifies registration with an on-chain read after the transaction lands when the adapter supports it.

The agent wallet still needs native gas, but it does not need an on-chain node identity. Node identity is only publisher-node attribution; PCA payment eligibility comes from PCA agent registration.

## Deregister a Publishing Agent

```bash
dkg pca deregister-agent <accountId> <agentAddress>
```

This is owner-gated on-chain.

## Add Funds

```bash
dkg pca funds <accountId> --tokens 50000
```

The CLI asks the daemon to approve token spend automatically before submitting the top-up transaction.

## Settle

```bash
dkg pca settle <accountId>
```

Settlement is permissionless. It runs the lazy-settlement sweep for the account.

## Inspect

```bash
dkg pca info <accountId>
dkg pca info <accountId> --probe-key <agentAddress>
```

The read-only snapshot includes owner, committed TRAC, top-up buffer, base epoch allowance, creation and expiry epochs, agent count, settlement window, and discount basis points.

## Use PCA With a Curated Context Graph

Attach a PCA to curated Context Graph registration with `--pca-account-id`:

```bash
dkg context-graph register <contextGraphId> --publish-policy 0 --pca-account-id <accountId>
```

`pcaAccountId` is valid only for curated publish policy. The daemon checks that the local curator matches the PCA owner before registering the Context Graph with the PCA.

## API Routes

| Route                                | Purpose              |
| ------------------------------------ | -------------------- |
| `POST /api/pca`                      | Create a PCA.        |
| `POST /api/pca/:id/agent`            | Register an agent.   |
| `DELETE /api/pca/:id/agent/:address` | Deregister an agent. |
| `POST /api/pca/:id/funds`            | Top up funds.        |
| `POST /api/pca/:id/settle`           | Run settlement.      |
| `GET /api/pca/:id`                   | Read account info.   |

These routes require a configured chain adapter with V10 PCA support. Nodes without that surface return feature-unavailable responses instead of pretending the account does not exist.


# Relays & Peers

Nodes use libp2p for peer connectivity. Edge nodes behind NAT reserve relay slots so other nodes can reach them. The default network relay set is loaded from the active network config.

## Inspect Peers

```bash
dkg peers
dkg peer info <peer-id>
```

If peer discovery looks empty:

* confirm the daemon is running
* wait for discovery to settle
* check configured relays in node config
* inspect daemon logs
* verify that both nodes subscribe to the same Context Graph when expecting shared memory

Direct messages and query-remote are best-effort P2P operations. Treat timeouts as connectivity facts, not as proof that the remote data does not exist.

## Prefer Operator Relays

Use `--relay-preferred` when you run relays you control and want this node to try those relays before the network defaults:

```bash
dkg start \
  --relay-preferred /ip4/203.0.113.10/tcp/4001/p2p/12D3KooWMyRelayOne... \
  --relay-preferred /dns4/relay.example.com/tcp/4001/p2p/12D3KooWMyRelayTwo...
```

The flag is repeatable. Entries are prepended in CLI order for that daemon run. To persist the preference, set `preferredRelays` in `~/.dkg/config.json`:

```json
{
  "preferredRelays": [
    "/ip4/203.0.113.10/tcp/4001/p2p/12D3KooWMyRelayOne...",
    "/dns4/relay.example.com/tcp/4001/p2p/12D3KooWMyRelayTwo..."
  ]
}
```

CLI entries and config entries are deduplicated before they are prepended to the network relay list. Public relays stay as fallback.

## Messenger Health

Short peer-to-peer protocols that use Universal Messenger expose delivery latency and queued counts through the daemon API:

```bash
curl -H "Authorization: Bearer $(dkg auth show)" \
  http://127.0.0.1:9200/api/slo
```

Use this when peer commands show a reachable peer but messages still queue or feel slow. `/api/slo` is an in-memory snapshot; daemon restart resets its samples, while the underlying retry outbox survives restart.


# Storage SPARQL HTTP

The DKG node can use any **SPARQL 1.1 Protocol**–compliant store you run yourself, instead of its default daemon-managed local Oxigraph server (or the embedded `oxigraph-worker` fallback). That gives you:

* **Real on-disk persistence** (e.g. Oxigraph server with RocksDB)
* **Larger graphs** without holding everything in the Node process
* **Existing infrastructure** (GraphDB, Blazegraph, Jena Fuseki, Neptune, Stardog)

## Backend: `sparql-http`

Configure the node to use the **`sparql-http`** backend with a **query endpoint**. `updateEndpoint` is optional and defaults to `queryEndpoint`, which covers stores that use one URL for both query and update.

### Config (CLI / config.json)

In `~/.dkg/config.json` (or your `DKG_HOME` config):

```json
{
  "name": "my-node",
  "apiPort": 9200,
  "listenPort": 9001,
  "store": {
    "backend": "sparql-http",
    "options": {
      "queryEndpoint": "http://127.0.0.1:7878/query",
      "updateEndpoint": "http://127.0.0.1:7878/update"
    }
  }
}
```

Optional:

* **`updateEndpoint`** — SPARQL update endpoint. Defaults to `queryEndpoint` when omitted.
* **`timeout`** — request timeout in ms (default `30000`).
* **`auth`** — `Authorization` header value, e.g. `"Bearer <token>"` or `"Basic <base64>"`.

### Oxigraph server

1. **Install and run Oxigraph** (Rust binary with RocksDB):
   * Download from [oxigraph/oxigraph releases](https://github.com/oxigraph/oxigraph/releases) or build from source.
   * Run the server, e.g.:

     ```bash
     oxigraph serve --bind 127.0.0.1:7878 --location /path/to/oxigraph-data
     ```
   * Default paths are often `/query` and `/update` (check the server’s docs).
2. **Point the DKG at it** using the `sparql-http` config above with your host/port.
3. Start the DKG node as usual; it will use the remote store for all triples.

{% hint style="info" %}
For a local Oxigraph server you do **not** have to run it yourself: set `"store": { "backend": "oxigraph-server" }` (the `dkg init` default) and the daemon fetches the pinned `oxigraph` binary, spawns it on `127.0.0.1`, and supervises it. Use the manual `sparql-http` steps above only when you run Oxigraph (or another SPARQL store) yourself or off-host.
{% endhint %}

Managed Oxigraph accepts optional launch settings under `store.options`:

```json
{
  "store": {
    "backend": "oxigraph-server",
    "options": {
      "port": 7878,
      "location": "/var/lib/dkg/oxigraph-data",
      "cacheDir": "/var/lib/dkg/oxigraph-bin",
      "readyTimeoutMs": 180000,
      "queryTimeoutS": 35,
      "memoryHighMiB": 2048,
      "memoryMaxMiB": 3072
    }
  }
}
```

`readyTimeoutMs` is the maximum startup readiness wait in milliseconds. It must be a positive integer; invalid values are ignored and the default 30-second timeout is used. Increase it when a large or recovering RocksDB database needs longer to open.

`queryTimeoutS` is the native Oxigraph query timeout in seconds. The rewritten HTTP store timeout includes an additional five-second grace period so Oxigraph can return its timeout response before the client aborts the request.

On Linux hosts using systemd, `memoryMaxMiB` runs managed Oxigraph in a dedicated transient user scope with a finite hard limit and disables swap for that scope, so database pressure cannot spill into host swap and stall the node. Optional `memoryHighMiB` sets its soft reclaim threshold and must not exceed `memoryMaxMiB`. This keeps Oxigraph outside the DKG daemon service's cgroup, so a finite `MemoryMax` on the daemon cannot kill the store or throttle the Node.js control plane as one combined process group. Enable lingering once for the node service account (`sudo loginctl enable-linger <dkg-user>`) so its user manager and bus exist before the system service starts at boot; verify with `systemctl --user is-system-running` as that account. The daemon supplies the required user-bus environment automatically. Startup fails rather than silently dropping configured limits when the scope cannot be created.

Size the daemon service and Oxigraph scope independently, while keeping their combined maxima within host capacity. For example, an 8 GiB node can reserve 3 GiB for managed Oxigraph and place a separate finite 4 GiB cap on the DKG service, leaving roughly 1 GiB for the OS. These options are deliberately opt-in and are not supported on non-systemd platforms.

### Other stores

* **Blazegraph:** One URL for both query and update. Set only `queryEndpoint` or set both options to the same URL (e.g. `http://127.0.0.1:9999/blazegraph/namespace/kb/sparql`).
* **Apache Jena Fuseki:** Typically `http://host:3030/dataset/query` and `http://host:3030/dataset/update`.
* **GraphDB, Neptune, Stardog:** Use the vendor’s SPARQL query and update URLs; add `auth` if required.

## Programmatic (DKGAgent)

When creating an agent in code, pass `storeConfig`:

```ts
import { DKGAgent } from '@origintrail-official/dkg-agent';

const agent = await DKGAgent.create({
  name: 'MyAgent',
  storeConfig: {
    backend: 'sparql-http',
    options: {
      queryEndpoint: 'http://127.0.0.1:7878/query',
      updateEndpoint: 'http://127.0.0.1:7878/update',
    },
  },
});
await agent.start();
```

## Store defaults

New installs default to a **daemon-managed local Oxigraph server** (`store.backend: "oxigraph-server"`): `dkg init`, `dkg openclaw/hermes/mcp setup`, or accepting the wizard default writes this block. The daemon fetches the pinned `oxigraph` binary on first boot and runs it on loopback, giving MVCC concurrent reads and incremental RocksDB persistence.

If a config has **no** `store` block at all, the runtime falls back to the embedded in-process **`oxigraph-worker`** (a single-writer store that rewrites its on-disk N-Quads dump under `dataDir` on every flush) — fine for development and small nodes. For very large graphs or existing infrastructure, use `sparql-http` with an external store.


# Host-Mode Manual Subscribe

**Scope.** Operator playbook for the manual / fourth-resort path that asks a core daemon to start hosting a curated CG's opaque SWM ciphertext without waiting for any of the three automatic discovery paths to fire.

This runbook covers **when** to reach for it (and when not to), **how** to call it safely, and **what the four discovery paths each look like** so you can tell from a log whether the manual call is actually needed.

> **Operator-only — NOT an agent MCP tool.** This endpoint changes *which node hosts* a curated CG's opaque ciphertext, which is a trust-boundary decision the curator owns. Always invoke it via a direct `curl` (or wrap it in the operator's `dkg` CLI / deploy scripts). It is intentionally **not** registered as an MCP tool on `mcp-dkg`, so an agent cannot autonomously enroll its connected core as a host. The earlier `dkg_request_hosting` tool was removed in the PR #672 Codex review pass for exactly this reason (review comment `id=3302086584`); the `requestHostMode` client method in `packages/mcp-dkg/src/client.ts` stays only for use inside operator scripts.

## TL;DR

Almost always you should let LU-6 Phase B's automatic discovery do its job. The manual subscribe is a last-resort tool — reach for it only when **all three** automatic paths have demonstrably failed for a CG, and a late-joining member is asking for catchup that cores can't yet serve.

## The four discovery paths

A core daemon picks up curated-CG hosting assignments through one of four mechanisms. The first three are automatic; the fourth is what this runbook covers.

<table><thead><tr><th width="40">#</th><th width="176">Path</th><th width="239">Wired at</th><th>Triggers when</th></tr></thead><tbody><tr><td>1</td><td><strong>Chain-event auto-subscribe</strong></td><td><code>packages/agent/src/dkg-agent.ts</code> (<code>ContextGraphCreated</code> handler inside the chain poller)</td><td>Curator registers an <code>accessPolicy=1</code> CG on-chain with a <code>nameHash</code> commitment. Cores in the sharding table with <code>swmHostMode</code> enabled subscribe immediately on event arrival.</td></tr><tr><td>2</td><td><strong>Discovery beacon</strong></td><td><code>packages/agent/src/dkg-agent.ts</code> (<code>DKG_CG_DISCOVERY_TOPIC</code> gossip subscription + <code>BEACON_REANNOUNCE_INTERVAL_MS</code> re-announce timer)</td><td>Curator pre-registers a CG (before any on-chain transaction) and starts re-announcing it on the discovery topic. Cores hear the beacon and subscribe. Used for pre-reg / off-chain-only CGs.</td></tr><tr><td>3</td><td><strong>Periodic reconciler</strong></td><td><code>packages/agent/src/dkg-agent.ts</code> (<code>hostModeReconcilerTimer</code>, <code>sweepSwmHostModeSubscriptions</code>)</td><td>Catches anything the first two paths missed (chain event lost in a re-org, beacon missed during a restart, etc.). Sweeps every locally-known CG and ensures host-mode subscription state is in sync. Idempotent.</td></tr><tr><td>4</td><td><strong>Operator-driven manual subscribe</strong> <em>(this runbook)</em></td><td><code>packages/cli/src/daemon/routes/memory.ts</code> (<code>POST /api/shared-memory/host-mode/subscribe</code>)</td><td>Operator explicitly POSTs a <code>contextGraphId</code>. The daemon enables host-mode for it the same way the reconciler would.</td></tr></tbody></table>

Paths 1–3 cover the documented Phase B happy path: a curator registers a CG, cores see it, cores host it. Path 4 exists for the gaps those three don't cover.

## When to reach for the manual path

Use the manual subscribe **only** when you can demonstrate at least one of:

1. **Off-chain CG / no chain commitment.** The curator did not register on-chain and does not run the discovery beacon (e.g. a one-off curated CG used inside an organization that lives entirely off-chain). Paths 1 and 2 cannot fire; path 3 only reconciles CGs the local node already knows about, so a fresh core needs to be told the id.
2. **Coverage gap during rollout.** Fewer than `minimumRequired- Signatures` capable cores are connected to the curator, and you (the operator) want to deliberately enroll a specific core as an opaque host. This is a transitional tool while testnet core capacity ramps; once enough cores are auto-subscribed via paths 1–3, this case goes away.
3. **Late-joining member catchup is failing** AND the failure log shows "no cores hold ciphertext for this CG" rather than a decryption / permission error. (If a member's catchup fails with `AEAD verify failed`, the issue is membership/key distribution, not host-mode subscription — manually subscribing more cores will not help.)

**Do not** use this as a routine subscribe call. If you find yourself reaching for it on every fresh CG, paths 1–3 are not firing correctly and that's the real bug to fix — file a ticket against the discovery poller, not against the daemon that needed the manual nudge.

## Preconditions

* Target daemon must be a **core** node (`nodeRole === 'core'`) with `swmHostMode` enabled in `~/.dkg/config.json`. Edge nodes have host mode disabled by build; the endpoint returns a no-op on those. For registered-CG hosting and node-operator authorization, the Core should also have a non-zero node profile `identityId`; see [Core Node Profile Registration](/use-dkg/run-node#core-node-profile-registration).
* Operator must have the daemon's `~/.dkg/auth.token` (same `Bearer` scheme every other `/api/*` route uses).
* Target CG must be **curated** (`accessPolicy === 1`). Public CGs use the plaintext SWM substrate and don't need an opaque host.

## How to call it

```bash
# Pick up the daemon's auth token. The default location is the
# per-node ~/.dkg/auth.token; if you run multiple nodes via
# scripts/devnet.sh, each node has its own auth.token under
# .devnet/nodeN/.
AUTH="$(tail -1 ~/.dkg/auth.token)"

# `contextGraphId` is the SAME id the curator used at `dkg context-graph
# create` time. On the hosting core you'll typically supply the
# curator-committed `nameHash` (the on-chain wire id) — that's what the
# chain-event path uses internally and it's what `gossipWireIdFor`
# expects to resolve into the SWM gossip topic.
curl -X POST \
  -H "Authorization: Bearer $AUTH" \
  -H 'Content-Type: application/json' \
  -d '{ "contextGraphId": "<curator-agent>/lj-A-1717000000" }' \
  http://127.0.0.1:9201/api/shared-memory/host-mode/subscribe
```

A successful response looks like:

```json
{
  "contextGraphId": "<curator-agent>/lj-A-1717000000",
  "subscribed": true,
  "alreadySubscribed": false,
  "hostingEnabled": true
}
```

Other documented response shapes:

* `{"subscribed": false, "alreadySubscribed": true, "hostingEnabled": true}` — the daemon was already subscribed to this CG (paths 1–3 already fired, or you called this twice). Safe; idempotent.
* `{"subscribed": false, "alreadySubscribed": false, "hostingEnabled": true, "memberMode": true}` — local node is already a **CG member** of this CG. Member-mode takes precedence; the daemon refuses to wire a second handler. This means you don't need host mode for this CG on this node — the member-mode handler already covers it.
* `{"subscribed": false, "alreadySubscribed": false, "hostingEnabled": false}` — node has no `swmHostModeStore`, i.e. host mode is disabled at config time. Not a core node, or `swmHostMode: false` in config.
* HTTP `400` — missing/blank `contextGraphId`.
* HTTP `501` — daemon build does not expose `enableSwmHostModeFor`.
* HTTP `500` — `enableSwmHostModeFor` threw. The body's `error` field carries the underlying message; the daemon log has the full trace.

## How to verify the subscribe took effect

After a successful POST:

1. The daemon log on the core should include `Host-mode subscribed CG=<id>` (or the persistence-queue equivalent).
2. `GET /api/shared-memory/host-mode/stats` reports the CG in its `subscribedCgIds` array (alongside `enabled`, `cgCount`, `totalBytes`, `totalEntries`). This is the host-mode store diagnostics endpoint, served by `packages/cli/src/daemon/routes/memory.ts` and backed by `DKGAgent.getSwmHostModeStats()`. Entries in `subscribedCgIds` are always the **canonical wire-form** id (the curator-committed `nameHash`, lowercase 0x-prefixed 32-byte hex) regardless of whether the CG was subscribed via the chain-event path, the beacon, the reconciler, or a manual subscribe call — see `canonicalSwmHostModeKey` in `packages/agent/src/dkg-agent.ts` for the rationale (PR #672 review `id=3302086589`). If you POSTed a cleartext id, expect the corresponding hash to come back here, not the original cleartext. Example response after a single subscribe:

   ```json
   {
     "enabled": true,
     "cgCount": 1,
     "totalBytes": 0,
     "totalEntries": 0,
     "subscribedCgIds": ["0x4ad12a3e…0a9c1b"]
   }
   ```

   `totalBytes` / `totalEntries` stay at zero until the first gossiped SWM envelope lands and is persisted — see step 3.
3. Within a few seconds, gossiped SWM envelopes for that CG should start showing up in the core's `swm-host-mode` substrate. With no curator currently writing, you won't see ingest until the next write — that's normal.
4. A member running `POST /api/shared-memory/catchup` against this core should now get a non-zero `totalInsertedTriples` (assuming the member holds the AEAD chain key — see SCENARIO D in `scripts/devnet-test-rfc38-late-joiner.sh`).

## How to stop hosting

The current daemon exposes a manual subscribe route and a stats route; it does **not** expose a `POST /api/shared-memory/host-mode/unsubscribe` route. If you need to stop hosting before a supported per-CG unsubscribe API exists, use an operator maintenance path outside this endpoint: disable `swmHostMode` for the daemon and restart to stop host-mode handlers, or perform a reviewed cleanup of the persisted host-mode store record and restart. Do not script a manual unsubscribe curl against this daemon version.

## Anti-patterns

* **Don't** loop the manual call as a substitute for the reconciler. The reconciler is what guarantees eventual consistency for CGs whose chain event was missed; replacing it with a polling script hides whatever bug is preventing the reconciler from converging.
* **Don't** call this on a CG you're also a member of. The daemon rejects with `memberMode: true`; if you got there by misreading the topology, you don't need host mode — your member handler is already authoritative.
* **Don't** wire it into MCP-tool calling patterns that an agent invokes automatically. Operator-only by design: an agent that reaches for host mode is bypassing the curator's authority over who hosts the curated CG. The previous `dkg_request_hosting` MCP tool was removed in PR #672 (Codex review `id=3302086584`) for this exact reason — there is no agent-facing entrypoint. If you want a friendlier CLI wrapper, add it to the operator-side `dkg` CLI (which is human-invoked), not to `mcp-dkg` (which agents drive).

## Related

* `packages/cli/src/daemon/routes/memory.ts` — endpoint implementation.
* `packages/agent/src/dkg-agent.ts` — `enableSwmHostModeFor`, the agent-side handler the endpoint delegates to.
* `packages/agent/src/dkg-agent.ts` — `ContextGraphCreated` handler, discovery beacon, and host-mode reconciler — the three automatic paths this runbook supplements.
* `scripts/devnet-test-rfc38-late-joiner.sh` SCENARIO D — the end-to-end happy path this endpoint participates in.


# Updates & Rollback

> **Tip:** point the node at a **reliable chain RPC** before updating — public endpoints rate-limit and can silently stall publishing.

Use the CLI update path for packaged installs:

```bash
dkg update --check
dkg update
dkg rollback
```

Before updating:

* stop long-running imports or publisher jobs
* check wallet and daemon status
* record the current package version
* keep a copy of local config and auth material outside the repo

After updating:

```bash
dkg status
dkg wallet
dkg mcp setup --force
```

Use `dkg rollback` when the latest installed version breaks daemon startup or a critical integration.


# Migrate to npm

> **Applies to `10.0.0-rc.11` and earlier.** The `dkg migrate-to-npm` command was removed in `10.0.0-rc.17`. On current releases the git-checkout → npm migration runs automatically on the first `dkg start`, so this manual procedure is no longer needed. Keep this page only for operators running a node pinned to rc.11 or older.

## Migrate a git-checkout install to the npm-pinned auto-update path

This guide is for operators currently running a DKG node from a `git clone`d checkout (typical layout: `~/dkg/` with `.git`, `packages/`, `node_modules/`, `pnpm-lock.yaml`, `package.json`). It walks through converting that install to use the npm-pinned auto-update path without re-installing.

The end-state: the daemon's auto-updater fetches pre-built artifacts of a specific `@origintrail-official/dkg` version from npm into `~/.dkg/releases/{a,b}/`, instead of building from source against the tracked git branch on every update cycle.

### Why migrate

The build-from-source auto-update path (active when the CLI detects a monorepo checkout) is fragile for long-running production daemons:

* **It runs `tsc` + dependent build steps on every update**, exposing the daemon to any regression that lands on the tracked branch between two polling cycles. A previous release retrospective for beacon-01 traced a shutdown deadlock to exactly this pattern: a regression merged to `main`, the next auto-update cycle built it, and the deadlock fired on the worker's first SIGTERM.
* **It is harder to pin to a known-good version.** With the npm path, the operator can set `autoUpdate.npmVersion = "10.0.0-rc.11"` (or just track `latest`) and know exactly what they'll get. With the git path, "latest" means "whatever `main` happens to look like at polling time".
* **It pulls a much larger dependency surface.** `pnpm install --frozen-lockfile` for the full monorepo runs hardhat, the EVM module's solidity tooling, and all dev dependencies. The npm path installs only the `production` dependency set.

### What the migration actually does

The `dkg migrate-to-npm` subcommand performs two changes:

1. **Renames `<repoRoot>/package.json`** to `<repoRoot>/package.json.pre-npm-migration-<timestamp>`. This is the **load-bearing** change. The auto-updater calls `findPackageRepoDir()` (in `packages/core/src/blue-green.ts`), which walks the directory tree looking for the marker pair `package.json + packages/`. Renaming `package.json` is sufficient to break that walker; the walker then returns `null`, `isStandaloneInstall()` returns `true`, and the auto-updater routes through `performNpmUpdate` on the next polling cycle.
2. **Renames `<repoRoot>/.git`** to `<repoRoot>/.git.pre-npm-migration-<timestamp>`. This is **cosmetic** — the walker doesn't look at `.git`. We rename it anyway because (a) it eliminates the operator-confusion failure mode (the original incident driver: operator sees `.git`, runs `git pull` thinking that's how updates work, fork happens), and (b) it prevents stray cron jobs or CI that watch for `.git` from doing anything unexpected.
3. **Writes `autoUpdate.source = "npm"`** into `~/.dkg/config.json`. Forward-compat with the `autoUpdate.source` config flag (PR #659). Until that flag merges this is silently ignored. Once it merges, this becomes the explicit pin and the renames in steps 1–2 become belt-and-braces.

#### What the migration does NOT touch

* **`packages/` and `packages/cli/dist/`.** The operator's `dkg` PATH symlink typically points into this tree. Renaming would break the ability to invoke `dkg` at all until the operator runs `npm install -g @origintrail-official/dkg`. The runbook recommends that as a follow-up step (see [Optional cleanup](#optional-cleanup-after-soak) below) once the operator has confirmed the npm-pinned daemon is healthy.
* **`node_modules/` and `pnpm-lock.yaml`.** Same reason — the current `packages/cli/dist/cli.js` runtime resolves modules from this `node_modules/`. Until the operator detaches the `dkg` invocation path, both must stay in place.
* **The blue-green slot tree under `~/.dkg/releases/{a,b}/`.** That is state, not source-tree. The auto-updater manages those slots itself.

### Pre-migration checklist

Before running `dkg migrate-to-npm --apply`:

* [ ] **Note the current commit hash** for rollback reference: `curl -s http://localhost:<api-port>/api/status | jq '.commit, .version'`.
* [ ] **Back up `~/.dkg/config.json`**: `cp ~/.dkg/config.json ~/.dkg/config.json.pre-migration`.
* [ ] **Back up `~/.dkg/` state** if you have anything worth preserving (decryption keys, custom agents, etc.). The migration does not touch `~/.dkg/`, but a snapshot before any operational change is good hygiene: `tar -czf ~/dkg-state-backup-$(date +%s).tar.gz -C ~ .dkg`.
* [ ] **Stop the daemon cleanly**: `dkg stop`. The migration script refuses to mutate the source tree while a worker process holds files open (override with `--force` only if the daemon is already wedged and you've SIGKILLed it manually).
* [ ] **Confirm there is no `~/.dkg-dev/` directory.** If your state lives there (typical for nodes that were originally set up by `pnpm dkg start` inside a fresh monorepo checkout without a pre-existing `~/.dkg/config.json`), the migration script will **hard-refuse** with a state-directory orphan blocker — see [Orphan state-directory handling](#orphan-state-directory-handling) below.

### Step-by-step

#### 1. Dry-run

Always start with a dry run. No flags = no mutation:

```bash
dkg migrate-to-npm
```

The output lists each action prefixed by `[LOAD-BEARING]`, `[cosmetic]`, or `[CONFIG]` along with the reason. Read through them. If there are blockers (`✗` lines), resolve them before proceeding.

#### 2. Apply

When you're satisfied with the dry-run output:

```bash
dkg migrate-to-npm --apply
```

The command performs the renames in order, then the config write, then prints exact next-step commands.

#### 3. Restart and verify

```bash
dkg start
```

Verify the daemon picked up the new install mode:

```bash
curl -s http://localhost:<api-port>/api/status | jq '.installMode // .version'
```

Wait one auto-update polling cycle (`checkIntervalMinutes`, default 30 min). On the first npm-path cycle, the daemon will install a fresh artifact into the inactive blue-green slot:

```bash
ls -la ~/.dkg/releases/
ls -la ~/.dkg/releases/{a,b}/node_modules/@origintrail-official/dkg/package.json
```

You should see one of `a/` or `b/` containing the npm-style layout (`node_modules/@origintrail-official/dkg/`) rather than the old git-style layout (`packages/cli/dist/`).

### Rollback

If something goes wrong before the first auto-update cycle has swapped slots:

```bash
dkg stop
mv ~/dkg/package.json.pre-npm-migration-<timestamp> ~/dkg/package.json
mv ~/dkg/.git.pre-npm-migration-<timestamp> ~/dkg/.git
# Remove or revert autoUpdate.source in ~/.dkg/config.json:
cp ~/.dkg/config.json.pre-migration ~/.dkg/config.json
dkg start
```

The next polling cycle will resume the git-path auto-update.

If the rollback is post-swap (the daemon already wrote an npm-style artifact to a blue-green slot), the rollback above will succeed but the daemon will need one more cycle to re-build the git-style artifact in the OTHER slot. That extra cycle is normal and harmless.

### Orphan state-directory handling

DKG resolves the active state directory (`dkgDir()`) by checking whether the running CLI is inside a monorepo:

* **In a monorepo checkout** AND `~/.dkg/config.json` does not exist → use `~/.dkg-dev/`
* Otherwise → use `~/.dkg/`

After this migration, `findPackageRepoDir` returns `null` (we renamed `package.json`), so the CLI looks at `~/.dkg/`. If your state was in `~/.dkg-dev/`, the migration script detects this and **hard-refuses** (no `--force` override; this case is genuinely unsafe — proceeding would silently make the CLI read from an empty `~/.dkg/` and behave like a fresh install).

The script's blocker message tells you the exact remediation. The two options:

**Option A: Move state.**

```bash
dkg stop
mv ~/.dkg-dev ~/.dkg
dkg migrate-to-npm --apply
dkg start
```

**Option B: Pin DKG\_HOME.**

If you prefer to keep state at `~/.dkg-dev/`:

```bash
echo 'export DKG_HOME=$HOME/.dkg-dev' >> ~/.zshrc   # or ~/.bashrc, ~/.config/fish/config.fish, etc.
# Open a NEW shell so the env var is picked up
exec $SHELL -l
dkg migrate-to-npm --apply
```

`DKG_HOME` overrides the auto-resolution unconditionally (rule 1 in `resolveDkgConfigHome`), so the CLI continues to use `~/.dkg-dev/` after migration.

### Daemon-alive bypass (`--force`)

The migration script refuses to mutate the source tree while the daemon is alive, because:

* The worker process holds file descriptors open against `~/dkg/packages/cli/dist/`. A rename mid-flight on POSIX systems is generally safe (the inode survives), but any in-flight write to `package.json` (highly unlikely but possible from a worker auto-update routine) would be lost.
* The next worker spawn would see the renamed tree and behave unexpectedly — the supervisor would either crash or boot from a half-migrated state.

If the daemon is wedged and `dkg stop` doesn't work:

```bash
kill -9 $(cat ~/.dkg/daemon.pid)
dkg migrate-to-npm --apply --force
```

`--force` downgrades the alive-check blocker to a warning. It does NOT bypass the state-directory orphan blocker (that's genuinely unsafe and has no escape hatch).

### Optional cleanup (after soak)

After the migrated daemon has been running healthily for at least a week (long enough to confirm one or two auto-update cycles completed cleanly), you can decouple from the old source tree entirely:

```bash
npm install -g @origintrail-official/dkg
which dkg                              # should now point at the npm-installed binary
dkg --version                          # confirm it matches what's in your blue-green slot
dkg stop
rm -rf ~/dkg/packages ~/dkg/node_modules ~/dkg/pnpm-lock.yaml
dkg start
```

At that point `~/dkg/` contains only the renamed backup files (`.git.pre-npm-migration-...`, `package.json.pre-npm-migration-...`) and is safe to delete entirely.

### Log rotation (cross-cutting recommendation)

Unrelated to this migration but discovered by the same incident retrospective: beacon-01 accumulated **134 MB of `daemon.log` in 24 hours** during a shutdown deadlock, dominated by chain-provider polling spam. Independent of whether you migrate, set up log rotation:

`/etc/logrotate.d/dkg`:

```
/home/<your-user>/.dkg/daemon.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}
```

`copytruncate` is required — the daemon does not respond to SIGHUP for log reopening, and renaming the file out from under it would silently lose subsequent writes. A future core-stability fix should reduce chain-provider log spam at the source.


# Troubleshooting

Start with the narrowest check that proves the failing layer.

## Daemon

```bash
dkg status
dkg logs
curl http://127.0.0.1:9200/api/status
```

## Auth

```bash
TOKEN=$(dkg auth show)
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:9200/api/agent/identity
```

401 means no usable token. 403 means the caller is recognized but not allowed to perform that operation.

## Memory writes

* Verify the target Context Graph exists.
* Verify the sub-graph exists before targeting it.
* Query the Knowledge Asset before sharing.
* Finalize (seal) the Knowledge Asset, then share it to SWM before publishing to VM (VM publish requires a finalized Knowledge Asset present in SWM).
* Check wallet funding before on-chain finality.

## Agent integrations

* MCP: restart the client after setup and inspect the tool list.
* Hermes: confirm the gateway is running and `API_SERVER_ENABLED=true`.
* OpenClaw: restart the gateway after setup if the adapter does not appear.


# Context Pack

DKG V10 is a verifiable memory system for agents. A DKG Node provides private Working Memory (WM), peer-visible Shared Working Memory (SWM), and on-chain Verifiable Memory (VM). Agents operate within Context Graphs, optionally partitioned into subgraphs.

Use this decision order:

1. Need status, setup, or tool discovery: call status or read the Node Skill.
2. Need free-text recall: use memory search.
3. Need exact graph patterns: use SPARQL query with named graph patterns.
4. Need to write draft knowledge: create and write a Working Memory Knowledge Asset, then finalize (seal) it.
5. Need team-visible knowledge: share the Knowledge Asset to Shared Working Memory.
6. Need durable finality: publish from Shared Working Memory to Verifiable Memory after confirming wallet funds and user intent.
7. Need publisher conviction: use the current PCA CLI/API surface, then verify ownership and registered agent status before assuming discount eligibility.

Always report the memory layer when presenting evidence. Do not imply on-chain verification for WM or SWM data.

Treat staker conviction, context oracles, and x402 knowledge commerce as a roadmap or contract/economics context unless a current `use-dkg` workflow gives exact commands.


# Invariants

* Use the DKG Node Skill as the exact operational contract.
* Prefer tool or adapter calls over raw HTTP when the runtime exposes them.
* Working Memory is private; Shared Working Memory is peer-visible; Verifiable Memory is on-chain.
* Publish to Verifiable Memory only when finality is intended and funds are available.
* Publish named Knowledge Assets from SWM with `dkg ka publish` / `publish-async` or `/api/knowledge-assets/{name}/vm/publish`; do not use direct-from-file VM publish or loose shared-memory write/publish recipes.
* Use `dkg pca ...` or `/api/pca/*` for Publishing Conviction Accounts; do not infer PCA ownership or agent registration without checking.
* Treat x402 paid access and context oracles as roadmap concepts unless the current Node Skill exposes the exact workflow.
* Query sub-graph-routed data with named graph patterns.
* Do not cite archive docs as current behavior.
* Do not route users to old setup, onboarding, deployment, or protocol-operation docs.
* Do not ask for admin tokens from remote machines; use local token discovery or agent registration.
* Keep current docs metadata at `status: current` and `version: v10`.


# Publish & Query

## Write path

1. Create or select a Context Graph.
2. Create a Working Memory Knowledge Asset.
3. Write RDF quads.
4. Finalize (seal) the Knowledge Asset.
5. Query the Knowledge Asset to verify.
6. Share to Shared Working Memory when peers should see it.
7. Publish to Verifiable Memory only with explicit finality intent.

Node Skill tools:

* `dkg_context_graph_create`
* `dkg_knowledge_asset_create`
* `dkg_knowledge_asset_write`
* `dkg_knowledge_asset_finalize`
* `dkg_knowledge_asset_query`
* `dkg_knowledge_asset_share`
* `dkg_knowledge_asset_publish`

CLI equivalents:

```bash
dkg ka create <name> -c <context-graph-id> --input-file <rdf-file> --share
dkg ka publish-async <name> -c <context-graph-id>
```

Use the one-shot CLI form only for create/write/finalize/share into SWM. VM publish remains explicit and operates on the named KA after it is fully shared.

## Query path

* Use `memory_search` for recall (`dkg_memory_search` on the MCP runtime).
* Use `dkg_query` for SPARQL.
* Use `GRAPH ?g { ... }` for sub-graph-routed data.


# Operate & Troubleshoot

Start with the failing layer.

## Daemon

```bash
dkg status
dkg logs
curl http://127.0.0.1:9200/api/status
```

## Auth

```bash
TOKEN=$(dkg auth show)
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:9200/api/agent/identity
```

## Funds

```bash
dkg wallet
```

Funds are needed for Verifiable Memory, not for WM/SWM/query-only flows.

## Connectivity

```bash
dkg peers
dkg peer info <peer-id>
```

For MCP, restart the client after setup. For Hermes, confirm the gateway is running. For OpenClaw, restart the gateway if the adapter is not loaded.


# CLI

Run `dkg <command> --help` for the current option surface.

Common commands:

```bash
dkg init                                 # interactive setup: node name, role, relay, triple-store backend (default: oxigraph-server)
dkg init --role core --network <name>    # initialize a Core Node that will create an on-chain node profile on startup
dkg start [-f]                           # start the node daemon (-f for foreground)
dkg stop                                 # graceful shutdown
dkg status                               # node health, peer count, store status
dkg logs                                 # tail the daemon log
dkg peers                                # list discovered agents on the network
dkg peer info <peer-id>                  # inspect a peer's identity and addresses

# Direct messaging
dkg send <name> <msg>                    # encrypted direct message to a peer
dkg chat <name>                          # interactive chat with a peer

# Context graphs (projects)
dkg context-graph create <id>            # create a local context graph
dkg context-graph register <id>          # register an existing CG on-chain (unlocks VM)
dkg context-graph add-agent <id> --agent <addr>   # add an agent to a curated CG allowlist (replaces deprecated 'invite')
dkg context-graph list                   # list subscribed context graphs
dkg context-graph info <id>              # show context-graph details
dkg context-graph agents <id>            # list agents in the CG allowlist
dkg context-graph request-join <id> <curatorPeerId>   # request to join a curated CG (peer id from V10 invite)
dkg context-graph sign-join <id>         # sign a join-request delegation locally without forwarding
dkg context-graph approve-join <id>      # approve a pending join request

# Knowledge Assets: create -> write -> finalize -> share -> publish
dkg ka create <name> -c <cg> --input-file <rdf-file> --share  # one-shot create/write/finalize/share; no VM publish
dkg ka import-file <name> -c <cg> --input-file <file>         # import a document into WM
dkg ka write <name> -c <cg> --input-file <rdf-file>           # append RDF payload quads to WM
dkg ka finalize <name> -c <cg> [--layer wm|swm]               # seal WM, or seal SWM content
dkg ka share <name> -c <cg> [--entity <uri...>]               # WM -> SWM
dkg ka share-async <name> -c <cg>                             # enqueue async WM -> SWM share
dkg ka share-jobs [--context-graph-id <cg>]                   # list async share jobs
dkg ka publish <name> -c <cg>                                 # sync SWM -> VM publish
dkg ka publish-async <name> -c <cg> [--publisher-node-identity-id 0]  # enqueue SWM -> VM publish
dkg ka pull-from <name> -c <cg> --layer swm|vm                # seed WM from SWM or VM
dkg ka discard <name> -c <cg>                                 # discard WM draft
dkg ka query <name> -c <cg>                                   # read WM quads
dkg ka history <name> -c <cg>                                 # lifecycle descriptor

# Compatibility aliases
dkg assertion import-file <name> -f <file> -c <cg>  # compatibility alias for document import
dkg assertion promote <name> -c <cg>                # compatibility alias for KA share

# Verification and endorsement
dkg verify <batchId> --context-graph <cg> --verified-graph <id>  # propose M-of-N verification
dkg endorse <ual> --context-graph <cg> [--agent <addr>]  # endorse a published KA as the authenticated agent (--agent only asserts the token's agent matches)

# Querying
dkg query [cg] -q "<sparql>"             # SPARQL against a local context graph
dkg query-remote <peer> -q "<sparql>"    # query a remote peer over P2P
dkg sync catchup-status <cg>             # show background catch-up status for a context graph
dkg subscribe <cg>                       # subscribe to a CG's gossip topics

# Async publisher (optional, for batching)
dkg publisher enable                     # enable the async publisher
dkg publisher publish-async <cg> <name> [--publisher-node-identity-id 0]  # alias for dkg ka publish-async
dkg publisher jobs                       # list publisher jobs
dkg publisher stats                      # publisher throughput stats
# publisher wallets need native gas plus PCA registration or TRAC; node identity is optional attribution

# Code & memory indexing
dkg index [directory]                    # index a code repo into the dev-coordination CG
dkg wallet                               # show admin and operational wallet addresses and balances
dkg set-ask <amount>                     # set the node's on-chain ask (TRAC per KB·epoch)

# Identity & auth
dkg auth show                            # show the current API auth token
dkg auth rotate                          # generate a new auth token
dkg auth status                          # show whether auth is enabled

# Framework adapters & MCP wiring
dkg openclaw setup                       # install & configure the OpenClaw adapter
dkg hermes setup                         # install & configure the Hermes adapter
dkg mcp setup                            # register the MCP server with Cursor / Claude Code / Claude Desktop / Windsurf / VSCode + Copilot / Cline / Codex CLI
dkg mcp serve                            # run the MCP server on stdio (invoked by the client; not run manually)

# Community integrations (registry: OriginTrail/dkg-integrations)
dkg integration list [--tier community]  # default tier filter is `verified`+
dkg integration info <slug>              # show details for one entry
dkg integration install <slug>           # install cli/mcp kind; --allow-community for community-tier entries

# Health & maintenance
dkg doctor [--json] [--no-orphan-scan]     # diagnose install state, version skew, orphan clones, config sanity

# Update / rollback
dkg update [--check] [--allow-prerelease]  # update node software
dkg rollback                               # roll back to previous version
```


# API

The canonical route contract is generated from the running daemon and exposed to agents through the DKG Node Skill:

* `packages/cli/skills/dkg-node/SKILL.md`
* `GET /.well-known/skill.md` on a running daemon

Use this page as a lookup pointer, not as a duplicate API definition. The highest-risk route families are:

<table><thead><tr><th width="273">Area</th><th>Route family</th></tr></thead><tbody><tr><td>Context graphs</td><td><code>/api/context-graph/*</code></td></tr><tr><td>Knowledge Assets and VM publish</td><td><code>/api/knowledge-assets/*</code></td></tr><tr><td>SWM substrate operations</td><td><code>/api/shared-memory/catchup</code>, <code>/api/shared-memory/host-mode/*</code>, <code>/api/shared-memory/verify-batch</code></td></tr><tr><td>Query</td><td><code>/api/query</code></td></tr><tr><td>Agents and messaging</td><td><code>/api/agents</code>, <code>/api/chat</code>, <code>/api/messages</code>, <code>/api/invoke-skill</code></td></tr><tr><td>Node identity and Core profile registration</td><td><code>/api/identity</code>, <code>/api/identity/ensure</code></td></tr><tr><td>Publishing Conviction Accounts</td><td><code>/api/pca/*</code></td></tr><tr><td>Messaging SLOs</td><td><code>/api/slo</code></td></tr><tr><td>Node status and peers</td><td><code>/api/status</code>, <code>/api/peer-info</code>, <code>/api/wallets/balances</code></td></tr></tbody></table>

## Knowledge Asset Lifecycle

Named Knowledge Assets use the lifecycle route family below. The active publishing path is create, write, finalize, share, then publish; VM publishing always operates on a named KA that has already been shared to SWM.

| Lifecycle step                  | Route                                                                                                              |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Create/open WM draft            | `POST /api/knowledge-assets`                                                                                       |
| Write RDF quads                 | `POST /api/knowledge-assets/{name}/wm/write`                                                                       |
| Import a document               | `POST /api/knowledge-assets/{name}/wm/import-file`                                                                 |
| Check import status             | `GET /api/knowledge-assets/{name}/wm/extraction-status`                                                            |
| Finalize/seal                   | `POST /api/knowledge-assets/{name}/wm/finalize`                                                                    |
| Share WM to SWM                 | `POST /api/knowledge-assets/{name}/swm/share`                                                                      |
| Enqueue async WM to SWM share   | `POST /api/knowledge-assets/{name}/swm/share-async`                                                                |
| Inspect async share jobs        | `GET /api/knowledge-assets/swm/share-jobs`, `GET /api/knowledge-assets/swm/share-jobs/{jobId}`                     |
| Cancel/recover async share jobs | `DELETE /api/knowledge-assets/swm/share-jobs/{jobId}`, `POST /api/knowledge-assets/swm/share-jobs/{jobId}/recover` |
| Publish SWM to VM               | `POST /api/knowledge-assets/{name}/vm/publish`                                                                     |
| Enqueue async VM publish        | `POST /api/knowledge-assets/{name}/vm/publish-async`                                                               |
| Seed/edit from SWM or VM        | `POST /api/knowledge-assets/{name}/wm/pull-from`                                                                   |
| Discard WM draft                | `POST /api/knowledge-assets/{name}/wm/discard`                                                                     |
| Read WM quads                   | `GET /api/knowledge-assets/{name}/wm/quads`                                                                        |
| Read lifecycle descriptor       | `GET /api/knowledge-assets/{name}`                                                                                 |

Both VM publish routes accept `options.publisherNodeIdentityIdOverride`. Use a non-negative decimal string; `0` means explicit no-attribution. Omit the option to use the publisher wallet's resolved default identity, which may also be `0`. Optional node attribution for a separate publisher wallet can be configured through `/api/operational-wallets`.

For exact request bodies, response shapes, and MCP tool names, use [Node Skill](/references/node-skill).


# Packages

Useful package-owned references:

<table><thead><tr><th width="200">Package</th><th>Reference</th></tr></thead><tbody><tr><td>CLI and daemon</td><td><code>packages/cli/README.md</code></td></tr><tr><td>MCP server</td><td><code>packages/mcp-dkg/README.md</code></td></tr><tr><td>Hermes adapter</td><td><code>packages/adapter-hermes/README.md</code></td></tr><tr><td>OpenClaw adapter</td><td><code>packages/adapter-openclaw/README.md</code></td></tr><tr><td>Agent package</td><td><code>packages/agent/README.md</code></td></tr><tr><td>Chain package</td><td><code>packages/chain/README.md</code></td></tr><tr><td>Core package</td><td><code>packages/core/README.md</code></td></tr><tr><td>Storage package</td><td><code>packages/storage/README.md</code></td></tr><tr><td>Query package</td><td><code>packages/query/README.md</code></td></tr><tr><td>Publisher package</td><td><code>packages/publisher/README.md</code></td></tr><tr><td>EVM module</td><td><code>packages/evm-module/README.md</code></td></tr></tbody></table>

Prefer these package references when a question is about package-specific flags, build steps, or API details.


# Glossary

<table><thead><tr><th width="202">Term</th><th>Meaning</th></tr></thead><tbody><tr><td>DKG V10</td><td>Version 10 of the Decentralized Knowledge Graph (DKG) — a decentralized knowledge network and protocol for verifiable agent memory.</td></tr><tr><td>DKG network</td><td>Peer-to-peer and on-chain system where nodes exchange, verify, and finalize graph knowledge.</td></tr><tr><td>DKG node</td><td>Local gateway into the DKG network. Owns storage, API, auth, wallets, networking, integrations, and UI.</td></tr><tr><td>Core Node</td><td>Infrastructure node that supports network storage, replication, and protocol services.</td></tr><tr><td>Edge Node</td><td>Local gateway for users, teams, apps, and agents.</td></tr><tr><td>Context Graph</td><td>Scoped knowledge domain. The Node UI may call it a project.</td></tr><tr><td>Sub-graph</td><td>Named slice inside a Context Graph, such as <code>chat</code>, <code>code</code>, <code>tasks</code>, <code>decisions</code>, <code>github</code>, or <code>meta</code>.</td></tr><tr><td>Working Memory</td><td>Private local memory layer for drafts and agent-local state.</td></tr><tr><td>Shared Working Memory</td><td>Peer-visible memory layer replicated through the network.</td></tr><tr><td>Verifiable Memory</td><td>On-chain finalized memory layer for selected knowledge.</td></tr><tr><td>Knowledge Asset</td><td>Graph data with provenance and integrity commitments. Created as a Working Memory draft, then sealed, shared, and published — at publish it is minted as a single ERC-721 token (one per publish) that can hold one or more entities, addressed by a stable UAL.</td></tr><tr><td>Knowledge Collection</td><td>Legacy (pre-V10.1) term for the on-chain publish unit, retired in the Knowledge Asset rename. A publish now mints exactly one Knowledge Asset (one ERC-721) that can hold multiple entities; there is no separate collection wrapper.</td></tr><tr><td>Assertion</td><td>Legacy name for a Knowledge Asset while it is still a Working Memory draft. The term survives in the <code>dkg assertion</code> CLI commands and the <code>dkg:Assertion</code> lifecycle record.</td></tr><tr><td>UAL</td><td>Universal Asset Locator. Durable identifier for a published Knowledge Asset, stable across content updates.</td></tr><tr><td>Agent</td><td>Software actor using a node through MCP, Hermes, OpenClaw, or custom SDK/API integration.</td></tr><tr><td>Curator</td><td>Authority for a curated Context Graph. Controls membership and publish policy.</td></tr><tr><td>Integration</td><td>External workflow connected to a DKG node through a supported public interface.</td></tr><tr><td>Publisher</td><td>Human or automated actor that triggers PUBLISH, UPDATE, or VERIFY operations.</td></tr><tr><td>Staker</td><td>Participant that locks TRAC to support network infrastructure.</td></tr><tr><td>SHARE</td><td>Operation that makes selected local knowledge visible in Shared Working Memory.</td></tr><tr><td>PUBLISH</td><td>Operation that finalizes selected knowledge into Verifiable Memory.</td></tr><tr><td>TRAC</td><td>Utility token used for on-chain DKG operations and staking.</td></tr><tr><td>Publishing Conviction Account</td><td>Publisher commitment account represented by a V10 conviction NFT. Used for publishing allowance, agent registration, and discount paths.</td></tr><tr><td>Publisher Conviction NFT</td><td>ERC-721 receipt for a Publishing Conviction Account.</td></tr><tr><td>Staker Conviction NFT</td><td>ERC-721 receipt for a staker conviction position.</td></tr><tr><td>Context Oracle</td><td>Roadmap pattern for consuming matured verified knowledge as oracle-ready agent context.</td></tr><tr><td>x402</td><td>Roadmap payment pattern for HTTP-based agent payments and paid knowledge access.</td></tr><tr><td>Universal Messenger</td><td>Reliability substrate for DKG short peer-to-peer protocols.</td></tr><tr><td>Node Skill</td><td>Canonical agent-facing operational contract at <code>packages/cli/skills/dkg-node/SKILL.md</code>.</td></tr></tbody></table>


# Node Skill

The canonical agent operational contract is:

```
packages/cli/skills/dkg-node/SKILL.md
```

The daemon also serves the skill at:

```
GET /.well-known/skill.md
```

Use the skill for exact tool names, HTTP routes, payload details, and agent execution rules. Use the docs corpus for system context, concepts, navigation, and task-level explanation.


# Networks & RPCs

OriginTrail DKG V10 runs across multiple EVM-compatible chains. Pick the network you want your node to operate on and use the matching RPC URL, chain ID, and block explorer below.

{% hint style="info" %}
DKG V10 is live on mainnet. A freshly set-up node defaults to **Gnosis mainnet** (`mainnet-gnosis`); choose another network at setup with the `dkg init` network prompt or `--network <name>` (`mainnet-base`, `testnet`). NeuroWeb mainnet is not yet selectable. See the [V10 Mainnet Release Timeline](/origintrail-v9-v10/v10-mainnet-release-timeline).
{% endhint %}

## DKG Mainnet

| Network  | RPC URL                                                | Chain ID | Gas token | Block explorer                 |
| -------- | ------------------------------------------------------ | -------- | --------- | ------------------------------ |
| Base     | `https://mainnet.base.org`                             | 8453     | ETH       | <https://basescan.org>         |
| Gnosis   | `https://rpc.gnosischain.com`                          | 100      | xDAI      | <https://gnosisscan.io>        |
| NeuroWeb | `https://astrosat-parachain-rpc.origin-trail.network/` | 2043     | NEURO     | <https://neuroweb.subscan.io/> |

## DKG Testnet

| Network          | RPC URL                                      | Chain ID | Gas token | Block explorer                         |
| ---------------- | -------------------------------------------- | -------- | --------- | -------------------------------------- |
| Base Sepolia     | `https://sepolia.base.org`                   | 84532    | ETH       | <https://sepolia.basescan.org>         |
| Gnosis Chiado    | `https://rpc.chiadochain.net`                | 10200    | xDAI      | <https://blockscout.chiadochain.net>   |
| NeuroWeb Testnet | `https://lofar-testnet.origin-trail.network` | 20430    | NEURO     | <https://neuroweb-testnet.subscan.io/> |

{% hint style="warning" %}
Public RPCs rate-limit and can silently stall publishing. For anything beyond quick testing, use a dedicated RPC endpoint (e.g. Infura, Alchemy, or your own node).
{% endhint %}

{% hint style="info" %}
To try the DKG on testnet you'll need test TRAC and native gas tokens — see [Funding](/use-dkg/funding). To run a local network for development, see the [Quickstart](/getting-started/quickstart).
{% endhint %}


# Contract addresses

{% hint style="info" %}
DKG V10 runs on **Base Sepolia (testnet)**, and the final release-candidate contracts are also deployed on **Base mainnet** as a pre-mainnet deployment. The full mainnet launch across Base, Gnosis, and NeuroWeb is still upcoming — see the [V10 Mainnet Release Timeline](/origintrail-v9-v10/v10-mainnet-release-timeline). The mainnet TRAC addresses below are the existing token contracts on those chains (for reference and bridging); the Gnosis and NeuroWeb mainnet protocol contracts will be published at mainnet launch.
{% endhint %}

## TRAC token

TRAC is the ERC-20 utility token used across the DKG. The token contract address is different on each chain — use the one for the network your node operates on.

On **mainnet**, TRAC is the original token contract (unchanged from V8). On the active V10 testnet (**Base Sepolia**), V10 uses a freshly redeployed test-TRAC contract (different from the V8 one). NeuroWeb uses the same native TRAC address on both mainnet and testnet.

### Mainnet

| Network  | TRAC token address                           |
| -------- | -------------------------------------------- |
| Base     | `0xa81a52b4dda010896cdd386c7fbdc5cdc835ba23` |
| Gnosis   | `0xEddd81E0792E764501AaE206EB432399a0268DB5` |
| NeuroWeb | `0xFfFFFFff00000000000000000000000000000001` |

### Testnet

| Network          | TRAC token address                           |
| ---------------- | -------------------------------------------- |
| Base Sepolia     | `0x2A58BdD13176D85906D804cdbFFA0D9119282DC8` |
| Gnosis Chiado    | `0x9cFa71394906fa38399aD305E7Ca97b00e3b4449` |
| NeuroWeb Testnet | `0xFfFFFFff00000000000000000000000000000001` |

{% hint style="info" %}
The test-TRAC faucet currently serves **Base Sepolia** only — that is the active V10 testnet. The Gnosis Chiado and NeuroWeb testnet addresses above are the existing test-token contracts (NeuroWeb uses the same address on mainnet and testnet). See the [deployments folder](https://github.com/OriginTrail/dkg/tree/main/packages/evm-module/deployments) for the canonical addresses.
{% endhint %}

## DKG smart contracts

The full set of DKG V10 contract deployments (Hub, Staking, Conviction, Random Sampling, ParametersStorage, …) lives in [`packages/evm-module/deployments`](https://github.com/OriginTrail/dkg/tree/main/packages/evm-module/deployments) — one file per network, listing every contract's on-chain address, version, and deployment block.

The **Hub** is the entry point — it resolves the addresses of every other V10 contract on a given network, so in most cases the Hub address is all you need. Note that V10 Hub addresses are **new** (they differ from V8 on every network, including mainnet).

| Network                | V10 Hub address                              |
| ---------------------- | -------------------------------------------- |
| Base (mainnet)         | `0x26146f51e31a95c075228a34cfc696f09e4c36c3` |
| Base Sepolia (testnet) | `0xC056e67Da4F51377Ad1B01f50F655fFdcCD809F6` |

{% hint style="info" %}
The Base mainnet Hub above is the pre-mainnet release-candidate deployment. Gnosis and NeuroWeb mainnet Hub addresses are published in the [deployments folder](https://github.com/OriginTrail/dkg/tree/main/packages/evm-module/deployments) as those networks' V10 contracts go live — use that folder as the source of truth.
{% endhint %}


# Bridging TRAC

TRAC is an ERC-20 token that originates on Ethereum. To use it on a DKG network — for funding nodes, staking, or publishing — you bridge it to that network. The TRAC token address on each chain is on the [Contract addresses](/general/contract-addresses) page.

## Base

Bridge TRAC from Ethereum to Base with [Superbridge](https://superbridge.app/base) (or any other Base bridge). See the [Base documentation](https://docs.base.org/) for more on bridging.

## Gnosis

Bridge TRAC from Ethereum to Gnosis with the [official Gnosis bridge](https://bridge.gnosischain.com/) or [OmniBridge](https://omnibridge.gnosischain.com/bridge).

## NeuroWeb

NeuroWeb is a permissionless, EVM-enabled Polkadot parachain; its native token is **NEURO** (used for gas). It evolved from the original OriginTrail Parachain via a December 2023 community governance vote. Dedicated docs live at [docs.neuroweb.ai](https://docs.neuroweb.ai/).

Bridge TRAC between Ethereum and NeuroWeb via [Snowbridge](https://app.snowbridge.network/). Step-by-step instructions are in the [NeuroWeb documentation](https://docs.neuroweb.ai/ethereum-neuroweb-trac-bridge).

### Adding TRAC on NeuroWeb to your wallet

The TRAC token address is the same on NeuroWeb mainnet and testnet:

```
0xFfFFFFff00000000000000000000000000000001
```

In MetaMask (connected to NeuroWeb): open **Assets → Import tokens** → paste the address above (the other fields auto-populate) → **Add custom token**. Your TRAC balance will then display.


# Whitepaper & RFCs

## Whitepaper

Explore the [OriginTrail Whitepaper](https://origintrail.io/ecosystem/whitepaper) for the vision behind a verifiable internet for AI — leveraging the synergies of crypto, internet, and AI technologies.

## RFCs (OT-RFCs)

OriginTrail development is transparent and guided by public technical **Requests for Comments (OT-RFCs)**. RFCs live in the [OT-RFC repository](https://github.com/OriginTrail/OT-RFC-repository).

### RFC lifecycle

* **Draft** — being written and discussed by the community.
* **Accepted** — approved by the core developers (after working-group and community discussion) and serving as a technical specification to be implemented.
* **Final** — implemented and merged into the codebase, tied to a specific client release.

### Contributing

Anyone can propose a new OT-RFC or comment on existing ones. Direct RFC discussions to the [RFC issues page](https://github.com/OriginTrail/OT-RFC-repository/issues) to keep the debate structured and long-term.


# Random Sampling

**Random Sampling** is the DKG's **Proof-of-Knowledge (PoK)** system: the mechanism that continuously verifies Core Nodes are actually storing the knowledge they claim to host, and that drives how network rewards are distributed.

Random Sampling is Core-only. A node must run with `nodeRole: "core"` and have a non-zero on-chain node profile (`identityId`) before the prover can bind. See [Core Node Profile Registration](/use-dkg/run-node#core-node-profile-registration) for setup and recovery.

## Why it exists

In a decentralized network, data availability can't be assumed — it has to be proven. Core Nodes host and serve Knowledge Assets, and Random Sampling lets the network constantly and randomly challenge them to prove they still hold specific data. The system:

* ensures knowledge remains available over time,
* rewards nodes that are consistently online and serving data, and
* provides a fair, automated way to distribute network rewards.

It is lightweight by design — nodes prove small slices of data rather than the whole graph — so it scales to billions of Knowledge Assets.

## How it works (high level)

1. **Challenge** — at the start of each *proof period*, an on-chain contract randomly selects a chunk of a Knowledge Collection for each Core Node to prove.
2. **Proof** — the node computes a Merkle proof for that chunk and submits it on-chain, where the contract verifies it.
3. **Score** — valid proofs accumulate into a node's score over each *epoch* (a longer reward cycle), reflecting uptime and the knowledge it serves.
4. **Rewards** — at the end of the epoch, rewards are distributed based on those scores.

Time is coordinated by two on-chain layers: **epochs** (long reward cycles) and **proof periods** (short, frequent challenge windows within each epoch).

## In V10

Random Sampling remains the core availability-proof system in V10. Staking and rewards are governed by the V10 **conviction** model — see [Conviction & Economics](/how-dkg-works/conviction-and-economics) for how staking, publishing, and rewards fit together.


# General Bug Bounty

To ensure the **security and proper functioning of our websites and applications,** Trace Labs has launched a dedicated bounty program. Each submission will be evaluated based on its severity and will correspond to a specific bounty reward.

## Vulnerability categories and rewards

* **Minor bug:** 50 TRAC
* **Medium bug:** 250 TRAC
* **Serious bug:** 500 TRAC
* **Critical bug:** 1000 TRAC

## Bug bounty rules

1. **Severity assessment:** The severity of each bug will be determined solely at the discretion of Trace Labs, based on both the likelihood and impact of the bug. All reward decisions are final.
2. **Submission process:** Please send your bug reports to [**bounty@origin-trail.com**](mailto:bounty@origin-trail.com) with the subject "WEBSITE/APP BUG BOUNTY." Upon receipt, we will evaluate the severity of the bug and contact you with further information. Submissions through other channels (e.g., social media) will not be accepted.

## Security vulnerabilities

* SQL injection.
* Cross-site scripting (XSS).
* Cross-site request forgery (CSRF).
* Remote code execution (RCE).
* Insecure configurations in web servers, databases, and application frameworks.
* Session hijacking and clickjacking.
* Sensitive data exposure.
* Unauthorized access to user accounts.
* Bypassing authentication mechanisms.
* Credentials exposure.
* Logic bypasses.

## Example submission template

```
**Title:** [Short description of the vulnerability]

**Description:**
[A detailed description of the vulnerability, including what it is and how it can be exploited]

**Steps to Reproduce:**
1. [First step]
2. [Second step]
3. [Further steps as necessary]

**Proof of Concept:**
[Include any screenshots, videos, or code snippets]

**Impact:**
[Explain the potential impact of the vulnerability]

**Suggested Fix:**
[Provide recommendations for how to fix the issue]

**Additional Information:**
[Any other information that might be relevant]

```

### Important restrictions

Please ensure you do not harm any live contracts on public networks while testing; otherwise, you will not be eligible for a bug bounty.

Leaking any vulnerability of the smart contracts on social media platforms or public channels will result in the cancellation of the bounty and might also invite legal action.

### Legal notice

We cannot issue rewards to individuals on sanctions lists or who reside in countries on sanctions lists. Depending on your country of residency and citizenship, you are responsible for any tax implications. Your local law may also impose additional restrictions.

This is a discretionary rewards program. We can cancel the program at any time, and the decision to pay a reward is entirely at Trace Labs' discretion.

Your testing must not violate any law or disrupt or compromise any data that is not your own.

{% hint style="warning" %}
To avoid potential conflicts of interest, we will not grant rewards to Trace Labs employees, employees who have left Trace Labs within the last 2 years, and contractors.
{% endhint %}


# V9 Archive

These pages are historical V9 material. They are preserved for audit, migration, and design archaeology only.

Use the current V10 docs for install, agent connection, memory lifecycle, publishing, peer connectivity, and operational guidance.

<table><thead><tr><th width="145">Section</th><th>Contains</th></tr></thead><tbody><tr><td><a href="https://github.com/OriginTrail/dkg/blob/main/docs/archive/v9/onboarding/00-overview.md">Onboarding</a></td><td>Historical V9 walkthroughs for publish, query, agent lifecycle, and package layout.</td></tr><tr><td><a href="https://github.com/OriginTrail/dkg/blob/main/docs/archive/v9/setup/JOIN_TESTNET.md">Setup</a></td><td>Historical setup and testnet notes.</td></tr><tr><td><a href="https://github.com/OriginTrail/dkg/blob/main/docs/archive/v9/specs/SPEC_PART1_MARKETPLACE.md">Specs</a></td><td>Historical protocol and economics specs.</td></tr><tr><td><a href="https://github.com/OriginTrail/dkg/blob/main/docs/archive/v9/plans/00_IMPLEMENTATION_PLAN.md">Plans</a></td><td>Historical implementation plans.</td></tr><tr><td><a href="https://github.com/OriginTrail/dkg/blob/main/docs/archive/v9/diagrams/publish-flow.md">Diagrams</a></td><td>Historical flow diagrams.</td></tr><tr><td><a href="https://github.com/OriginTrail/dkg/blob/main/docs/archive/v9/use_cases/KILLER_USE_CASES.md">Use cases</a></td><td>Historical V9 use-case notes.</td></tr><tr><td><a href="https://github.com/OriginTrail/dkg/blob/main/docs/archive/v9/future_ideas/README.md">Future ideas</a></td><td>Historical ideas that are not current V10 operating guidance.</td></tr><tr><td><a href="https://github.com/OriginTrail/dkg/blob/main/docs/archive/v9/misc/README.md">Miscellaneous</a></td><td>Historical branch notes, feedback, and other archived material.</td></tr></tbody></table>