STRATO: Lending, Bridge und Bilanzprüfung

Prüffrage und Umfang

Die Prüfung fragt, ob die Finanzkomponenten von STRATO Ansprüche und Vermögen konsistent behandeln und welche Verlustpfade der untersuchte Zustand tatsächlich zulässt. Gemeint ist die STRATO-Blockchain auf upquark, nicht der Hostinganbieter.

Der Bestand vom 8.–9. Oktober 2026 umfasst Lending, CDP, SaveUSDST, klassische und Yield-Vaults, Pools, Oracles, Bridge sowie MetalForge/TokenFactory. Diese Auswertung führt die damaligen Berichte zusammen. Die offiziellen Projektquellen dienen zur Einordnung; den Deployment-Zustand belegen die im Audit erhobenen Daten.

Quellen dem Deployment zuordnen

Bevor ein Quelltextbefund wirtschaftlich bewertet wird, müssen ausführende Logik, Registry-Zuordnung und Verwahrort feststehen. Diese Rollen können bei unterschiedlichen Komponenten liegen. Im Lending-Gegencheck wurde die zunächst angenommene Vermögenszuordnung korrigiert. Die Bewertung musste sich daher auf den richtigen Halter beziehen, nicht nur auf den geprüften Logikvertrag.

Das folgende Modell vergleicht vier Merkmale zweier erfundener Manifeste. Es meldet eine geänderte Routingrevision. Das ist ein Anlass zur erneuten Zuordnung, noch kein Sicherheitsbefund. Übereinstimmende Werte wären ebenfalls nur so zuverlässig wie die zugrunde liegenden Belege.

1expected = {"network": "demo", "implementation": "rev-A", "routing": "map-A", "custody": "pool-A"}
2observed = {**expected, "routing": "map-B"}
3required = ("network", "implementation", "routing", "custody")
4def compare(left, right):
5    missing = [key for key in required if key not in left or key not in right]
6    changed = [key for key in required if key in left and key in right and left[key] != right[key]]
7    return {"matches": not missing and not changed, "missing": missing, "changed": changed}
8result = compare(expected, observed)
9assert result["changed"] == ["routing"]
10print(result)

Was die Belege zeigen

Die Berichte verwenden Quelltext, zeitlich verankerte Zustandsabfragen, Indexabgleich, lokale Rechnungen und Simulationen. Quelltext erklärt eine Regel; Zustandsdaten zeigen, welche Konfiguration und Bestände zur Prüfzeit vorlagen. Eine lokale Simulation prüft Verhalten unter ihren Modellannahmen.

Die dokumentierten Schreibversuche wurden vor der Contract-Ausführung abgewiesen. Sie zeigen keine erfolgreiche Zustandsänderung. Nicht persistierende Aufrufe sind ebenfalls keine ausgeführten Transaktionen. Das Modell darunter hält deshalb Integrität, Methodenbeschreibung und Schreibbehauptung getrennt. Ein passender Hash prüft Bytes, nicht die Wahrheit einer Beobachtung.

1from hashlib import sha256
2payload = b"invented local state observation"
3record = {"digest": sha256(payload).hexdigest(), "anchor": "snapshot-A",
4          "method": "local-model", "persistent": False}
5allowed = {"source-review", "state-read", "local-model", "executed-write"}
6def inspect(data, evidence):
7    intact = sha256(data).hexdigest() == evidence["digest"]
8    described = bool(evidence["anchor"]) and evidence["method"] in allowed
9    write_claim = evidence["method"] == "executed-write" and evidence["persistent"] is True
10    return {"intact": intact, "described": described, "write_claim": write_claim}
11assert inspect(payload, record)["write_claim"] is False
12assert inspect(payload + b"changed", record)["intact"] is False
13print(inspect(payload, record))

Lending: historisch High

