Updated 3 min read
ORION: Trust the Identity, Not the Location
A hostname is a weak place to put trust. ORION checks an Ed25519 signature on the record itself, so a client can accept data without treating the server address as proof.
By Luis Mendoza Software architect
The problem with location-based trust
Most systems still assume that the right address implies the right answer. If a request lands on the expected IP or hostname, the client treats the payload as authentic. That shortcut is convenient, and it is also the failure mode.
It breaks in ordinary operations, not only in attacks. A DNS hijack, a poisoned route, a censored path, or a failover into another region can all deliver bytes the publisher did not intend. The client has arrived. It has not learned who published the record.
ORION separates those two questions. Reaching a node is transport. Accepting the record is identity. The client validates a cryptographic record, not the coordinates of the machine that served it.
What ORION is
ORION — Open Resilient Identity Overlay Network — is a decentralized identity overlay built by Scraplay. Publishers sign records with Ed25519. Peers replicate those records and resolve them with a distributed lookup, so the record stays available when any single host does not.
The scope is narrow on purpose. ORION does not replace your database, your API, or TLS. It answers a question those layers leave open once a record can live in more than one place: is this the record the publisher signed, no matter which node handed it over?
How it works in practice
A publisher signs an identity record with its own key. Peers index that record and answer lookups across the overlay. A consumer checks the signature locally. Lookup does not need a central directory, and verification does not require trusting the peer that returned the bytes.
If one node goes offline, others can still serve the same signed record. Replacing a server, moving a region, or losing a machine does not create a new trust decision. Location stays an operational detail. The signature stays the anchor.
Consider a client that resolved a hostname and then had to follow that name into another region. TLS can still present a valid certificate for the name. It does not, by itself, prove that a replicated identity record is the one the publisher signed. That is the check ORION adds: the signature on the record, independent of the address that served it.
Where it helps B2B systems
The useful cases are the ones where infrastructure moves and the identity should not. An API that has to survive a host change. A service federated across regions. Any client that needs to know who published a record, not only which address answered.
ORION sits beside TLS and PKI. Those still protect the connection and name the servers you operate. ORION adds an identity on the record that remains valid when the topology changes. It does not retire certificates, and it does not ask you to trust a node instead of a signature.
What's next
ORION is infrastructure Scraplay is building and operating, not a paper architecture. If you are designing systems that must verify a publisher after the hostname moves, start with the project. If you want to see whether that layer belongs in a system you already run, we can look at the architecture with you.