A release note is not deployment coverage
Publishing a repaired component does not update the customer-owned contracts that depend on it.
Dependency repair · testnet prototype
A published fix is only the start.Prove each deployment is repaired.
Orryn helps infrastructure suppliers and protocol teams coordinate known dependency repairs across customer-owned smart-contract deployments—with clear checks, owner-controlled changes, and evidence tied to the state that was observed.
release policy → deployment evidenceno customer key custody
Current prototype supports one documented oracle-adapter and proxy pattern; unsupported paths are reported as unsupported, not silently accepted.
Repair path · illustrative
NOT LIVE DATASupplierRepair release
ORYNNchecks
CustomerOwn deployment
Evidence resultPass · Fail · Unknown
Known repair conditionsEvidence-bound outcome
Made for the handoff between
Supplier security teamsCustomer protocol teamsAuthorized owners
The gap
One supplier release. Many customer-owned deployments. Who checked that they all changed?
A release announcement says a repair exists. It does not establish which customer deployments use it, whether their configuration is safe, or whether the agreed behavior still works.
A version string is not the whole story
A deployment can use the expected code and still have a wrong route, unsafe setting, or unmet behavior check.
The customer controls the repair
Suppliers can explain and prepare a change, but only the customer’s owner, multisig, or governance can authorize it.
Evidence and funding are disconnected
When a supplier funds remediation, it needs a clear way to tie each eligible deployment’s result to its grant rules.
Repair workflow
A repair process with evidence at each handoff.
Orryn coordinates and explains the work. The customer remains in control of its deployment and its keys.
01Supplier
Publish the repair policy
The supplier defines the affected deployment scope and the conditions an acceptable repair must meet.
02Read only
Inspect the customer’s deployment
Orryn reads the supported onchain dependency path and records the chain state it observed.
03Evidence
Explain what does not match
Each required check reports pass, fail, unknown, or unsupported, with its expected and observed evidence.
04Customer controlled
Customer authorizes its own repair
Orryn can prepare and simulate a proposed transaction. The customer’s authorized wallet decides whether to execute it.
05Arc · planned end-to-end
Recheck, then apply campaign rules
A fresh result can be tied to a funded Arc campaign. The contract—not a page badge—controls grant settlement.
Architecture
Observe on the customer’s chain. Settle the campaign on Arc.
The website and verifier run as regular web services. The deployment being inspected stays on its source chain; Arc is the destination for campaign USDC rules. Chainlink CRE is intended to coordinate evidence and chain facts, and is still an integration in progress.
Source chain
Customer deployment
Proxy, dependency route, configuration, and current block state.
Orryn verifier
Checks and evidence
Runs the named supported checks and records a scoped outcome.
Arc settlement
Campaign contract
Applies funded USDC eligibility and claim rules onchain.
Chainlink CRE: planned evidence/fact orchestration.End-to-end workflow not live yet
Evidence, with boundaries
Every result should answer: what was checked, and against what?
Observe before you conclude
Results are bound to a named deployment and observed chain snapshot. A missing or stale observation is not a pass.
Code and configuration both matter
The supported check looks at the dependency route, implementation, required configuration, and agreed behavior tests.
The owner stays in control
Orryn does not hold customer upgrade keys or silently change a customer’s contract.
Evidence has a boundary
A verifier’s signed report identifies who attested to the result; it is not a cryptographic proof that arbitrary code is secure.
Orryn is not a universal scanner or an automatic upgrader. The current prototype covers one documented oracle-adapter/proxy pattern; other patterns need explicit support or manual review.
Repair with accountability
Know which deployments are repaired—and what still needs attention.
Start with the repair policy, the customer-owned deployment, and the evidence needed to call the work done.