Die überprüfbare Vorhandels-Autorisierungsschicht für autonomes Kapital
Sie haben bereits einen Trading-Agenten? Ergänzen Sie Profit Engine Governor. Verwahrung behalten. Kontrolle behalten.
PE Governor prüft jede eingereichte Orderabsicht gegen Ihre Regeln, koordiniert die Portfoliokapazität über Agenten hinweg und gibt eine kurzlebige signierte Autorisierung über den exakt erlaubten Betrag zurück. Ihr Executor verifiziert sie; PE Governor übernimmt nie die Verwahrung und platziert nie die Order.
Neues Kapital autorisieren, begrenzt auf den exakt erlaubten Betrag.
Verdict 02REDUCE
Eine bestehende verwaltete Position verkleinern. Den zurückgegebenen Betrag nie überschreiten.
Verdict 03REJECT
Eine harte Regel ist verletzt. Diesen Kandidaten nicht erneut ausführen.
Verdict 04HOLD
Temporäre Blockade oder in diesem Zyklus nicht ausgewählt. Abwarten und erneut anfragen.
01Eine deterministische Entscheidung, live gerendert
Eine deterministische Entscheidung, live gerendert
Diese Karte stammt aus derselben reinen Policy, die der bezahlte Endpunkt ausführt, auf Basis der Beispielanfrage unten. Gleiche Eingabe ergibt immer denselben Entscheidungs-Hash.
Ihre Agenten senden bis zu 50 Kandidaten auf einen gemeinsamen Bus: Lane, Asset, Richtung, angefragtes Nominal, vom Aufrufer geliefertem Maximalverlust und erwarteter Nettokante, Evidenzstatus und Ablauf.
Phase 02
2. Steuern
PE Governor wendet eine einzige reine Policy an: Aktualität des Zustands, Abstimmung, Not-Aus, Evidenz, Verlustbudgets, Reserve, Nominalgrenzen und Parallelität — dann Ranking und höchstens ein Gewinner.
Phase 03
3. Befolgen
Kapital bewegt sich zu Ihren Bedingungen. Gleiche Anfrage rein, bytegleiche Entscheidung raus, mit SHA-256-Hashes der kanonischen Anfrage und Entscheidung für die Prüfung.
02Grundlegende Kontrolle für autonomes Kapital
Grundlegende Kontrolle für autonomes Kapital
Eine deterministische Autorisierungsschicht, die Agentenentscheidungen begrenzt, prüfbar und über Ihren gesamten Ausführungs-Stack hinweg portabel macht.
Manipulationssichere Policy-Belege
Jede Antwort verbindet kanonische Anfrage und Entscheidung mit SHA-256-Hashes, Policy-Version, Zeitstempel, exakt erlaubtem Betrag und Prüfungen von Istwert gegen Limit. Wiederholungen bleiben bytegleich.
Portfolioweite Governance
Bewerten Sie bis zu 50 Kandidaten aus mehreren Strategien gegen einen aktuellen, abgestimmten Portfolio-Snapshot. Regeln zu Verlust, Drawdown, Reserve, Nominale, Parallelität und Not-Aus greifen, bevor höchstens ein Gewinner ausgewählt wird.
Maschinennative Bezahlung
Zahlen Sie den veröffentlichten, risikogestaffelten Preis pro Entscheidung in USDC auf Base über den Coinbase Business Checkout oder nutzen Sie Prepaid-Guthaben. Idempotenz verhindert doppelte logische Käufe.
Die Durchsetzung beginnt in Ihrem Ausführungsadapter
PE Governor liefert die Autorisierung; Ihr Adapter prüft sie und hält sich daran, bevor eine Order platziert wird. Coinbase setzt PE-Entscheidungen derzeit nicht am Handelsplatz durch, und die Zahlung ändert das Urteil nie.
03Signierte Autorisierungen, die Ihr Executor prüfen kann
Signierte Autorisierungen, die Ihr Executor prüfen kann
Jede gesteuerte Allokation trägt eine kurzlebige, kryptografisch signierte Autorisierung, die an ihre exakte Absicht und den zuletzt übermittelten Risikozustand des Portfolios gebunden ist.
Überprüfbare Policy-Nachweise
Die Signatur deckt die kanonische Nachweis-Nutzlast ab: Aussteller, Schlüssel-ID, Verdikt, exakt erlaubter Betrag, Kandidat, Strategie, Lane, vollständiger Geltungsbereich, Request-Hash, Entscheidungs-Hash, Portfolio-Zustands-Hash, das dauerhafte Preisangebot und der Ablauf. Den öffentlichen Schlüssel einmal laden und offline prüfen.
Atomare Reservierungen über Agenten hinweg
Gleichzeitige Agenten in Mandant und Portfolio konkurrieren um ein einziges aggregiertes Risikobuch. Ein Gewinnerkandidat wird nur ausführbar, wenn die Reservierung gewährt wird; sonst wird das Verdikt zu HOLD herabgestuft.
Risikogestaffelte Preise
Der Preis einer Entscheidung skaliert mit dem Risikokapital — dem größten angefragten Nominal oder Maximalverlust der Anfrage. Das Angebot ist deterministisch und hash-gebunden. Zahlung kauft die Prüfung, nie ein Verdikt.
Deterministischer Preis pro Entscheidung
Risikokapital ist max(requestedNotionalUsd, maximumLossUsd) über alle eingereichten Kandidaten. Eine Krediteinheit entspricht 0,05 USDC.
Deterministischer Preis pro Entscheidung
Risikokapital
Preis (USDC auf Base)
Krediteinheiten
bis 1.000 $
0.05 USDC
1
bis 10.000 $
0.10 USDC
2
bis 100.000 $
1.00 USDC
20
bis 500.000 $
5.00 USDC
100
über 500.000 $
10.00 USDC
200
Derselbe Preis gilt für ALLOCATE, REDUCE, REJECT und HOLD. Es gibt kein Abonnement.
Vor der Ausführung prüfen
Ihr Ausführungsadapter muss Nutzlast-Hash, Signatur, Aussteller und Schlüssel-ID, Gültigkeitsfenster, aktives Reservierungs-Token, alle erwarteten Hashes sowie die exakte Übereinstimmung von Order, autorisierter Absicht und Betrag prüfen. Verbrauchen Sie jede Autorisierung genau einmal in einem dauerhaften Speicher und weisen Sie jede Order ohne gültige Autorisierung ab.
verify-authorization.ts
import { verifyAuthorizationForOrder } from "./pe-authorization";
// 1. Fetch and cache the published Ed25519 verification key (kid + issuer).
const { issuer, keys } = await (await fetch("/api/pe/v1/keys")).json();
// 2. Gate every order on a live, exactly matching authorization.
const check = await verifyAuthorizationForOrder({
proof: decision.proof, // returned with every 200
publicKeyBase64Url: keys[0].x,
order: {
candidateId, strategyId, assetId, lane, side, reduceOnly,
amountUsd: decision.allocationAmountUsd, // must equal permittedAmountUsd exactly
tenantId, portfolioId, agentId, ownerId, accountScope,
},
expected: {
issuer,
keyId: keys[0].kid,
policyVersion: decision.policyVersion,
requestHash: decision.audit.requestHash,
decisionHash: decision.audit.decisionHash,
portfolioStateHash: decision.proof.payload.portfolioStateHash,
quoteHash: decision.priceQuote.quoteHash,
reservationFencingToken: decision.proof.payload.reservation.fencingToken,
},
// Durable single-use store: ONE atomic operation, never has() then add().
replayStore: {
consumeIfUnused: async (id) => {
const { rowCount } = await db.query(
"INSERT INTO used_authorizations (id) VALUES ($1) ON CONFLICT DO NOTHING",
[id],
);
return rowCount === 1; // false => already consumed
},
},
});
if (!check.valid) throw new Error(check.reason); // never place the order
placeOrder(decision.allocationAmountUsd);
Portfoliokapazität über das gesamte Ausführungsfenster halten
Optional
Eine signierte Autorisierung offline zu prüfen genügt weiterhin für sich allein. Wer mehr will, beansprucht sie: PE Governor hält dann den Anteil dieser Autorisierung an der Gesamtkapazität, bis Ihr Adapter das Ergebnis meldet — so kann ein zweiter Agent denselben Spielraum nicht doppelt verbrauchen.
AUTHORIZED
Mit der Entscheidung ausgestellt und hält bereits Kapazität für ihr kurzes Gültigkeitsfenster.
CLAIMED
Ihr Adapter hat einen geheimen Claim-Key gebunden und verantwortet nun das Ergebnis. Kein anderer Aufrufer kann den Zustand ändern.
COMMITTED
Der Adapter hat gehandelt. Die Kapazität bleibt gehalten, denn gebundenes Kapital arbeitet bis zur Abstimmung.
RELEASED
Der Adapter hat ohne Handlung abgebrochen. Die Kapazität wird sofort zurückgegeben.
EXPIRED
Niemand hat rechtzeitig zurückgemeldet. Die Kapazität wird von selbst zurückgegeben, ganz ohne Aufräumaufruf.
authorization-lifecycle.ts
// Optional. Offline verification of the proof is still sufficient.
const { authorizationId } = decision.lifecycle;
const claimKey = crypto.randomUUID() + crypto.randomUUID(); // >= 32 chars, keep it
const claim = await fetch(`/api/pe/v1/authorizations/${authorizationId}/claim`, {
method: "POST",
headers: { "x-pe-claim-key": claimKey },
});
if (!claim.ok) return; // someone else owns this authorization
try {
await placeOrderWithYourOwnExecutor(intent); // PE Governor never does this
await fetch(`/api/pe/v1/authorizations/${authorizationId}/commit`, {
method: "POST",
headers: { "x-pe-claim-key": claimKey },
});
} catch {
// stand down and give the capacity straight back
await fetch(`/api/pe/v1/authorizations/${authorizationId}/release`, {
method: "POST",
headers: { "x-pe-claim-key": claimKey },
});
}
Der Lebenszyklus-Zustand ist die Buchführung Ihrer eigenen Richtlinie. Ein Commit hält fest, dass Ihr Adapter gehandelt hat; PE Governor platziert, leitet und settelt nach wie vor keine Order.
05Die Policy einmal installieren
Die Policy einmal installieren
Rufen Sie den Endpunkt vor jeder Allokation ab dem Eigentümer-Schwellenwert auf. Bei REJECT oder HOLD stoppen und einen REDUCE-Betrag nie überschreiten.
install-policy.txt
# Install once, obey always.
BEFORE any allocation >= OWNER_THRESHOLD_USD:
decision = POST /api/pe/v1/governor # same-origin; production clients resolve it against https://governor.solarly.ai
if decision.decision in ("REJECT", "HOLD"):
stop() # no order, no retry loop
if decision.decision == "REDUCE":
size = min(intended_size, decision.allocationAmountUsd)
if decision.decision == "ALLOCATE":
size = decision.allocationAmountUsd # never more
execute(size) # execution is 100% yours
Zahlen Sie pro Entscheidung in USDC auf Base über einen Coinbase-Business-Checkout oder nutzen Sie vorausbezahlte Credits. Kein Abo. Autorisierung ist keine Abwicklung: erst ein COMPLETED-Checkout gibt die Entscheidung frei.
Step 01
POST + Idempotenzschlüssel
Eine logische Anfrage wird atomar reserviert.
Step 02
402 mit x402-URL
Genau ein Coinbase-Checkout wird erzeugt.
Step 03
202 während der Verarbeitung
Mit gleichem Schlüssel und Checkout-Id erneut versuchen.
Step 04
COMPLETED
Polling bestätigt einen COMPLETED-Checkout. Die Bestätigung per signiertem Webhook ist verfügbar, sobald sie konfiguriert ist.
Step 05
200 Entscheidung
Einmal gespeichert; Wiederholungen sind bytegleich.
Die Statuscode-Zustandsmaschine
POST /api/pe/v1/governor (X-Idempotency-Key: uuid-v4)
|
v
402 Payment Required --payment.x402Url--> client pays the checkout
| |
|<---- retry: same key + X-Checkout-Id ------+
v
202 Accepted checkout ACTIVE / PROCESSING --> back off, retry
|
v
checkout COMPLETED (polling; signed webhook when configured)
|
v
200 OK pe-governor-decision.v1, stored once, replays byte-identical
Wiederholungsschleife im Client
Eine minimale Integration. Sende einen UUID-v4-Idempotenzschlüssel, lies x402-URL und Checkout-ID aus dem 402-Body, bezahle sie und frage dann mit demselben Schlüssel und derselben Checkout-ID ab, bis die Entscheidung freigegeben wird.
retry-loop.ts
import { randomUUID } from "node:crypto";
const ENDPOINT = "/api/pe/v1/governor"; // same-origin; resolves against https://governor.solarly.ai
const idempotencyKey = randomUUID(); // UUID v4, one per logical decision
// 1. First call: body + idempotency key. No payment yet, so expect 402.
let res = await fetch(ENDPOINT, {
method: "POST",
headers: { "content-type": "application/json", "x-idempotency-key": idempotencyKey },
body: JSON.stringify(governorRequest),
});
if (res.status !== 402) throw new Error(`unexpected status ${res.status}`);
// 2. Read the x402 URL and checkout id straight off the 402 body.
const { payment } = await res.json();
const x402Url: string = payment.x402Url; // where the client pays
const checkoutId: string = payment.checkoutId; // echo this back on every retry
// 3. Pay with your x402 client. The authorization response is NOT settlement:
// only a COMPLETED checkout releases the decision.
await x402Client.pay(x402Url, { amount: payment.amount, asset: payment.currency });
// 4. Poll the same request with the same key + checkout id, backing off.
for (let attempt = 0; attempt < 12; attempt++) {
res = await fetch(ENDPOINT, {
method: "POST",
headers: { "x-idempotency-key": idempotencyKey, "x-checkout-id": checkoutId },
}); // body may be omitted on retries
if (res.status === 200) {
const decision = await res.json(); // pe-governor-decision.v1
console.log(decision.decision, decision.allocationAmountUsd, decision.audit.decisionHash);
break;
}
if (res.status !== 202) throw new Error(await res.text()); // 402/409 are terminal
await new Promise((r) => setTimeout(r, Math.min(500 * 2 ** attempt, 8000)));
}
01. Keine Handelsausführung und keine Orderplatzierung
02. Keine Verwahrung, keine Wallets, keine privaten Schlüssel
03. Kein Brokerage und keine Geldübermittlung
04. Kein LLM im Entscheidungspfad
05. Keine eigene Renditeprognose und kein Anspruch auf proprietäres Alpha
06. Erwartete Kante und Maximalverlust sind stets Eingaben des Aufrufers
07. Keine handelsplatzseitige Durchsetzung wird behauptet; Ihr Adapter setzt jede Autorisierung durch
08. Eine signierte Autorisierung belegt, welche Policy-Entscheidung ausgestellt wurde. Sie ist kein Compliance-Zertifikat, keine Underwriting-Entscheidung, keine On-Chain-Attestierung und keine Handelsplatz-Freigabe.