Karatum Trading Assurance for Cancore bots

Status: prototype. Built from Cancore's public SDK source and documentation. There is no partnership with Cancore, Cancore has not reviewed or endorsed this, Karatum has no Cancore account, and it has not been run on the log of a live Cancore bot: every log in the tests is synthetic. The one outside input is a ten-entry log written by Cancore's own audit.ts on our machine, used to check that our hashing matches theirs.

Code: packages/trading (@karatum/trading). Method: trading-assurance.md.

#What Cancore gives us to read

Cancore is a trading venue on Canton Network and EVM chains. An AI agent trades there through @cancore/bot-mcp, which talks over a local unix socket to cancore-botd. The daemon holds the key of one bot account, checks every trade command against limits the owner set (default-deny), and writes each decision to audit.jsonl, a hash-chained, append-only log. Both packages are release candidates (0.1.0-rc.0), built from source and not on npm.

Everything below was read in Cancore's SDK repository, github.com/Cancore-io/sdk (Apache-2.0), at commit 79f804add8c5d13dca4ebc7a70a8fc2026a0cc0a:

Three properties of the log shape everything that follows:

1. An order.make entry has no order id. The daemon writes the entry before it calls the API and logs no result, so the id the venue assigns is in no entry of that order. order.take and order.cancel do carry the id, and so do settle entries.
2. The log records the command and the decision, not the state the decision was taken on. Reference prices, USD prices, positions and the open-order book are not in it.
3. The chain has no key and no outside witness. Cancore's docs say that audit verify does not catch a log cut at its end, and that the chain catches an edit, not a full replacement. The daemon catches a cut only against its own state file.

#What each track shows, and what it does not

The verdict statuses, scores and evidence classes are defined in the methodology.

#Run it on your own botd log

Nothing leaves your machine: the CLI reads local files and makes no network call.

# copies, not the live files (the daemon appends to audit.jsonl)
sudo cp /var/lib/cancore-bot/audit.jsonl /var/lib/cancore-bot/limits.json . && sudo chown "$USER" audit.jsonl limits.json

# 1. the chain, re-walked independently of cancore-bot (read-only; exit 0 intact, 3 broken)
pnpm exec tsx packages/trading/src/cli.ts verify-log audit.jsonl

# 2. the three tracks, as text
pnpm exec tsx packages/trading/src/cli.ts evaluate audit.jsonl --limits limits.json --orders-per-hour 5

# 3. the sealed report, and the part of it that may be published
pnpm exec tsx packages/trading/src/cli.ts report audit.jsonl --limits limits.json --out report.json
pnpm exec tsx packages/trading/src/cli.ts report audit.jsonl --limits limits.json --public --out report.public.json

Options:

Exit codes: 0 no track failed; 1 Execution Reliability or Risk Compliance is FAILURE; 2 usage or unreadable input; 3 the log does not verify.

To try it without a bot, the synthetic fixtures are in packages/trading/fixtures/cancore/ (manifest.json says what each one is):

F=packages/trading/fixtures/cancore
pnpm exec tsx packages/trading/src/cli.ts evaluate $F/synthetic-overlimit-allowed.audit.jsonl --limits $F/limits.json

#Order states (optional)

An export of order states lets the adapter name the made order that did not settle, replay takes in full, and compute PnL. The file is { "orders": [...], "ownOrderIds": [...] }, where orders are OrderResponseDto objects as Cancore's API returns them and ownOrderIds are the ids of the orders the bot made itself.

There is no credential-free way to get them. On devnet (https://api-dev.cancore.app, six unauthenticated GETs on 2026-11-06 21:17 UTC):

The OpenAPI spec marks /orders, /orders/my and /orders/{id} as bearer-only. The spec also lists GET /public/activity?partyId= (completed swap count and USD volume of a party) as public; we did not call it, having no party of our own to ask about. So order states need a session of the bot's own account, which is opened by signing a challenge with the bot's key. Karatum does not hold that key and should not. The owner exports the JSON with their own session, or a later live reader runs on the owner's machine. The code is a port (OrderStateSource in packages/trading/src/cancore/orders.ts) with one implementation that reads a file; a file is the owner's word, like the log, so it adds detail and does not raise the evidence class.

#Privacy

Canton is privacy-preserving: a trade is visible to its parties, not to the public. The assurance keeps that property.

• The audit log, the limits file and any order export stay with the owner. The CLI runs locally.
• The full report (report) quotes parameters in its findings and is for the owner.
• The public report (report --public) is what Karatum would publish or attest: the two verdict statuses and scores, counts, finding codes with the positions they refer to, the chain head, the sha256 of the log file and of the limits, and the hash of the full report. No pairs, amounts, prices, order ids, parties or per-entry hashes, and nothing from the performance track beyond the number of fills.
• The chain head and file hashes are commitments to low-entropy data without a salt. Confirming a guess would take the entire log, entry for entry; that is not practical for a real log, and it is a property to know about before publishing a head for a very short one.

Nothing is published today: the report format exists, the attestation of it does not.

#Limits of this integration

• Not run on a real bot. The parsing, hashing and replay follow Cancore's source at one commit of a release candidate. A later botd may change an entry or a rule; packages/trading/src/cancore/protocol.ts names the files to re-read, and the test against the log written by Cancore's audit.ts fails first if the hashing changes.
• The log is the operator's. An operator who controls the machine controls the log, the limits file and the daemon binary. Anchoring a head limits what can be rewritten afterwards; it does not make the daemon honest.
• The reconciliation of made orders from the log alone is by count, because the log has no id to reconcile by.
• The matching of made orders against an order export assumes the venue stores the amounts as the daemon sent them (base amount exact, quote amount within one part in a million). That has not been checked against a real order.
• Evidence class from a log alone is E1. Karatum's default certification policy asks for E3, so a log-only report is not certificate-eligible. See the methodology for what would raise it.

#What we would need from Cancore

See the one-page proposal: docs/investor/cancore-proposal.md.