Define the boundary.
Specify the participating organizations, collection members, node locations, and permitted business actions. Decide who operates the network and how membership changes.
QKITE LEDGER THE VAULT
Shared truth.
Private data.
Your business network.
Your rules of trust.
A permissioned Layer 1 design built around post-quantum cryptography, for organizations that need shared facts and private business data.
Private collections · Named organizations · Verifiable decisions
THE QKITE LEDGER NETWORKILLUSTRATIVE VIEW
QKite LedgerONE SHARED LEDGER
Select a participant to see their view ↗
LETTER OF CREDIT #04812 Verified
Issuing bank’s view Private details accessible
ACCESSPermissionedDATAPrivate by collectionDECISIONSPolicy-drivenHISTORYShared & auditable
THE ENTERPRISE TRUST LAYER
Agree on the outcome.
Protect the underlying data.
A business network should not need to choose between a shared source of truth and confidentiality. Ledger’s architecture separates the ordered record from the private execution behind it.
01Shared ledgerOne ordered history for the network
02Private collectionsData held by the organizations that belong
03Attestation policiesExplicit rules for whose agreement counts
Trust is a rule you can inspect.
Collection members execute a business action and attest its result. Validators check that the required organizations signed the same result under the committed policy.
The design does not require validators to read a collection’s private payload. Membership and policy remain visible so the network can understand how a result was accepted.
Read the Ledger architecture →FIVE ENTERPRISE WORKFLOWS
Where shared trust
becomes useful work.
Explore the application concepts, transaction logic, and privacy boundaries in detail. Each is in development as part of the Ledger ecosystem.
01Trade LedgerPrivate trade finance
Letters of credit and invoice finance between banks and businesses.
↗02CredVaultVerifiable credentialsIssue credentials, check signed answers, and manage revocation without exposing the full record.
↗03Chain of CustodyProduct traceabilityFollow product history and verify the organizations behind each recorded handoff.
↗04Consortium VoteConfidential group decisionsCoordinate verifiable voting while keeping ballot choices within the authorized circle.
↗05BidSealSealed procurementCommit to bids, reveal under an agreed policy, and preserve an auditable award process.
↗
Policies you can read
Trust rules are public, versioned and on the ledger.
Who must agree before something counts is not hidden in a vendor's database. Each smart contract declares an attestation policy for every function. The policy is committed to the ledger, and a change is a new version everyone can inspect.
- And requires every listed party.
- Or accepts any one of them.
- OutOf requires a threshold, such as 3 of 5.
policy: release_payment v2
- And
- Issuing Bank
- Or
- Advising Bank
- Confirming Bank
- OutOf 2
- Inspector A
- Inspector B
- Inspector C
FROM ARCHITECTURE TO OPERATIONS
Enterprise readiness
is more than a chain.
Identity, deployment boundaries, operational ownership, and evidence requirements need to be agreed before a production network begins.
Design for evidence.
Map attestation history, access policies, retention, and review responsibilities to your organization’s requirements. Auditability supports review; it is not a compliance certification.
Agree the operating model.
Set availability targets, support ownership, backup and recovery procedures, and incident expectations during deployment planning. Published SLA guarantees are not yet available.
Test the actual process.
Evaluate representative records, failure scenarios, and policy combinations before rollout. The workflow examples here are illustrative, not customer case-study claims.
DEVELOPMENT ROADMAP
Build confidence.
Then scale the deployment.
Proposed development priorities. Timing and launch dates have not been announced; these milestones do not indicate completed releases.
01
Protocol & deployment foundations
Document organization identity, private collections, policy evaluation, and network operating responsibilities.
QKite Ledger02
Reference business workflows
Develop and evaluate Trade Ledger, CredVault, Chain of Custody, Consortium Vote, and BidSeal against representative scenarios.
All five application tracks03
Controls & operational review
Assess privacy boundaries, contract behavior, audit evidence, deployment security, backup, and failure recovery.
Security review & enterprise evaluation04
Deployment readiness
Define release criteria, support terms, service targets, and controlled rollout guidance with the participating organizations.
Operations & service modelPROPOSED APPLICATION TRACKS
What each workflow needs to prove.
ApplicationDevelopment focusValidation focus
Trade Ledger
Development focusLetters of credit, document attestations, and invoice registration.
Validation focusPayment policy combinations and the limits of same-network duplicate detection.
CredVault
Development focusCredential issuance, signed verification, and revocation flows.
Validation focusIssuer authority, revocation freshness, and the information disclosed by each answer.
Chain of Custody
Development focusProduct identity, ownership handoffs, and recall workflows.
Validation focusTransfer policies and the boundary between ledger evidence and physical authenticity.
Consortium Vote
Development focusMembership, ballot recording, tallying, and approval policies.
Validation focusAuditor visibility, quorum rules, and the limits of receipt and collusion guarantees.
BidSeal
Development focusBid commitments, authorized reveal, and award decisions.
Validation focusReveal timing, supplier-held bids, and the evidence behind each procurement decision.
CONFIDENTIALITY WITHOUT ISOLATION