Use case
Permissioned shared workflow
Known firms share one workflow. Membership is the assumption. A public token is a different project.
Several organisations want one view of a deal, a shipment, or a covenant, and none of them should be the silent database.
When shared machinery earns a place
When the parties will sign a membership agreement and still want shared execution.
When it does not
A single company's internal process. Use the conventional option.
Conventional-first
Their system, your audit rights, an export.
You negotiated trust instead of encoding it.
Hybrid
Signed messages, a replicated log, a hash anchor. Not necessarily a new virtual machine.
Less machinery. Fewer smart-contract bugs.
On-chain-native
Fabric-style membership or a known-validator chain. Contracts only for the steps that must be shared.
Upgrades, membership, and data residency dominate the design.
Patterns
Components
- Hyperledger FabricGreen — compatible use if you keep the notices
- CometBFTGreen — compatible use if you keep the notices
- Cosmos SDKGreen — compatible use if you keep the notices
Read before you build
Questions a person still has to answer
- Who can add a member?
- Where does the data sit?
- What happens when a member leaves?