Für Lending hält die historische Gegenprüfung die High-Einstufung aufrecht. Sie verbindet den bekannten Befund mit der korrigierten Vermögenszuordnung und dem damaligen wirtschaftlichen Zustand. Critical wurde nicht belegt.

Dabei sind drei Aussagen auseinanderzuhalten: Ein Fehler in der Logik, seine Erreichbarkeit im konkreten Deployment und die wirtschaftlichen Voraussetzungen eines Verlusts. Der Nachweis einer dieser Aussagen ersetzt die anderen nicht. Die abgewiesenen Schreibversuche liefern insbesondere keinen Beleg für eine erfolgreiche Entnahme.

Für die Abhilfeprüfung kommt es auf eindeutige Ansprüche, korrekt gebundene Sicherheiten und eine unabhängig rekonstruierte Bilanz an. Eine heutige Einstufung erfordert neue Zustandsbelege.

Bridge: insgesamt Medium

Die native Bridge wurde insgesamt als Medium bewertet: High Impact bei Low Likelihood. Die lokale Modellprüfung stützt eine bedingte Schadenswirkung, belegt aber weder die nötige Kontrolle durch einen Angreifer noch eine Ausführung im Produktionsdienst. High Impact ist hier eine Bewertungsdimension, kein High-Schweregrad.

Für die defensive Prüfung sind Beobachtung, Bestätigung und Abschluss getrennte Zustände. Das Modell erlaubt nur ausdrücklich aufgeführte Übergänge und verweigert einen Abschluss ohne vorherige Bestätigung. Ob diese Bestätigung belastbar ist, beantwortet es nicht: Konsens, Betriebszustand und tatsächliche Finalität liegen außerhalb des Beispiels.

1def advance(state, event, verified=False):
2    if state == "new" and event == "observe":
3        return "observed"
4    if state == "observed" and event == "confirm" and verified is True:
5        return "confirmed"
6    if state == "confirmed" and event == "complete":
7        return "completed"
8    raise ValueError("transition rejected")
9assert advance("observed", "confirm", verified=True) == "confirmed"
10try:
11    advance("observed", "complete")
12except ValueError:
13    print("unconfirmed completion rejected")
14else:
15    raise AssertionError("invalid transition accepted")

Accounting: Einlagen, Erträge und Strategien

Bei SaveUSDST wurde im geprüften Zustand kein frei auslösbarer schwerer Einlagenverlust festgestellt. Der Bericht behandelt daneben eine engere Frage zur Verfügbarkeit erwarteter Erträge. Diese betrifft einen anderen Anspruch als das eingezahlte Kapital.

Die Vault-Prüfung fand die für eine untersuchte Verstärkungshypothese vorausgesetzte gemeinsame Ressourcentopologie nicht vor. Damit fehlte eine notwendige Voraussetzung. Verwahrungskonzentration kann trotzdem relevant sein, belegt aber nicht diesen Verlustpfad.

Das Rechenmodell addiert Liquidität und eingesetztes Vermögen in derselben ganzzahligen Einheit und vergleicht sie mit Verbindlichkeiten. Es prüft eine Summenbeziehung. Ob Forderungen rechtmäßig, Strategiebestände werthaltig oder Vermögen rechtzeitig verfügbar sind, muss separat geprüft werden.

1def reconcile(cash, deployed, liabilities):
2    values = [cash, *deployed, liabilities]
3    if any(type(value) is not int or value < 0 for value in values):
4        raise ValueError("non-negative integer units required")
5    assets = cash + sum(deployed)
6    return {"assets": assets, "liabilities": liabilities,
7            "surplus": assets - liabilities, "covered": assets >= liabilities}
8assert reconcile(60, [25, 15], 100)["surplus"] == 0
9assert reconcile(60, [25, 15], 101)["covered"] is False
10print(reconcile(60, [25, 15], 100))

Oracles: Alter und tatsächliche Nutzung

