The compliance officer opens the vendor risk assessment form.
Section 7: “Settlement Infrastructure Provider - Legal Entity Information.”
She is filling this out for Plasma. Third new vendor form this week, but this one is different.
The form wants straightforward answers:
Legal entity name
Registered jurisdiction
Primary operating location
Escalation contact for settlement disputes
Standard questions. She has filled out hundreds of these.
Except Plasma’s settlement security does not come from a legal entity she can name.
It comes from Bitcoin.
She reviews the documentation again. State root commitments anchor to Bitcoin’s blockchain. Settlement finality inherits proof-of-work security that has operated across adversarial regulatory environments for over 15 years.
She understands it technically.
She has no idea what to write in the “Legal Entity Name” field.
She messages the implementation team.
“Need entity information for Plasma vendor risk assessment. Who operates the settlement layer?”
Response:
“Settlement security is provided through Bitcoin anchoring. No single entity operates it. That’s the design. It removes jurisdictional dependency.”
She reads that twice.
The risk assessment form does not have a checkbox for “no entity operates this because security comes from cryptographic commitments.”
It has fields for:
Entity name
Address
Jurisdiction
Regulatory oversight body
Her cursor blinks inside “Legal Entity Name.”
She types: “Bitcoin Network.”
Deletes it. That is not a vendor.
She types: “Decentralized cryptographic consensus.”
Deletes it. Legal wants entity names, not architecture descriptions.
The whole point of Plasma’s Bitcoin anchoring is that settlement does not depend on entities whose incentives can shift, whose governance can fracture, or whose validators can be pressured.
The whole point of the vendor risk form is documenting exactly those dependencies.
She opens the compliance framework guide.
“Organizations must maintain documentation of all entities involved in payment settlement infrastructure, including legal jurisdiction, regulatory oversight, and dispute resolution mechanisms.”
Plasma’s settlement finality comes from Bitcoin’s proof-of-work. Bitcoin does not have a legal jurisdiction. It has a protocol that has remained operational across jurisdictions that attempted to regulate, restrict, or pressure it.
That is the feature.
It is also what makes the form impossible to complete.
She calls the compliance director.
“I’m stuck on the Plasma vendor assessment. The settlement security model doesn’t map to our documentation categories.”
“What do you mean?”
“Security comes from Bitcoin anchoring, not from identifiable entities. There’s no company to list. No jurisdiction to record. The architecture intentionally removes those dependencies.”
Silence.
“So who do we hold accountable if settlement fails?”
“Cryptographic proof. The same mechanism that has secured Bitcoin for over fifteen years.”
Another pause.
“I need a legal entity name for the risk assessment. That’s the requirement.”
She looks back at the form.
The requirement assumes settlement security comes from entities you can identify, contract with, and sue if necessary.
Plasma’s architecture assumes settlement security comes from removing dependence on those entities entirely.
Both assumptions make sense in their own framework.
They just do not overlap.
The form expects a company. Plasma delivers mathematics.
She saves the document as draft. Leaves Section 7 blank.
Opens a new file.
“Bitcoin-Anchored Settlement Infrastructure. Proposed Vendor Assessment Framework.”
She begins writing documentation explaining how compliance teams should evaluate infrastructure specifically designed to eliminate the counterparty dependencies their frameworks were built to document.
The infrastructure works.
The forms do not have fields for how it works.
And that gap between entity-based security and cryptographic security remains there in a blank field labeled “Legal Entity Name.”
Waiting for categories that do not exist yet.