What Escrow and Address Checks Actually Cover

An earlier version of this post claimed that a combination of escrow, address validation and identity checks ruled out an entire class of attacks by construction. That was wrong, and it was wrong in a way worth correcting in public rather than quietly deleting.

No control rules out an attack. A control narrows one class of loss and leaves the rest of the surface where it was. The useful question for anyone deciding what to build on is not which controls a network has, but what each one covers, what it does not cover, and which of them are finished.

Security is not one property

Loss in a multi-chain system does not arrive through one door. At least four distinct failure modes are usually collapsed into a single word:

• One party takes delivery and does not pay.
• Value is signed over to the wrong destination.
• The counterparty is not the entity you believed you were dealing with.
• One chain accepts a false statement about another chain's state.

These have different causes and different controls. A design that answers one and is described as though it answers all four is worse than a design that answers none, because the reader stops looking.

The principle

Write down each control as three lines: what it does, what class of loss it narrows, what it does not cover. If the third line is empty, the control has not been understood yet.

Control 1 - escrow-held settlement

What it does. Both sides commit assets to a contract that releases them only when the conditions written into that contract are met. Neither party holds the other's assets during the exchange.

What it narrows. Sequencing risk in a bilateral exchange: the case where one side performs first and the other walks away. Escrow removes the advantage of going second.

What it does not cover. Escrow is a program, and it inherits every risk a program has. It cannot observe anything outside the chain, so an obligation delivered off-chain - a file, a rendered result, a physical good - has to be reported by something, and that reporting step becomes the weak link rather than the payment. It says nothing about whether the goods matched their description. It does not help if the counterparty wanted your credentials rather than your funds. On UniNet, parts of smart-contract execution are incomplete, so escrow here is a design to read and test, not a production settlement path.

Control 2 - address validation

What it does. A transfer is refused before signing if the destination is not well-formed, or does not resolve to something the network recognises. Human-readable recipient names bind a name to a key so an operator is not comparing hex by eye.

What it narrows. Loss to a destination nobody controls: truncated strings, transposed characters, a paste that captured the wrong buffer. This is a real and boring category of loss, and validation addresses it well.

What it does not cover. Validation answers whether a destination exists. It does not answer whether it is the destination you meant. A well-formed address belonging to an attacker passes every check a validator can run. So does a look-alike name registered by somebody else, a recipient whose key has been taken, and an address substituted upstream in whatever process produced the payment request. The residual risk moves to the step that chose the address - usually a person under time pressure, or an agent following instructions it did not author. That step is where the remaining work is.

Control 3 - identity binding

What it does. An actor is bound to a key pair, and the network keeps separate identity types for people, for agents and for node operators. A counterparty presents a signature rather than an assertion.

What it narrows. Impersonation inside the network. If the key binding holds, a party that has transacted before can be recognised as the same party again, and history can be attributed to an identity rather than to a session.

What it does not cover. A key binding establishes continuity, not legitimacy. It tells you this is the same entity as last time. It does not tell you the entity is a registered company, or that it is solvent, or that it is who it claims to be off the network. Identity verification backends are not connected today, so a supervisor relationship on UniNet is a cryptographic link between keys rather than an attested legal identity. Any flow that depends on knowing the legal person behind a key has to source that assurance elsewhere for now.

Control 4 - cross-chain message verification

What it does. Before one chain acts on a statement about another chain's state, it verifies a proof of that statement.

What it narrows. This is where a cross-chain system concentrates its risk. A chain that accepts an unverified claim that a deposit occurred elsewhere will issue value against an event that never happened. Verification is the control that decides whether a bridge is a security boundary or a hole with a queue in front of it.

What it does not cover, and what is unfinished. Parts of bridge verification on UniNet are incomplete. This is the control on this page least suited to production dependence, and it is the reason the original version of this post was indefensible: it made an absolute claim across a set of controls that included an unfinished one.

What is actually in place

The architecture defines node operator identity with reliability recorded at network level, delegated authority that can be scoped and revoked with the revocation cascading to everything derived from it, container-level workload isolation with resource limits, and signed transfers with sub-wallets and human-readable recipients. Those are described in the architecture, and each appears on build status with its current grade. Several are marked Ungraded, meaning the capability is asserted in the design documents but production readiness has not been signed off by engineering. Read the grade before designing against the capability.

Limitation

Parts of bridge verification are incomplete; do not design a production cross-chain settlement path around it yet. Parts of smart-contract execution are incomplete. Identity verification backends are not connected. Hardware security modules are not implemented, so key custody is software custody. None of the properties described here have been through an independent security audit, which makes them design intent you should read and test rather than a compliance control you can cite. The current state of every subsystem, and the date it was last reviewed against the codebase, is on build status.

What this supports today

Bilateral flows that settle on one chain, with authority scoped in advance and revocable afterwards, are the part of this surface that is coherent now. That is enough to model an agent with a spending cap, a service that refuses a request whose authority has expired, and a counterparty whose history is attributable across sessions - the primitives described for autonomous agents. Cross-chain settlement belongs in the design document and out of the production path until the verification row changes state.

The honest summary is narrower than the original and more useful. These controls remove specific ways to lose money. They leave the selection step and the host operator inside the trust boundary. One of them is not finished.