Der Oracle-Bericht unterscheidet veraltete Einträge von den zur Prüfzeit wirtschaftlich eingebundenen Feeds. Die veralteten Einträge begründeten im geprüften Snapshot keinen schweren Verlustbefund. Ein alter Zeitstempel allein sagt noch nicht, ob eine aktive Finanzkomponente diesen Preis verwendet.

Das Modell akzeptiert nur positive Preise mit bekannten, nicht zukünftigen und ausreichend jungen Zeitstempeln. Fehlende Angaben führen zur Ablehnung. Damit prüft es Frische, nicht Preisrichtigkeit, Herkunft oder die tatsächliche Nutzung durch eine Anwendung.

1def valid_price(price, updated, now, max_age):
2    values = (price, updated, now, max_age)
3    if any(type(value) is not int for value in values):
4        return False
5    if price <= 0 or updated < 0 or now < 0 or max_age < 0:
6        return False
7    age = now - updated
8    return 0 <= age <= max_age
9assert valid_price(100, 990, 1000, 30)
10assert not valid_price(100, 900, 1000, 30)
11assert not valid_price(100, 1001, 1000, 30)
12assert not valid_price(100, None, 1000, 30)
13print("fresh accepted; stale, future and missing rejected")

Weitere Komponenten und Gegenprüfungen

Die CDP- und MetalForge/TokenFactory-Berichte etablierten in ihren geprüften Pfaden keinen schweren frei auslösbaren Vermögensverlust. Die Pool-Gegenprüfung begrenzte die wirtschaftliche Bedeutung des untersuchten Randverhaltens. Auch aus diesen Ergebnissen ergab sich kein Critical.

Die Gegenprüfungen sind Teil des Audits: Fehlt die erforderliche Berechtigung, wirtschaftliche Nutzung oder Topologie, ist die konkrete Hypothese nicht bestätigt. Das sagt nichts Abschließendes über ungeprüfte Pfade oder spätere Änderungen. Die Ergebnisse gelten für den dokumentierten Umfang, nicht als Freigabe des Gesamtsystems.

Abhilfen prüfen

Die Abhilfeprüfung sollte bei den nachgewiesenen Zuordnungen beginnen: aktuelle Implementierung, Routing und Vermögenshalter erneut binden. Danach sind Ansprüche gegen Bestände unabhängig zu rekonstruieren. Bridge-Übergänge brauchen dokumentierte Bestätigungsvoraussetzungen; Preisfrische muss dort geprüft werden, wo der Preis eine wirtschaftliche Entscheidung beeinflusst.

Die Beispiele erläutern diese Regeln, ersetzen aber keine Tests der tatsächlichen Implementierung. Ein produktiver Regressionstest muss eine verletzte Invariante erkennen und die relevante Konfiguration abdecken. Ob STRATO solche Änderungen vorgenommen hat, wurde in dieser Auswertung nicht geprüft.

Fazit

Der Lending-Befund bleibt im historischen Bestand High. Die Bridge bleibt insgesamt Medium; ein Critical wurde nicht belegt. Besonders wichtig war die korrigierte Vermögenszuordnung: Ohne sie hätte die wirtschaftliche Bewertung auf der falschen Instanz beruht.

Als nächster Schritt ist der damalige Befund an das aktuelle Deployment zu binden und eine etwaige Abhilfe gegen dieselben Sicherheitsregeln zu prüfen.

Grenzen der Prüfung

• Die Aussagen beziehen sich auf den Bestand vom 8.–9. Oktober 2026.
• Aktueller Fix-Status, spätere Konfigurationen und externe Offenlegung wurden nicht geprüft.
• Die Codebeispiele erklären Prüfregeln; sie validieren weder STRATO-Code noch Produktionsverhalten.

Quellen

Die Links liefern Projektkontext. Für das Urteil zählt der im Audit beschriebene Prüfbestand. Prüfmodelle und echte Werkzeugauszüge sind getrennt gekennzeichnet.