STRATO: lending, bridge and balance review

Audit question and scope

The audit asks whether STRATO's financial components keep claims and assets consistent, and which loss paths the reviewed state actually permits. It concerns the STRATO blockchain on upquark, not the hosting provider.

The 8–9 October 2026 archive covers lending, CDP, SaveUSDST, classic and yield vaults, pools, oracles, bridges and MetalForge/TokenFactory. This assessment brings those reports together. Official project sources provide context; data collected in the audit supports deployment-state claims.

Bind sources to the deployment

Before a source finding can be assessed economically, executable logic, registry routing and custody must be identified. Different components may hold these roles. Lending counter-review corrected the initially assumed custody attribution. The assessment therefore had to use the actual asset holder, not just the reviewed logic contract.

The following model compares four fields in two invented manifests. It reports a changed routing revision. That calls for renewed attribution, not an automatic security finding. Matching values would be only as reliable as their supporting evidence.

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)

What the evidence establishes

The reports use source code, time-anchored state queries, index reconciliation, local calculations and simulations. Source explains a rule; state data records configuration and balances at the time of review. Local simulation tests behavior under model assumptions.

Documented writes were rejected before contract execution. They show no successful state change. Non-persistent calls are not executed transactions either. The model below therefore separates integrity, method description and a write claim. A matching hash checks bytes, not the truth of an observation.

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: historical High

Historical lending counter-review retains the High rating. It connects the known finding to corrected custody attribution and the economic state at that time. Critical was not established.

Three claims must remain separate: a logic error, its reachability in the specific deployment and the economic prerequisites for loss. Evidence for one does not replace the others. Rejected writes in particular do not demonstrate successful fund removal.

Remediation verification needs unique claims, correctly bound collateral and an independently reconstructed balance sheet. A present rating requires fresh state evidence.

Bridge: Medium overall

The native bridge was rated Medium overall: High impact with Low likelihood. Local model testing supports a conditional loss effect, but establishes neither the necessary attacker control nor production execution. High impact is an assessment dimension here, not a High severity rating.

Defensive review separates observation, confirmation and completion into distinct states. The model permits only listed transitions and rejects completion without prior confirmation. It does not establish whether confirmation is trustworthy: consensus, operational state and actual finality are outside the example.

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: deposits, rewards and strategies

SaveUSDST review did not establish a publicly triggerable severe deposit loss in the examined state. The report separately addresses a narrower question about expected-reward availability. That concerns a different entitlement from deposited principal.

Vault review did not observe the shared-resource topology required by an examined amplification hypothesis. A necessary prerequisite was therefore absent. Custody concentration may still matter, but does not prove that loss path.

The arithmetic model adds cash and deployed assets in the same integer unit, then compares them with liabilities. It checks a total. Validity of claims, value of strategy assets and timely asset availability require separate checks.

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: age and actual use

The oracle report distinguishes stale entries from feeds economically mapped at the time of review. The stale entries did not establish a severe loss finding in the reviewed snapshot. An old timestamp alone does not tell whether an active financial component consumes that price.

The model accepts only positive prices with known, non-future and sufficiently recent timestamps. Missing information causes rejection. It checks freshness, not price accuracy, origin or actual application use.

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")

Other components and counterchecks

CDP and MetalForge/TokenFactory reports did not establish a severe publicly triggerable asset loss along their reviewed paths. Pool counter-review limited the economic significance of the examined edge behavior. These results did not establish Critical either.

Counterchecks are part of the audit: without required permissions, economic use or topology, the specific hypothesis remains unconfirmed. This does not settle unreviewed paths or later changes. Results apply to documented scope, not as whole-system approval.

Verify remediation

Remediation verification should start with evidenced attribution: rebind the current implementation, routing and asset holder. Then independently reconstruct claims against balances. Bridge transitions need documented confirmation prerequisites; freshness must be checked where price affects an economic decision.

The examples explain these rules but do not replace tests of the actual implementation. A production regression test must detect a broken invariant and cover the relevant configuration. This assessment did not check whether STRATO has made such changes.

Conclusion

The lending finding remains High in the historical archive. The bridge remains Medium overall; Critical was not established. Corrected custody attribution was particularly important: without it, economic assessment would have relied on the wrong component.

The next step is to bind the historical finding to the current deployment and test any remediation against the same security rules.

Review limits

• Statements refer to the 8–9 October 2026 archive.
• Present remediation, later configurations and external disclosure were not checked.
• Code examples explain checks; they validate neither STRATO code nor production behavior.

References

The links provide project context. The judgment rests on the evidence described in the audit. Review models and actual tool excerpts are labelled separately.