Truly self-sovereign: VaultChain has no "governing council", "stewardship" or some kind of centralised authority. In the same way anyone can run their own email servers, anyone can host a VaultChain cluster and join the network. They chose how and when they connect with the wider VaultChain network and who can use it. End users can consume any part of the network they have access to, and VaultChain then presents that as a single private contiguous network space to each consumer.
Storage burden: As a distributed ledger (DLT) grows in size the cost of maintaining network synchronisation rises with it. In a VaultChain only those that want to hold or verify the data store the data. This places the storage burden of long term data onto those that need the data not onto the network as a whole avoiding a tragedy of the commons.
Trust relationships: Hubs partition the size of the VaultChain to relevant participants, allowing owners to trust groups of network participants rather than just chains of hashed blocks. Hubs allow allow certain partitions of the VaultChain to operate with higher levels of trust than others.
Reputation: Because VaultChains are multi-node directed graphs, decentralised trust is built on network reputation & distance rather than proof-of-work.
Anonymity: Data stored in a VaultChain is built from anonymised linked data sets, the data can be retrieved and aggregated from multiple Vaults into large queryable graphs without breaking network anonymity. Sub-graphs within the dataset can be validated by different network participants.
Zero-knowledge: A VaultChain uses zero-knowledge proofs to reference specific datasets so preserving anonymity, whilst ensuring the graph is still navigable.
Audit Trails: A VaultChain allows newer data to be stored, updated & referenced as part of a single piece of auditable data.
Compliant: Data can be permanently deleted from a VaultChain, but only when all members of a Hub holding that data agree to its deletion.