COSMO · Manifesto v6.0
Verifiable Liquidity Mandates
Delegate liquidity operations without delegating blind trust.
Capital owners define the mandate.
Agents execute within hard limits.
COSMO proves every action.
In one sentence
COSMO is a control and verification layer for market makers and liquidity agents managing third-party capital. Capital owners issue bounded mandates covering venues, assets, amounts, slippage, gas and execution limits. Every action ends in an independently verifiable execution and settlement receipt.
1. The delegation problem
Capital rarely sits with the people who operate it. Protocols, foundations, DAOs, treasuries and investors entrust liquidity work to market makers, liquidity managers and, increasingly, to autonomous agents. The operator brings skill and speed. The capital owner brings the money and carries the loss.
For a long time the interesting question was whether an agent could trade at all. That question is settled. The question that decides whether third-party capital will ever be handed to a machine is different:
The driving question
How does a capital owner delegate execution to a market maker or agent without handing over a wallet key with blanket authority?
Today the honest answers are poor. A private key is all or nothing. Co-signing every transaction recentralizes the work that was supposed to be delegated. A monthly report is written by the party being measured. Limits live in a policy document, execution lives in a bot, settlement lives on a chain, and the three disagree exactly when it matters.
COSMO exists for this gap: between the capital owner who must set the terms and the operator who must act within them, with a proof in between that neither side has to take on faith.
2. What a capital owner does not want
Every conversation with a capital owner ends up at the same five refusals. They are the specification.
- An unrestricted private key. Whoever holds the key can do everything the key can do. Possession is not a mandate.
- Signing every transaction by hand. Manual co-signing does not scale to liquidity work and re-centralizes exactly what was delegated.
- Trusting the operator's own reports. Reporting is produced by the party being measured. It is an account, not a proof.
- Learning about a breach after the loss. Limits that are only checked in hindsight are not limits. They are forensics.
- Reassembling the story from three systems. Authorization, execution and settlement live in different tools and are reconciled by hand, if at all.
Delegation without blanket authority.
Autonomy without free disposal.
Proof instead of
reporting.
3. What one mandate binds
A Verifiable Liquidity Mandate is one document, sealed by its hash before anything runs, that binds all of the following into a single checkable object:
- the capital owner and the operator, whether a market maker, a liquidity manager or an autonomous agent;
- the permitted markets and venues, pinned by contract address and by the runtime code hash of the venue;
- amount, position and inventory limits;
- slippage and gas bounds;
- duration and the number of permitted actions;
- retry and stop rules;
- one-shot or time-bounded authorization;
- the actual execution and its settlement;
- an independently checkable receipt.
Change one byte of the mandate and it is a different mandate with a different hash. That is the point. The mandate is not a description of what the operator promised. It is the identity under which every later step is recorded and judged.
4. The life of a mandate
Mandate. The capital owner's terms become one signed, one-shot mandate: venue, amount, limits, expiry. No mandate, no action.
Policy. The rules are hash-pinned before anything runs and default to reject. A venue that drifts, a code hash that moves, a cap that would be breached ends the case fail-closed. The rules are not invented after the outcome.
Ceremony. The engine stops at the irreversible boundary and waits. A human arms the step, case-bound, fresh, exactly once. In the current trust model this human step is part of the authority design, not a shortcoming of it. Autonomy ends where capital moves.
Execution. Fresh quote, simulation and gas check against the mandated bounds, then exactly one submit. There is no automatic retry. An attempt that cannot satisfy its own preconditions stops itself before a signature exists.
Settlement. The case watches the chain until the transaction is canonical with the mandated confirmations, and compares what settled with what was signed.
Receipt and verification. A signed receipt closes the case over hash-chained evidence. A standalone verifier re-checks the whole case from the files alone, with no network and no access to the engine that produced them.
Termination. A mandate names its own end. When the term expires or the last permitted action is spent, a termination proof reads the chain at a pinned block and derives the closing facts: capital exposure zero, standing approvals zero, authority ended, ownership with the capital owner, every transaction the execution wallet ever sent mapped to an archived receipt. What cannot be proven, such as the destruction of a signing seed, is recorded as an attestation with a standing falsification rule and a watch that keeps reading the chain.
The rule behind the last step
A mandate that cannot provably end was never fully specified.
5. Limiting is not proving
Wallet and policy systems can limit what an agent may spend, and that is valuable. A limit answers one question: was this action blocked or allowed? It does not answer the questions a capital owner asks after the fact.
COSMO additionally proves, for every action: which mandate applied; which policy was enforced and under which hash; which market conditions were checked before the step; which exact transaction was prepared; what was actually sent; what settled on chain; whether amount, route, slippage, gas and retry rules were honored; and that a separate verifier, run by anyone from the published files, reaches the same verdict.
The difference is the difference between a lock and a ledger. A lock keeps things out. A ledger lets a third party check, later and without asking, what went in and out and under whose authority.
6. The foundation: seven primitives, one Execution Case
The mandate is the product. Underneath it sits a framework COSMO built and proved before the first liquidity mandate existed. It began with a deliberately narrow problem: let an agent perform one real trade without unrestricted control over the principal's account. Solving it required a bounded delegate, a one-shot mandate, rules fixed before execution, a human ceremony at the irreversible boundary, a tamper-evident record, a signed receipt and a separate consistency check. Almost none of that was about trading.
| # | Primitive | Function |
|---|---|---|
| 1 | Delegated authority | A standing but bounded permission: delegate key, scope, caps, expiry and on-chain revoke. |
| 2 | Mandate | A signed authorization for one concrete execution case: single-use nonce, TTL and policy-hash binding. |
| 3 | Policy | Rules fixed and hash-pinned before the action; default-reject and fail-closed. |
| 4 | Ceremony | Explicit arming of the irreversible step. In the current trust model, a human ARM. |
| 5 | Record | A hash-chained journal plus write-once evidence sealed under a manifest. |
| 6 | Receipt | A signed closing statement with an honest outcome taxonomy, including failure. |
| 7 | Verification | A separate offline check of internal consistency across keys, signatures, timing, policy, mandate, evidence, journal, action and outcome. |
Delegated authority and the mandate are deliberately different things. The first is the standing permission a case runs under. The second authorizes one case within that permission. Possession of a key is never treated as permission.
The core object is the Execution Case: one reconstructable process that binds principal, agent, action, budget, policy, authorization, evidence and closing outcome. A rejected, expired or failed case is a valid record if it truthfully represents what the system knew and did.
The sentence that carries the foundation
Capability is copyable. Authority is not.
The trade was the occasion. The primitives became the framework. The mandate became the offer.
7. Proof
The Agent Economy is full of narratives. COSMO should be judged by evidence. Five public proof stages anchor this manifesto; the first two ran with real capital on Ethereum mainnet, the other three on Supra. Every row carries its honest scope next to its claim.
| Proof | What happened | Honest scope |
|---|---|---|
| VLM-001 Verifiable Liquidity Mandate Ethereum mainnet 2026-08-22 → 2026-09-05 |
A sponsor-funded liquidity mandate with wei-exact caps, an exact action list and an expiry date was sealed by hash and executed: the LP position was opened and minted directly to the sponsor, standing approvals were reset to zero, and six days later the position was closed with the proceeds paid straight to the sponsor. Four lifetime transactions. OPEN, RESET and CLOSE each verified ACCEPT 10/10 by the internal verifier and by the public standalone verifier 1.3.2. After expiry, a termination proof derived five predicates on chain at a pinned block on two independent RPCs, and the signing seed was retired under a falsifiable attestation with a standing nonce watch. | EUR 40 total budget, one pool, a full-range position. COLLECT was permitted and never executed. The just-in-time funding transaction hashes were not archived; the wei-exact match is proven by balance reads on two RPCs. Receipt of the close proceeds is proven from settlement evidence and transfer logs, not by the dedicated sweep-proof verb. Seed deletion is attested, not proven. This is not market making. |
| EVM-MICRO-001 Bounded swaps Ethereum mainnet 2026-08-20 |
Two bounded swaps of 0.0001 ETH into SUPRA through a hash-pinned pool and router, with slippage and gas caps, a case-bound human ARM and exactly one submit each. Trade 1 executed correctly and exposed a defect in the internal verifier, which compared settlement fields in a key-order-sensitive way; the standalone verifier accepted. After the repair, without touching the live bundle, both verifiers accepted. Trade 2 ran on the approved state and verified with no post-run repair of any kind. | Micro scale. Both transactions are public on Ethereum (blocks 25,796,272 and 25,796,695); the case bundles themselves are not published. Two administrative implementations behind the pool's SUPRA token remain unverified, accepted for this size and not for larger ones. |
| Case 001 FX / SupraFX 2026-08-14 |
A micro-live SUPRA/USDC trade ran through delegated authority, mandate, policy, ARM, execution, receipt and verification. EXECUTED, ACCEPT 10/10. The delegate was later revoked on chain. | One pair, one venue, micro scale. Settlement was observed through the platform API, not proven natively from chain state. |
| Case 002 Market work delivery 2026-08-14 |
A solver delivered a pre-mandated result hash for a live marketplace job. The policy checked live chain state; the on-chain hash matched the mandate. EXECUTED, ACCEPT 10/10. | The case ended at DELIVERED. The later buyer approval was a direct human action outside this case. |
| Case 002-G Delivery + acceptance 2026-08-15 |
On a second live job, provider delivery and buyer acceptance were each executed as separate one-shot mandated cases. The approval atomically released 5 wCOSMO escrow. Both cases closed EXECUTED and verified ACCEPT 10/10. | The same operator armed both ceremonies. Role separation was cryptographic, not organizational independence. |
Public material: the VLM-001 proof page and its evidence bundle; the EVM-MICRO-001 transactions on Ethereum, linked from /mandates/; the bundles for Case 001, Case 002 and Case 002-G; the narrative overview at /institutional/; the public verifier at /verifier/.
Failures are part of the proof
Between 2026-08-22 and 2026-08-28, six armed attempts to close VLM-001 stopped themselves before signing anything: a fee cap exceeded, RPC errors, a pre-approve read gate. Each left a journal ending in a named failure and no signature. The verifier version published before the live policy pins existed returned REJECT against the same cases; those REJECT files stayed in the bundle next to the ACCEPTs of the version that carries the pins. Two failed Case 002 attempts, one before network contact and one expired because the ARM arrived late, were likewise kept and never relabelled.
A mandate system that cannot name its failures cannot be audited.
8. Truth, observation and verification
A verifier can only prove what its evidence model allows. COSMO verifies internal consistency and record integrity: that the receipt, the journal, the evidence, the policy pins, the mandate and the observed settlement agree with each other and with the signatures over them. It does not claim universal world truth.
- A platform observation can be internally consistent and still be wrong about external reality.
- An on-chain state transition is a stronger anchor than an application balance observation.
- A self-attested receipt is not the same as an independent third-party attestation.
- Without reference-market comparison data there is no best-execution claim, only a bounded-execution claim.
Current verification boundary
The standalone verifier is public: a single self-contained file at heros.cloud/verifier/, currently version 1.3.2, with a pinned source hash so anyone can check the file they run. It performs a separate offline check of internal consistency against a published trust profile. It is not an independent third-party attestation. The engine that produces the evidence is a single attestor, not an attestor network.
Those limits are stated next to the claims they qualify, and they will be moved only by evidence: an independent operator, a second attestor, or reference-market data that exists.
9. Roles, and what COSMO is not
| Role | Who |
|---|---|
| Capital owner | Protocol, foundation, DAO, treasury, investor. Defines markets, amounts, limits, term and authority. |
| Operator | Market maker, liquidity manager, autonomous agent. Executes inside the mandate. |
| COSMO | The mandate, control, execution and proof layer between them. |
COSMO is explicitly not the market maker, not a trading strategy, not a DEX, not a custodian, not merely an agent wallet, not a profitability promise and not a general trading bot. It is not a foundation model, a chatbot, an identity provider, a reputation oracle or a regulator.
What COSMO does not claim
- no guaranteed capital safety;
- no guaranteed profitability;
- no regulatory or legal compliance status;
- no best execution while no reference-market comparison data exists;
- no fully autonomous market making;
- no support for arbitrary chains, routers or strategies;
- no production readiness derived from bounded pilots alone;
- no demonstrated external demand.
What it does is narrower: it makes the authority, the rules, the action, the evidence and the recorded outcome of a liquidity operation explicit, bounded and checkable by someone who was not in the room.
10. Beyond liquidity
The first pilot does not need to automate a full market-making strategy. A single bounded rebalancing or one bounded liquidity action is enough to prove the mechanism, and that is what has been proven. The same mandate shape covers a family of operations a capital owner may want to delegate:
- bounded treasury rebalancing;
- deploying capital into approved liquidity pools;
- rebalancing inventory across approved assets;
- hedging holdings within preset limits;
- building or withdrawing liquidity by fixed rules;
- later: proving execution quality against external reference markets.
Demonstrated so far: one bounded liquidity-pool mandate, two bounded swaps and mandated marketplace work. Everything else on that list is an application to validate, not a shipped fact. Controlled treasury execution is the second story; the category behind both is execution and assurance infrastructure for agent economies. Terms like "institutional layer" or "execution layer" remain valid category labels. They are no longer the first sentence.
The same discipline extends to venues. A venue that wants its settlements to count as evidence can issue a small, signed, falsifiable statement per settlement; COSMO has published a venue-neutral requirements document for that at /vsa/. It raises venue claims from dashboard data to attested and falsifiable, never to proven.
11. Built on Supra, proven where the capital was
| Layer | Role |
|---|---|
| Models / skills | What agents can reason about and perform. |
| Identity / Web of Trust | Who an actor is and how trust paths are formed. |
| SupraOS | Coordination: how agents are organized, composed and connected to workflows. |
| SupraFX | Market and liquidity rails: price, depth, routing and venues. |
| COSMO | Mandates, policies, ceremony, records, receipts and verification around autonomous action. |
| Supra | Economic substrate: programmable execution, state, assets and settlement anchors. |
COSMO is built on Supra and complementary to SupraOS and SupraFX. The winning story is composition, not competition. The liquidity pilots ran where the entrusted capital happened to be, on Ethereum mainnet; the marketplace and FX cases ran on Supra. Two chains with real capital is a fact about two pilots. It is not a claim of support for arbitrary chains, routers or strategies.
12. The Controlled Liquidity Pilot
The offer is deliberately small, because a small offer can be proven end to end.
- one capital owner;
- one market maker or agent;
- one trading pair;
- one approved venue;
- one bounded capital mandate;
- one concrete liquidity or rebalancing action;
- one independently checkable closing record.
Run one bounded liquidity mandate with real capital and independently verify the result.
The pilot is curated: one engagement at a time, scoped together with the capital owner before any mandate is signed. Start at heros.cloud/mandates/.
13. $COSMO and the community
The mandate thesis does not by itself prove a token economy. Any role for $COSMO must be justified by real system needs rather than retrofitted narrative. Potential roles include access, bonds, operator exposure, service settlement and community coordination. Each should be evaluated by one question: does it improve accountability, or does it merely add a token where none is needed?
The community that matters is not an audience around a claim. It is the network of operators, capital owners, verifier scrutinizers and domain builders that can run, challenge and improve the mandate discipline, and that produces the external demand the mechanism still has to earn.
14. Principles
- Capital owners define the mandate. Agents execute within hard limits. COSMO proves every action.
- Possession of a key is not a mandate.
- Capability is copyable. Authority is not.
- Every irreversible action needs a bounded mandate.
- Policy is fixed before execution, not invented after the outcome.
- Limits checked in hindsight are forensics.
- Reporting is an account. A receipt is a proof only if someone else can re-run it.
- A mandate names its own end.
- Failure must close with a named, signed outcome.
- On-chain state is stronger than platform observation when available.
- Human authorization is valid architecture when the trust model requires it.
- Domain economics may differ while integrity guarantees remain shared.
- COSMO complements SupraOS and SupraFX; it does not compete with them.
- Public evidence matters more than pitch decks.
- A demonstrated mechanism is not the same as demonstrated demand.
15. The declaration
We believe capital will be delegated to machines, and that the terms of that delegation will decide who is trusted with it.
We believe a capital owner should never have to choose between a blank cheque and doing the work by hand.
We believe an operator who works within hard limits and leaves a verifiable trail deserves more capital than one who asks to be trusted.
We believe a limit that cannot be proven afterwards was never a limit, and a mandate that cannot end was never fully written.
We believe the proof of an action belongs to the party who bears its risk, in a form that party can check without asking anyone.
We believe Supra can become a home for this economy because execution, automation, data, markets and agent infrastructure are converging there, with SupraFX providing market rails and SupraOS providing coordination, while COSMO provides the mandate and proof discipline around autonomous action.
We are not building a smarter trading bot. We are building the layer that answers: whose capital, under which mandate, within which limits, what happened, and how can the outcome be checked?
COSMO exists for that answer.
16. Public short version
COSMO lets market makers and liquidity agents deploy third-party capital without requiring blind trust. A capital owner issues one bounded mandate covering venues, assets, amounts, slippage, gas, action count and term. The mandate is sealed by hash, the policy is pinned before execution, a human arms the irreversible step, exactly one transaction is submitted, settlement is checked against what was signed, and a signed receipt closes the case. A public standalone verifier re-checks the whole case from the files alone. The mechanism has been proven with real capital on Ethereum mainnet, including a complete mandate lifecycle through to termination, and across two economic domains on Supra. COSMO is built on Supra and complements SupraOS and SupraFX. Evidence and verifier: heros.cloud/mandates/ and heros.cloud/verifier/.
Appendix: creator and community lines
- Capital owners define the mandate. Agents execute within hard limits. COSMO proves every action.
- Delegate the work, not the key.
- A limit you can only check afterwards is forensics.
- Reporting is an account. A receipt is a proof.
- A mandate names its own end.
- Capability can scale. Authority must stay bounded.
- Agents do not need a blank cheque. They need a mandate.
- COSMO turns "can do" into a provable "may do".
- One verification entry point. Shared integrity. Domain-specific economics.
- COSMO compiles safeguards into execution.
In einem Satz
COSMO ist eine Kontroll- und Verifikationsschicht für Market Maker und Liquiditätsagenten, die fremdes Kapital einsetzen. Kapitalgeber erteilen begrenzte Mandate über Venues, Assets, Beträge, Slippage, Gas und Ausführungsgrenzen. Jede Handlung endet in einem unabhängig prüfbaren Ausführungs- und Settlement-Receipt.
1. Das Delegationsproblem
Kapital liegt selten bei denen, die damit arbeiten. Protokolle, Foundations, DAOs, Treasuries und Investoren vertrauen Liquiditätsarbeit Market Makern, Liquiditätsmanagern und zunehmend autonomen Agenten an. Der Operator bringt Können und Geschwindigkeit. Der Kapitalgeber bringt das Geld und trägt den Verlust.
Lange war die spannende Frage, ob ein Agent überhaupt handeln kann. Diese Frage ist beantwortet. Die Frage, die entscheidet, ob fremdes Kapital je einer Maschine übergeben wird, ist eine andere:
Die Leitfrage
Wie delegiert ein Kapitalgeber Ausführung an einen Market Maker oder Agenten, ohne einen Wallet-Key mit Blankovollmacht aus der Hand zu geben?
Die ehrlichen Antworten sind heute schlecht. Ein Private Key ist alles oder nichts. Das Mitsignieren jeder Transaktion zentralisiert die Arbeit wieder, die delegiert werden sollte. Der Monatsbericht wird von der Partei geschrieben, die gemessen wird. Grenzen stehen in einem Policy-Dokument, die Ausführung läuft in einem Bot, das Settlement liegt auf einer Chain, und die drei widersprechen sich genau dann, wenn es darauf ankommt.
COSMO setzt in dieser Lücke an: zwischen dem Kapitalgeber, der die Bedingungen setzen muss, und dem Operator, der innerhalb dieser Bedingungen handeln muss, mit einem Beweis dazwischen, den keine Seite glauben muss.
2. Was ein Kapitalgeber nicht will
Jedes Gespräch mit einem Kapitalgeber endet bei denselben fünf Ablehnungen. Sie sind die Spezifikation.
- Ein unbeschränkter Private Key. Wer den Key hält, kann alles, was der Key kann. Besitz ist kein Mandat.
- Jede Transaktion von Hand signieren. Manuelles Mitsignieren skaliert nicht für Liquiditätsarbeit und zentralisiert genau das, was delegiert wurde.
- Den eigenen Berichten des Operators vertrauen. Ein Bericht wird von der Partei erstellt, die gemessen wird. Er ist eine Darstellung, kein Beweis.
- Von einer Grenzverletzung erst nach dem Verlust erfahren. Grenzen, die nur im Nachhinein geprüft werden, sind keine Grenzen. Sie sind Forensik.
- Die Geschichte aus drei Systemen zusammensetzen. Autorisierung, Ausführung und Settlement leben in verschiedenen Werkzeugen und werden von Hand abgeglichen, wenn überhaupt.
Delegation ohne Blankovollmacht.
Autonomie ohne freie Verfügung.
Beweis statt
Bericht.
3. Was ein Mandat bindet
Ein Verifiable Liquidity Mandate ist ein Dokument, das vor jeder Ausführung durch seinen Hash versiegelt wird und alles Folgende zu einem einzigen prüfbaren Objekt bindet:
- den Kapitalgeber und den Operator, ob Market Maker, Liquiditätsmanager oder autonomer Agent;
- die erlaubten Märkte und Venues, gepinnt über Contract-Adresse und Laufzeit-Codehash der Venue;
- Betrags-, Positions- und Inventargrenzen;
- Slippage- und Gas-Schranken;
- Laufzeit und Anzahl erlaubter Aktionen;
- Retry- und Stop-Regeln;
- einmalige oder zeitgebundene Autorisierung;
- die tatsächliche Ausführung und ihr Settlement;
- ein unabhängig prüfbares Receipt.
Ein geändertes Byte im Mandat ergibt ein anderes Mandat mit einem anderen Hash. Genau das ist der Punkt. Das Mandat beschreibt nicht, was der Operator versprochen hat. Es ist die Identität, unter der jeder spätere Schritt aufgezeichnet und beurteilt wird.
4. Das Leben eines Mandats
Mandat. Die Bedingungen des Kapitalgebers werden zu einem signierten, einmaligen Mandat: Venue, Betrag, Grenzen, Ablauf. Kein Mandat, keine Handlung.
Policy. Die Regeln werden per Hash gepinnt, bevor irgendetwas läuft, und lehnen im Zweifel ab. Eine Venue, die driftet, ein Codehash, der sich bewegt, eine Grenze, die verletzt würde, beendet den Fall fail-closed. Die Regeln werden nicht nach dem Ergebnis erfunden.
Zeremonie. Die Engine hält an der unumkehrbaren Grenze an und wartet. Ein Mensch scharft den Schritt: fallgebunden, frisch, genau einmal. Im aktuellen Trust-Modell ist dieser menschliche Schritt Teil des Autoritätsdesigns, nicht sein Mangel. Autonomie endet dort, wo Kapital sich bewegt.
Ausführung. Frisches Quote, Simulation und Gas-Prüfung gegen die mandatierten Schranken, dann genau ein Submit. Es gibt keinen automatischen Retry. Ein Versuch, der seine eigenen Vorbedingungen nicht erfüllt, stoppt sich selbst, bevor eine Signatur existiert.
Settlement. Der Fall beobachtet die Chain, bis die Transaktion mit den mandatierten Bestätigungen kanonisch ist, und vergleicht, was gesettelt wurde, mit dem, was signiert wurde.
Receipt und Verifikation. Ein signiertes Receipt schließt den Fall über hash-verketteter Evidence. Ein Standalone-Verifier prüft den gesamten Fall allein aus den Dateien nach, ohne Netz und ohne Zugriff auf die Engine, die sie erzeugt hat.
Beendigung. Ein Mandat benennt sein eigenes Ende. Wenn die Laufzeit abläuft oder die letzte erlaubte Aktion verbraucht ist, liest ein Terminierungsbeweis die Chain an einem gepinnten Block und leitet die Schlussfakten ab: Kapitalexposition null, offene Freigaben null, Autorität beendet, Eigentum beim Kapitalgeber, jede Transaktion, die das Ausführungs-Wallet je gesendet hat, einem archivierten Receipt zugeordnet. Was nicht beweisbar ist, etwa die Vernichtung eines Signatur-Seeds, wird als Attestation mit einer stehenden Falsifikationsregel und einer Watch aufgezeichnet, die die Chain weiter liest.
Die Regel hinter dem letzten Schritt
Ein Mandat, das nicht beweisbar enden kann, war nie vollständig spezifiziert.
5. Begrenzen ist nicht beweisen
Wallet- und Policy-Systeme können begrenzen, was ein Agent ausgeben darf, und das ist wertvoll. Eine Grenze beantwortet eine Frage: wurde diese Handlung blockiert oder erlaubt? Sie beantwortet nicht die Fragen, die ein Kapitalgeber hinterher stellt.
COSMO beweist zusätzlich, für jede Handlung: welches Mandat galt; welche Policy unter welchem Hash durchgesetzt wurde; welche Marktbedingungen vor dem Schritt geprüft wurden; welche exakte Transaktion vorbereitet wurde; was tatsächlich gesendet wurde; was auf der Chain gesettelt wurde; ob Betrags-, Routen-, Slippage-, Gas- und Retry-Regeln eingehalten wurden; und dass ein separater Verifier, den jeder aus den veröffentlichten Dateien ausführen kann, zum selben Urteil kommt.
Der Unterschied ist der zwischen einem Schloss und einem Hauptbuch. Ein Schloss hält Dinge draußen. Ein Hauptbuch lässt einen Dritten später und ohne zu fragen prüfen, was hinein- und hinausging und unter wessen Autorität.
6. Das Fundament: sieben Primitive, ein Execution Case
Das Mandat ist das Produkt. Darunter liegt ein Rahmen, den COSMO gebaut und bewiesen hat, bevor das erste Liquiditätsmandat existierte. Er begann mit einem bewusst engen Problem: ein Agent soll einen echten Trade ausführen, ohne unbeschränkte Kontrolle über das Konto des Prinzipals. Die Lösung brauchte einen begrenzten Delegate, ein einmaliges Mandat, vor der Ausführung fixierte Regeln, eine menschliche Zeremonie an der unumkehrbaren Grenze, eine manipulationssichere Aufzeichnung, ein signiertes Receipt und eine separate Konsistenzprüfung. Fast nichts davon hatte mit Trading zu tun.
| # | Primitiv | Funktion |
|---|---|---|
| 1 | Delegierte Autorität | Eine stehende, aber begrenzte Erlaubnis: Delegate-Key, Scope, Caps, Ablauf und On-Chain-Widerruf. |
| 2 | Mandat | Eine signierte Autorisierung für einen konkreten Execution Case: Einmal-Nonce, TTL und Policy-Hash-Bindung. |
| 3 | Policy | Regeln, die vor der Handlung fixiert und per Hash gepinnt sind; Default-Reject und fail-closed. |
| 4 | Zeremonie | Explizites Scharfschalten des unumkehrbaren Schritts. Im aktuellen Trust-Modell ein menschlicher ARM. |
| 5 | Record | Ein hash-verkettetes Journal plus write-once Evidence, versiegelt unter einem Manifest. |
| 6 | Receipt | Eine signierte Abschlusserklärung mit ehrlicher Ergebnistaxonomie, Scheitern eingeschlossen. |
| 7 | Verifikation | Eine separate Offline-Prüfung der internen Konsistenz über Keys, Signaturen, Timing, Policy, Mandat, Evidence, Journal, Handlung und Ergebnis. |
Delegierte Autorität und Mandat sind bewusst verschiedene Dinge. Das erste ist die stehende Erlaubnis, unter der ein Fall läuft. Das zweite autorisiert einen Fall innerhalb dieser Erlaubnis. Der Besitz eines Keys wird nie als Erlaubnis behandelt.
Das Kernobjekt ist der Execution Case: ein rekonstruierbarer Prozess, der Prinzipal, Agent, Handlung, Budget, Policy, Autorisierung, Evidence und Abschlussergebnis bindet. Ein abgelehnter, abgelaufener oder gescheiterter Fall ist eine gültige Aufzeichnung, wenn er wahrheitsgemäß wiedergibt, was das System wusste und tat.
Der Satz, der das Fundament trägt
Capability is copyable. Authority is not.
Der Trade war der Anlass. Die Primitive wurden zum Rahmen. Das Mandat wurde zum Angebot.
7. Beweise
Die Agent Economy ist voller Erzählungen. COSMO soll an Evidence gemessen werden. Fünf öffentliche Beweisstufen tragen dieses Manifest; die ersten beiden liefen mit echtem Kapital auf Ethereum Mainnet, die anderen drei auf Supra. Jede Zeile trägt ihre ehrliche Reichweite neben ihrem Anspruch.
| Beweis | Was geschah | Ehrliche Reichweite |
|---|---|---|
| VLM-001 Verifiable Liquidity Mandate Ethereum Mainnet 2026-08-22 → 2026-09-05 |
Ein sponsorfinanziertes Liquiditätsmandat mit wei-exakten Caps, einer exakten Aktionsliste und einem Ablaufdatum wurde per Hash versiegelt und ausgeführt: die LP-Position wurde eröffnet und direkt an den Sponsor gemintet, offene Freigaben wurden auf null zurückgesetzt, und sechs Tage später wurde die Position geschlossen, mit Auszahlung der Erlöse direkt an den Sponsor. Vier Transaktionen im gesamten Leben des Wallets. OPEN, RESET und CLOSE jeweils ACCEPT 10/10 durch den internen Verifier und den öffentlichen Standalone-Verifier 1.3.2. Nach Ablauf leitete ein Terminierungsbeweis fünf Prädikate on-chain an einem gepinnten Block über zwei unabhängige RPCs ab, und der Signatur-Seed wurde unter einer falsifizierbaren Attestation mit stehender Nonce-Watch stillgelegt. | Gesamtbudget EUR 40, ein Pool, eine Full-Range-Position. COLLECT war erlaubt und wurde nie ausgeführt. Die Hashes der Just-in-time-Funding-Transaktionen wurden nicht archiviert; die wei-exakte Übereinstimmung ist durch Balance-Reads auf zwei RPCs bewiesen. Der Empfang der Schließungserlöse ist aus Settlement-Evidence und Transfer-Logs bewiesen, nicht durch das dedizierte Sweep-Proof-Verb. Die Seed-Löschung ist attestiert, nicht bewiesen. Das ist kein Market Making. |
| EVM-MICRO-001 Begrenzte Swaps Ethereum Mainnet 2026-08-20 |
Zwei begrenzte Swaps von je 0,0001 ETH in SUPRA über einen hash-gepinnten Pool und Router, mit Slippage- und Gas-Caps, einem fallgebundenen menschlichen ARM und genau einem Submit pro Trade. Trade 1 wurde korrekt ausgeführt und deckte einen Defekt im internen Verifier auf, der Settlement-Felder abhängig von der Schlüsselreihenfolge verglich; der Standalone-Verifier akzeptierte. Nach der Reparatur, ohne das Live-Bundle anzufassen, akzeptierten beide Verifier. Trade 2 lief auf dem freigegebenen Stand und verifizierte ohne jede Nachbesserung. | Mikroformat. Beide Transaktionen sind auf Ethereum öffentlich (Blöcke 25.796.272 und 25.796.695); die Case-Bundles selbst sind nicht veröffentlicht. Zwei administrative Implementierungen hinter dem SUPRA-Token des Pools bleiben unverifiziert, akzeptiert für diese Größe, nicht für größere. |
| Case 001 FX / SupraFX 2026-08-14 |
Ein Micro-Live-Trade SUPRA/USDC lief durch delegierte Autorität, Mandat, Policy, ARM, Ausführung, Receipt und Verifikation. EXECUTED, ACCEPT 10/10. Der Delegate wurde später on-chain widerrufen. | Ein Paar, eine Venue, Mikroformat. Das Settlement wurde über die Plattform-API beobachtet, nicht nativ aus dem Chain-State bewiesen. |
| Case 002 Marktplatz-Lieferung 2026-08-14 |
Ein Solver lieferte einen vorab mandatierten Ergebnis-Hash für einen echten Marktplatz-Job. Die Policy prüfte den Live-Chain-State; der On-Chain-Hash entsprach dem Mandat. EXECUTED, ACCEPT 10/10. | Der Fall endete bei DELIVERED. Die spätere Abnahme durch den Käufer war eine direkte menschliche Handlung außerhalb dieses Falls. |
| Case 002-G Lieferung + Abnahme 2026-08-15 |
Auf einem zweiten echten Job wurden Provider-Lieferung und Käufer-Abnahme als getrennte einmalige mandatierte Fälle ausgeführt. Die Abnahme gab atomar 5 wCOSMO Escrow frei. Beide Fälle schlossen EXECUTED und verifizierten ACCEPT 10/10. | Derselbe Operator hat beide Zeremonien gescharft. Die Rollentrennung war kryptographisch, nicht organisatorisch unabhängig. |
Öffentliches Material: die VLM-001-Beweisseite und ihr Evidence-Bundle; die EVM-MICRO-001-Transaktionen auf Ethereum, verlinkt von /mandates/; die Bundles für Case 001, Case 002 und Case 002-G; die narrative Übersicht unter /institutional/; der öffentliche Verifier unter /verifier/.
Scheitern gehört zum Beweis
Zwischen dem 22. und dem 28. August 2026 stoppten sich sechs gescharfte Versuche, VLM-001 zu schließen, selbst, bevor irgendetwas signiert war: eine überschrittene Gebührenobergrenze, RPC-Fehler, ein Read-Gate vor der Freigabe. Jeder hinterließ ein Journal, das mit einem benannten Fehlschlag endet, und keine Signatur. Die Verifier-Version, die vor den Live-Policy-Pins veröffentlicht wurde, lieferte gegen dieselben Fälle REJECT; diese REJECT-Dateien blieben im Bundle neben den ACCEPTs der Version, die die Pins trägt. Zwei gescheiterte Case-002-Versuche, einer vor jedem Netzkontakt und einer abgelaufen, weil der ARM zu spät kam, wurden ebenso behalten und nie umetikettiert.
Ein Mandatssystem, das sein Scheitern nicht benennen kann, ist nicht prüfbar.
8. Wahrheit, Beobachtung und Verifikation
Ein Verifier kann nur beweisen, was sein Evidence-Modell zulässt. COSMO verifiziert interne Konsistenz und Aufzeichnungsintegrität: dass Receipt, Journal, Evidence, Policy-Pins, Mandat und das beobachtete Settlement miteinander und mit den Signaturen darüber übereinstimmen. COSMO behauptet keine universelle Weltwahrheit.
- Eine Plattformbeobachtung kann intern konsistent und trotzdem falsch über die externe Realität sein.
- Ein On-Chain-Zustandsübergang ist ein stärkerer Anker als eine Balance-Beobachtung in einer Anwendung.
- Ein selbst attestiertes Receipt ist nicht dasselbe wie eine unabhängige Attestation durch Dritte.
- Ohne Referenzmarkt-Vergleichsdaten gibt es keinen Best-Execution-Anspruch, nur einen Anspruch auf begrenzte Ausführung.
Aktuelle Verifikationsgrenze
Der Standalone-Verifier ist öffentlich: eine einzelne, in sich geschlossene Datei unter heros.cloud/verifier/, derzeit Version 1.3.2, mit gepinntem Quell-Hash, sodass jeder die Datei prüfen kann, die er ausführt. Er führt eine separate Offline-Prüfung der internen Konsistenz gegen ein veröffentlichtes Trust-Profil durch. Er ist keine unabhängige Attestation durch Dritte. Die Engine, die die Evidence erzeugt, ist ein einzelner Attestor, kein Attestor-Netzwerk.
Diese Grenzen stehen neben den Ansprüchen, die sie einschränken, und sie werden nur durch Evidence verschoben: einen unabhängigen Operator, einen zweiten Attestor oder Referenzmarktdaten, die existieren.
9. Rollen, und was COSMO nicht ist
| Rolle | Wer |
|---|---|
| Kapitalgeber | Protokoll, Foundation, DAO, Treasury, Investor. Legt Märkte, Beträge, Grenzen, Laufzeit und Autorität fest. |
| Operator | Market Maker, Liquiditätsmanager, autonomer Agent. Führt innerhalb des Mandats aus. |
| COSMO | Die Mandats-, Kontroll-, Ausführungs- und Beweisschicht dazwischen. |
COSMO ist ausdrücklich nicht der Market Maker, keine Handelsstrategie, keine DEX, kein Verwahrer, nicht bloß ein Agenten-Wallet, kein Profitabilitätsversprechen und kein allgemeiner Trading-Bot. Es ist kein Foundation Model, kein Chatbot, kein Identitätsanbieter, kein Reputationsorakel und kein Regulator.
Was COSMO nicht behauptet
- keine garantierte Kapitalsicherheit;
- keine garantierte Profitabilität;
- kein regulatorischer oder rechtlicher Compliance-Status;
- keine Best Execution, solange keine Referenzmarkt-Vergleichsdaten existieren;
- kein vollständig autonomes Market Making;
- keine Unterstützung beliebiger Chains, Router oder Strategien;
- keine Produktionsreife, die allein aus begrenzten Piloten abgeleitet wäre;
- keine nachgewiesene externe Nachfrage.
Was COSMO tut, ist enger: Es macht Autorität, Regeln, Handlung, Evidence und aufgezeichnetes Ergebnis einer Liquiditätsoperation explizit, begrenzt und prüfbar für jemanden, der nicht im Raum war.
10. Über Liquidität hinaus
Der erste Pilot muss keine vollständige Market-Making-Strategie automatisieren. Ein einzelnes begrenztes Rebalancing oder eine begrenzte Liquiditätsaktion reicht, um den Mechanismus zu beweisen, und genau das ist bewiesen. Dieselbe Mandatsform deckt eine Familie von Operationen ab, die ein Kapitalgeber delegieren möchte:
- begrenztes Treasury-Rebalancing;
- Kapitaleinsatz in freigegebene Liquiditätspools;
- Rebalancing von Inventar über freigegebene Assets;
- Absicherung von Beständen innerhalb vorgegebener Grenzen;
- Auf- oder Abbau von Liquidität nach festen Regeln;
- später: Nachweis der Ausführungsqualität gegen externe Referenzmärkte.
Bisher demonstriert: ein begrenztes Liquiditätspool-Mandat, zwei begrenzte Swaps und mandatierte Marktplatzarbeit. Alles Weitere auf dieser Liste ist eine zu validierende Anwendung, kein gelieferter Fakt. Kontrollierte Treasury-Ausführung ist die zweite Geschichte; die Kategorie hinter beiden ist Ausführungs- und Absicherungsinfrastruktur für Agentenökonomien. Begriffe wie "institutionelle Schicht" oder "Execution Layer" bleiben gültige Kategorielabels. Sie sind nicht mehr der erste Satz.
Dieselbe Disziplin reicht bis zu den Venues. Eine Venue, deren Settlements als Evidence zählen sollen, kann pro Settlement eine kleine, signierte, falsifizierbare Erklärung ausstellen; COSMO hat dafür ein venue-neutrales Anforderungsdokument unter /vsa/ veröffentlicht. Es hebt Venue-Angaben von Dashboard-Daten auf attestiert und falsifizierbar, nie auf bewiesen.
11. Auf Supra gebaut, bewiesen dort, wo das Kapital lag
| Schicht | Rolle |
|---|---|
| Modelle / Skills | Worüber Agenten schlussfolgern und was sie ausführen können. |
| Identität / Web of Trust | Wer ein Akteur ist und wie Vertrauenspfade entstehen. |
| SupraOS | Koordination: wie Agenten organisiert, komponiert und mit Workflows verbunden werden. |
| SupraFX | Markt- und Liquiditätsschienen: Preis, Tiefe, Routing und Venues. |
| COSMO | Mandate, Policies, Zeremonie, Records, Receipts und Verifikation rund um autonome Handlung. |
| Supra | Ökonomisches Substrat: programmierbare Ausführung, State, Assets und Settlement-Anker. |
COSMO ist auf Supra gebaut und ergänzt SupraOS und SupraFX. Die gewinnende Geschichte ist Komposition, nicht Wettbewerb. Die Liquiditätspiloten liefen dort, wo das anvertraute Kapital lag, auf Ethereum Mainnet; die Marktplatz- und FX-Fälle liefen auf Supra. Zwei Chains mit echtem Kapital sind ein Fakt über zwei Piloten. Sie sind kein Anspruch auf Unterstützung beliebiger Chains, Router oder Strategien.
12. Der Controlled Liquidity Pilot
Das Angebot ist bewusst klein, weil ein kleines Angebot Ende zu Ende beweisbar ist.
- ein Kapitalgeber;
- ein Market Maker oder Agent;
- ein Handelspaar;
- eine freigegebene Venue;
- ein begrenztes Kapitalmandat;
- eine konkrete Liquiditäts- oder Rebalancing-Aktion;
- ein unabhängig prüfbarer Abschlussrecord.
Ein begrenztes Liquiditätsmandat mit echtem Kapital ausführen und das Ergebnis unabhängig verifizieren.
Der Pilot ist kuratiert: ein Engagement zur Zeit, gemeinsam mit dem Kapitalgeber abgesteckt, bevor ein Mandat signiert wird. Einstieg unter heros.cloud/mandates/.
13. $COSMO und Community
Die Mandatsthese beweist für sich genommen keine Token-Ökonomie. Jede Rolle für $COSMO muss aus echten Systembedürfnissen begründet sein, nicht aus nachträglicher Erzählung. Mögliche Rollen sind Zugang, Bonds, Operator-Exposure, Service-Settlement und Community-Koordination. Jede sollte an einer Frage gemessen werden: verbessert sie Verantwortlichkeit, oder fügt sie nur einen Token hinzu, wo keiner nötig ist?
Die Community, auf die es ankommt, ist kein Publikum um eine Behauptung. Sie ist das Netz aus Operatoren, Kapitalgebern, Verifier-Prüfern und Domänenbauern, das die Mandatsdisziplin betreiben, herausfordern und verbessern kann, und das die externe Nachfrage erzeugt, die der Mechanismus sich noch verdienen muss.
14. Prinzipien
- Kapitalgeber definieren das Mandat. Agenten führen innerhalb harter Grenzen aus. COSMO beweist jede Handlung.
- Der Besitz eines Keys ist kein Mandat.
- Capability is copyable. Authority is not.
- Jede unumkehrbare Handlung braucht ein begrenztes Mandat.
- Die Policy wird vor der Ausführung fixiert, nicht nach dem Ergebnis erfunden.
- Grenzen, die erst im Nachhinein geprüft werden, sind Forensik.
- Ein Bericht ist eine Darstellung. Ein Receipt ist nur dann ein Beweis, wenn jemand anderes es nachrechnen kann.
- Ein Mandat benennt sein eigenes Ende.
- Scheitern muss mit einem benannten, signierten Ergebnis abschließen.
- On-Chain-State ist stärker als Plattformbeobachtung, wo er verfügbar ist.
- Menschliche Autorisierung ist legitime Architektur, wenn das Trust-Modell sie verlangt.
- Domänenökonomien dürfen sich unterscheiden, solange die Integritätsgarantien gemeinsam bleiben.
- COSMO ergänzt SupraOS und SupraFX; es konkurriert nicht mit ihnen.
- Öffentliche Evidence zählt mehr als Pitch Decks.
- Ein demonstrierter Mechanismus ist nicht dasselbe wie demonstrierte Nachfrage.
15. Die Erklärung
Wir glauben, dass Kapital an Maschinen delegiert werden wird, und dass die Bedingungen dieser Delegation entscheiden, wem es anvertraut wird.
Wir glauben, dass ein Kapitalgeber nie zwischen einem Blankoscheck und Handarbeit wählen müssen sollte.
Wir glauben, dass ein Operator, der innerhalb harter Grenzen arbeitet und eine prüfbare Spur hinterlässt, mehr Kapital verdient als einer, der um Vertrauen bittet.
Wir glauben, dass eine Grenze, die sich hinterher nicht beweisen lässt, nie eine Grenze war, und dass ein Mandat, das nicht enden kann, nie fertig geschrieben wurde.
Wir glauben, dass der Beweis einer Handlung der Partei gehört, die ihr Risiko trägt, in einer Form, die diese Partei prüfen kann, ohne jemanden zu fragen.
Wir glauben, dass Supra ein Zuhause für diese Ökonomie werden kann, weil Ausführung, Automation, Daten, Märkte und Agenteninfrastruktur dort zusammenlaufen: SupraFX liefert Marktschienen, SupraOS liefert Koordination, und COSMO liefert die Mandats- und Beweisdisziplin rund um autonome Handlung.
Wir bauen keinen klügeren Trading-Bot. Wir bauen die Schicht, die beantwortet: wessen Kapital, unter welchem Mandat, innerhalb welcher Grenzen, was geschah, und wie lässt sich das Ergebnis prüfen?
Dafür gibt es COSMO.
16. Öffentliche Kurzfassung
COSMO ermöglicht Market Makern und Liquiditätsagenten, fremdes Kapital ohne blindes Vertrauen einzusetzen. Ein Kapitalgeber erteilt ein begrenztes Mandat über Venues, Assets, Beträge, Slippage, Gas, Aktionszahl und Laufzeit. Das Mandat wird per Hash versiegelt, die Policy vor der Ausführung gepinnt, ein Mensch scharft den unumkehrbaren Schritt, genau eine Transaktion wird gesendet, das Settlement wird gegen das Signierte geprüft, und ein signiertes Receipt schließt den Fall. Ein öffentlicher Standalone-Verifier prüft den gesamten Fall allein aus den Dateien nach. Der Mechanismus ist mit echtem Kapital auf Ethereum Mainnet bewiesen, einschließlich eines vollständigen Mandatslebenszyklus bis zur Beendigung, und über zwei ökonomische Domänen auf Supra. COSMO ist auf Supra gebaut und ergänzt SupraOS und SupraFX. Evidence und Verifier: heros.cloud/mandates/ und heros.cloud/verifier/.
Appendix: Creator- und Community-Zeilen
- Kapitalgeber definieren das Mandat. Agenten führen innerhalb harter Grenzen aus. COSMO beweist jede Handlung.
- Delegiere die Arbeit, nicht den Key.
- Eine Grenze, die du nur hinterher prüfen kannst, ist Forensik.
- Ein Bericht ist eine Darstellung. Ein Receipt ist ein Beweis.
- Ein Mandat benennt sein eigenes Ende.
- Fähigkeit kann skalieren. Autorität muss begrenzt bleiben.
- Agenten brauchen keinen Blankoscheck. Sie brauchen ein Mandat.
- COSMO macht aus "kann" ein belegbares "darf".
- Ein Verifikations-Einstiegspunkt. Gemeinsame Integrität. Domänen-spezifische Ökonomie.
- COSMO kompiliert Schutzmechanismen in Ausführung.
Risk and honesty note. This manifesto is a strategic and narrative document. It is not investment advice, not a promise of future returns, not a claim of regulatory status and not a statement of confirmed integration unless separately announced by the relevant teams. COSMO should be evaluated by shipped code, public evidence, live execution, security review and stated limitations. The mandate mechanism has been demonstrated on bounded pilots. External demand remains to be proven.
Version basis: public COSMO positioning and evidence state as of September 2026. Supersedes the v5.0 manifesto, which remains archived at /manifesto/v5/.