Documentation Index of Independent Settlement Protocols.
Over the past months I have deployed a series of independent smart contract protocols on Ethereum mainnet. Each one is finished, immutable, and ownerless. Each one does one thing.
This post introduces The Substrate: not a protocol, not a framework, not a suite. A documentation index. One place where these protocols are briefly described, individually linked, and shown to be orchestratable, even though they are not aware of each other and do not depend on each other in any way.
What each protocol is
Every protocol in this collection follows the same structural pattern:
-
An ERC primitive that represents a physical or digital object or asset on-chain
-
Immutable smart contracts that handle neutral, deterministic settlement
That is the complete structure. No governance. No upgradeability. No owner. Each protocol is deployed, verified on Etherscan, and ownership renounced. They run without me or anyone else.
Each protocol also has a separate quick-start templates repository. The templates are reference implementations, the direct, documented path to building on each protocol without going through any platform or intermediary.
The protocols
DeDe: parcel settlement. P2P pickup, dropoff, and delivery confirmation. ERC-721 parcel primitive plus escrow and signer registry.
DROP: physical storage settlement. Intake, hold, and release of physical goods at a storage node. ERC-721 storage session primitive plus optional escrow.
CUT: digital ownership and rights settlement. Fractional or full ownership rights of any digital medium. ERC-1155 media primitive plus scene registry.
KEY: vehicle ownership and sale settlement. ERC-721 vehicle identity anchor plus atomic sale settlement. In jurisdictions where vehicle registries expose APIs, platforms built on KEY can initiate legally recognized ownership transfers from the decentralized side. The registry cannot initiate or modify a KEY transaction. The bridge is one-directional.
STAY: commodity settlement. Representation and settlement of commodity assets and access rights.
ACT: physical service settlement. Agreement, delivery, confirmation, and settlement for any real-world service. Scale and context are irrelevant to the protocol.
Independent by design
These protocols do not know each other exist. There is no shared state, no internal coupling, no common coordinator between them. Each one is deployable and fully functional in complete isolation.
They share a design pattern and an author. That is the extent of their relationship.
This is worth stating directly because the temptation when seeing a collection of protocols is to read them as a system that must be used together. That is not what this is. A logistics platform might use DeDe and DROP. A media platform might use CUT alone. A vehicle marketplace might use KEY alone. A travel platform might use STAY and ACT. None of these require any other protocol to function.
The orchestration possibilities exist because each protocol is a clean, narrow primitive. Combining specialized tools produces more leverage than one tool attempting to do many things. But combination is always a platform decision, never a protocol requirement.
Blockchain microservices
The closest architectural analogy is microservices. Each protocol is a self-contained service with a single responsibility. It exposes a deterministic interface. It has no opinion about what surrounds it. Platforms orchestrate them the same way a system orchestrates independent services, at the layer above, without modifying the services themselves.
The difference from conventional microservices is permanence. These are not services that can be taken down, modified, or redeployed by their operator. They are immutable infrastructure. The settlement behavior defined at deployment is the settlement behavior forever.
What this means in practice
Until now, settling a real-world transaction on-chain required either building the settlement logic yourself or relying on a platform that controls the rails. Platforms that control rails can extract fees, modify behavior, gate access, and be captured by external pressure.
These protocols are rails that no platform controls. The protocol fee is immutable and set at deployment. The templates ensure the direct path to the protocol is always open and documented. No platform can close that path.
This does not make existing platforms obsolete. Platforms add real value through matching, discovery, user experience, and legal compliance. What changes is that the settlement layer beneath them is now neutral, permanent, and accessible to anyone.
The option exists. That is what this post is about.
The Substrate
Protocol repositories, template repositories, contract addresses, and orchestration examples are documented in one place.
https://github.com/pablo-chacon/substrate