Where Cartulary is today, what it is not yet, and the order of the work. Hosted features are marked built only when they run at this domain; separate experiments are marked built only when they have a reproducible implementation and a recorded run. And nothing unbuilt carries a date, because a date on an unbuilt thing is a promise nobody asked for. Everything not yet built says what must be true before it can ship.
One item is not a feature and does not appear below: the hosted multi-tenant deployment is a prototype convenience, not the target architecture. What that means, and what it costs to change, is on the architecture page.
A fictional treasury operation with real mechanics, open to anyone without an account, including a scripted screening incident and its hold.
Sign in, create an organisation, sign a policy, register agents, grant mandates, issue API keys, and make governed decisions on real requests.
USDC on Base Sepolia: the allow response is the unsigned transaction, the agent signs it with a key we never hold, and the settled receipt carries the transaction hash at depth.
npm install cartulary, and a receipt specification with a dependency-free verifier and adversarial vectors that run in CI.
Stated here rather than discovered later. Each of these is a real gap between what the product governs and what a regulated operator would need before trusting it with money that matters.
Everything on the rail today is test network and test value, labelled as such on every receipt. Moving real money needs custody integration, an operational runbook, and a written readiness gate.
Live screening receipts record not_screened, truthfully. The gateway exists; the engine and the vendor adapters behind it do not.
A narrow external-signing validator has been built and run against a local Canton network, using Canton's example Iou model: a prepared transaction is checked against its approval and its hash recomputed before anything is signed. It is not a stablecoin settlement, it is not integrated into the hosted application, and it has not run on DevNet, TestNet, or MainNet, which needs a participant to sponsor access.
No SOC 2 and no penetration test by a third party. The application now runs with least privilege, so it cannot alter evidence even if it tried, but tenant isolation is still enforced in application queries rather than by row-level policies. The security work is on the roadmap and stated rather than implied.
Grouped by the question each line of work exists to answer. Within a track, the order is the order of the work.
Who may spend, within what limits, and how is it stopped?
Agents, mandates, policies, payments, holds, and an append-only receipt chain, with live and simulated environments separated at the database by composite keys.
Every spend authority shown as granted and as enforced, across the emerging agent-payment protocols, with utilisation and one-action revocation that cancels scheduled spend.
A payment that violates its mandate or policy is never built. The attempt is receipted with the rule that refused it.
Principals, operators of record, and binding status, with one-action suspension that freezes every mandate an agent holds and stands between a signature and a relay.
A change is a new immutable version, shown as a diff with a seven-day backtest before anyone signs it. Operators, approvers, and auditors are invited by email and enforced in every action.
An approval decided at one moment cannot outlive the authority behind it: a revoked mandate or a tightened policy stops a payment that was already allowed, and the refusal joins its chain.
An agent that engages another, with authority narrowing at each hop and the whole chain legible from the payment.
Requires: Evidence from real deployments that sub-delegation happens in practice, rather than us inventing a hierarchy nobody asked for.
How does an approval become money, without us ever holding it?
The allow response is the unsigned transaction. The agent signs those exact bytes with a wallet only it holds, Cartulary verifies by recovery against the bound wallet, relays, and writes the settled receipt at depth. Test network, test value, said so on every receipt.
The SDK decodes the prepared transaction, checks the chain, token, recipient, and amount against what the caller asked for, and recomputes the signing hash. A replacement may raise its fees and change nothing else. Anything that disagrees is refused unsigned.
An expired template is reissued for the same payment, a stuck transaction is re-bid at the same nonce with only its fees raised, and a reorganisation appends an observation. Every recovery is receipted; nothing is corrected in place.
A narrow external-signing validator, run against a local Canton network using Canton's example Iou model. A transaction prepared by the participant is decoded and checked against the approved intent, its signing hash recomputed independently, and signed only once all of it agrees. Three tampered transactions with internally consistent hashes are refused, because a consistent lie can only be caught by comparison with the approval. The contract is committed and disclosed to both parties. It is not a stablecoin settlement, it is not integrated into the hosted application, and it has not run on DevNet, TestNet, or MainNet.
The same two gates against a shared network, reconciled to a real ledger update on a validator we do not run.
Requires: A DevNet or TestNet participant willing to sponsor access. We can build and demonstrate the adapter locally without one; we cannot fake a shared ledger.
Signing through the services institutions already use, behind the same two-method signer interface the SDK defines.
Requires: A design partner whose custody arrangement we build against. A reference AWS KMS signer exists; the rest is integration work that should follow a real counterparty, not precede one.
Real value, on a network that matters, with an operational runbook and a stated readiness gate.
Requires: Screening in force, custody integrated, a third-party security review, and a written gate covering incident response, key compromise, and reversal. Until every line of that is true, this stays unbuilt and the receipts keep saying test value.
Both legs or neither, receipted as one decision.
Requires: A rail where the other leg is representable, which would require extending the local Canton work above.
What can be proved afterwards, and to whom?
Every step of every decision as an append-only, hash-chained receipt, readable four ways: operator, auditor, examiner, and counterparty, verified by recomputation at render.
The same chain as a counterparty receives it: its own leg in full, the rest as linkage only. Disclosed hashes can be recomputed and sequence linkage checked; withheld contents, authorship, and completeness cannot.
The receipt schema, the protocol mapping, and the adapter note, published with a dependency-free verifier and adversarial vectors that run in CI, so anyone can check the disclosed chain integrity, the schema implementation, and the published test vectors without us.
Updates, deletes, and truncates on receipts are refused by the database itself. Cancelling scheduled spend appends a receipt rather than removing one.
Periodic commitment to the head of each organisation's evidence, so that dropping a whole chain or its tail becomes detectable rather than invisible.
Requires: A decision about where the anchor lives and who pays for it. This closes the largest stated hole in what the standard proves today, which is why it sits above newer features.
Receipts signed by the organisation's key, so that a chain proves who wrote it and not only that it is internally consistent.
Requires: Key management for organisations, and a considered answer on rotation and revocation. Until then the standard says plainly that self-consistency is not authorship.
What must be checked before the money moves, and reported after?
An unresolved alert is never forced into a binary: keep held and investigate, with requested evidence, an assigned investigator, and its own deadline, receipted.
Direct ingestion of the OFAC, OFSI, EU, and UN lists: versioned, fuzzy-matched, and re-screened retroactively when a list changes. The lists are public; the matching is ours.
Requires: Nothing external. This is the largest gap between what the product governs and what a regulated user would need on day one, which is why it is next rather than later.
Address attribution and existing KYC providers behind adapters. Data vendors feed the decision; they never make it.
Requires: The engine above, and a design partner's existing vendor contracts to build against.
Originator and beneficiary data on covered transfers, IVMS 101.
Requires: A counterparty institution to exchange with; the format is settled, the routing is not.
Blocking reports and suspicious activity preparation, with deadlines tracked from the receipt chain. The case-evidence format exists; filing and authenticated submission remain unbuilt.
Requires: A regulated entity of record to file as, which is a corporate question before it is a technical one.
Acting on a blocked verdict at the token layer, through issuer freeze and burn interfaces.
Requires: An issuer relationship. We can decide to block today; enforcing it at the token layer is not ours to do alone.
What makes it usable, operable, and safe to depend on?
One call decides allow, hold, or refuse and returns the receipts, callable against the simulated environment with a published test key.
Magic-link sign-in protects live data; the simulated console needs no account, because it is the front door.
npm install cartulary: TypeScript, two runtime dependencies checked with npm audit, and no user-supplied RPC endpoint. Decide, sign, submit, and settle test-value USDC on Base Sepolia in one call; refusals throw the rule that refused them.
The rail without a terminal: connect a wallet, see the decision, read the prepared transaction decoded and checked against what you asked for, sign in the browser, and follow it to its settled receipt. The wallet signs; it does not get to decide what it is signing.
Cartulary connects as a role that owns nothing and holds no update or delete on receipts or the audit log. Evidence is append-only by privilege rather than by trigger alone: the application cannot alter a receipt, cannot disable a trigger, and cannot drop one.
Row-level policies keyed to the requesting organisation, so that a forgotten clause in a query cannot become a cross-tenant disclosure.
Requires: Every request to carry its organisation into the database session, and every policy rewritten against that rather than against a browser identity. Today isolation is enforced in application queries, which we would rather state here than have someone find.
Decision and hold events pushed to your systems as they happen, signed and replayable.
Requires: Someone waiting on a hold who should not have to poll for it.
Per decision. Published, not negotiated.
Requires: Enough real usage to know what a decision costs us to make.
A penetration test first, because it changes the product; the controls journey after, visible here as it happens.
Requires: Isolation hardening above, and a budget. An audit of an unhardened system buys a certificate, not security.
Scope cuts are recorded here, not deleted. If something on this page turns out to be wrong, it changes here first.