Warning
ATTENTION : PROJECT IS IN EXPERIMENTAL MODE
Caution
FREQUENT DRAMATIC CHANGES TO THE CODE, ARCHITECTURE AND CONCEPTS ARE NORMAL AT THIS STAGE
A multi-chain, client-validated protocol for cryptographic ownership, transfer, provenance, and state evolution using Single-Use Seals, canonical commitments, deterministic replay resistance, and adversarial runtime orchestration.
Where Parwana sits in the DieWan Accountability Platform:
flowchart TB
PAR["Parwana · protocol<br/>canonical bytes · verifier · SDK"]
PIT["Piteka · product<br/>authorize · execute · investigate · Postgres live state"]
TUP["Tuppira · data plane<br/>observe · index · read model"]
HEM["Hemion · developer console<br/>explorer · local verifier · wallet"]
CON["csv-contracts · chain anchors<br/>optional anchor provider"]
PIT -->|uses protocol + verifier| PAR
PIT -->|signed evidence feed| TUP
TUP -->|read model| HEM
HEM -->|verifies locally| PAR
PAR -.->|anchors commitments| CON
TUP -.->|observes anchors| CON
classDef here fill:#2563eb,stroke:#1d4ed8,color:#ffffff;
class PAR here;
You are here — Parwana, the neutral protocol. It defines what mandates,
receipts, and sanads mean, owns the canonical byte/hash pipeline, and provides
the verifier. Every product above (Piteka, Tuppira,
Hemion) depends on Parwana and must never redefine its meaning. See
the org charter in development/ARCHITECTURE.md.
Foundational terms for a newcomer to Parwana:
| Term | Kind | Plain-English meaning | Real-world example |
|---|---|---|---|
| CSV (Client-Side Validation) | Keyword | Clients validate truth locally from proofs that travel with ownership; chains only anchor commitments, never execute global state. | Verifying a signed PDF yourself instead of asking a central server. |
| Sanad | Data structure | Parwana's native proof-carrying ownership instrument (سند, "deed/title"). | A property deed that carries its own chain of proof, not just a DB row. |
| Single-Use Seal | Data structure | A consumable ownership condition that can be closed exactly once, giving replay/double-spend resistance. | A tamper-evident seal on a package: once broken, it can't be reused. |
| Transfer | Data structure | A state transition that consumes a seal and creates new ones, moving ownership deterministically. | Endorsing a cheque over to a new payee — the old claim is spent. |
| Commitment | Keyword | The canonical, deterministic byte/hash encoding of protocol state that a chain can anchor. | An official, byte-for-byte fingerprint everyone can re-derive and cite. |
| Anchor | Keyword | Publishing a commitment to a chain as optional timestamp/settlement evidence. | A notary stamp proving something existed at a point in time. |
| Verifier | Component | The side-effect-free function that turns evidence + rules into a deterministic verdict. | A referee applying a fixed rulebook to reach the same call every time. |
| Replay resistance | Keyword | The guarantee that a past transition can't be re-applied to double-spend. | A one-time password that stops working after a single use. |
Parwana is a constitutional protocol system built around three foundational ideas:
- Client-Side Validation
- Single-Use Seals
- Sanads
Together, these create a protocol where:
- ownership evolves off-chain,
- clients validate truth locally,
- chains anchor commitments rather than execute global state,
- transfers become deterministic proof transitions,
- replay and double-spend resistance emerge from seal consumption,
- provenance becomes cryptographically portable,
- state scales without requiring universal replication.
Parwana is not a traditional blockchain application.
It is a client-validated cryptographic state protocol capable of operating across heterogeneous chains while preserving deterministic ownership semantics and adversarial integrity.
The system combines:
- RGB-style client-side validation principles,
- cryptographic seal semantics,
- multi-chain anchoring,
- replay-safe transfer algebra,
- deterministic recovery,
- constitutional runtime enforcement,
- formal invariant modeling,
- canonical proof systems.
The protocol does not require every participant or chain to execute and store the entire global state.
Instead:
- state transitions are validated locally,
- proofs travel with ownership,
- chains only anchor commitments,
- validity propagates cryptographically.
This radically changes scalability assumptions.
Global Consensus
↓
Global Execution
↓
Global Replication
↓
Global Validation
Local Ownership
↓
Proof-Carrying State
↓
Client Validation
↓
Chain-Anchored Commitments
The blockchain becomes:
- a timestamping layer,
- a settlement anchor,
- a commitment publication surface,
—not the authoritative holder of complete protocol state.
Single-Use Seals are the foundation of state evolution.
A seal represents a consumable ownership condition.
A valid state transition:
- consumes a previous seal,
- creates new seals,
- commits the transition cryptographically,
- prevents replay or double-spending.
A seal can only be closed once.
This gives the protocol:
- deterministic ownership lineage,
- replay resistance,
- monotonic state evolution,
- cryptographic transfer finality.
The protocol treats ownership transitions as:
Seal Consumption → State Transition → New Seal Creation
rather than mutable account balance updates.
Sanads are the protocol’s native cryptographic ownership instruments.
A Sanad is not merely a token or receipt.
It is a:
- proof-carrying ownership artifact,
- selectively-disclosable cryptographic document,
- canonicalized provenance container,
- transferable state instrument,
- replay-safe commitment structure.
Sanads can encode:
- ownership,
- provenance,
- claims,
- attestations,
- rights,
- transfer history,
- content commitments,
- resource relationships.
They evolve through seal consumption and client-side validation.
┌────────────────────────────────────────────┐
│ SANAD │
│--------------------------------------------│
│ Ownership State │
│ Provenance │
│ Claims │
│ Commitments │
│ Transfer Conditions │
│ Selective Disclosure │
└────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────┐
│ SINGLE-USE SEAL │
│--------------------------------------------│
│ Consumable Ownership Condition │
│ Replay Prevention │
│ State Transition Authorization │
└────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────┐
│ CLIENT-SIDE VALIDATION │
│--------------------------------------------│
│ Proof Verification │
│ Consignment Validation │
│ Transition Verification │
│ Canonical Commitment Checks │
└────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────┐
│ CHAIN ANCHORING │
│--------------------------------------------│
│ Bitcoin │
│ Ethereum │
│ Solana │
│ Aptos │
│ Sui │
│ Celestia │
└────────────────────────────────────────────┘
Parwana is designed to provide:
- scalable ownership systems,
- replay-safe state evolution,
- cryptographic provenance,
- privacy-preserving transfers,
- deterministic recovery,
- selective disclosure,
- multi-chain interoperability,
- adversarial resilience,
- formally-governed protocol execution.
Traditional blockchains force every node to:
- execute everything,
- store everything,
- validate everything.
Parwana rejects this model.
Instead:
- owners carry proofs,
- clients validate locally,
- chains anchor commitments,
- state is transferred through consignments.
This creates major advantages.
The protocol avoids global execution amplification.
Only relevant participants validate state transitions.
This dramatically reduces:
- chain congestion,
- replicated computation,
- state bloat,
- execution overhead.
Scalability emerges from eliminating unnecessary universal validation.
Only parties involved in a transfer need full state visibility.
Selective disclosure allows:
- proof minimization,
- hidden historical state,
- confidential ownership relationships,
- partial provenance disclosure.
Ownership lineage becomes explicit and cryptographically provable.
Every state transition:
- consumes seals,
- produces commitments,
- carries provenance,
- preserves deterministic history.
Parwana is built as a constitutional system.
The repository does not merely organize code. It attempts to constrain what the system is allowed to become.
The architecture prioritizes:
- invariant enforcement,
- semantic purity,
- deterministic behavior,
- replay resistance,
- explicit state transitions,
- adversarial survivability.
┌────────────────────────────────────────────────────────────┐
│ APPLICATION LAYER │
│------------------------------------------------------------│
│ SDKs · CLI · Services · Wallets · APIs · Agents │
└────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ SANAD LAYER │
│------------------------------------------------------------│
│ Ownership Instruments │
│ Claims │
│ Provenance │
│ Selective Disclosure │
│ Content Trees │
│ Commitment Chains │
└────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ CLIENT VALIDATION LAYER │
│------------------------------------------------------------│
│ Consignments │
│ Proof DAGs │
│ Seal Validation │
│ Transition Verification │
│ Canonical Commitments │
│ Proof Provenance │
└────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ PROTOCOL LAYER │
│------------------------------------------------------------│
│ Transfer Algebra │
│ Replay Protection │
│ Finality Models │
│ Capability Negotiation │
│ Deterministic Recovery │
│ State Transition Governance │
└────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ RUNTIME LAYER │
│------------------------------------------------------------│
│ Coordination │
│ Backpressure Control │
│ Replay Databases │
│ Failure Domains │
│ Event Recovery │
│ Lease Management │
│ Byzantine Containment │
└────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ MULTI-CHAIN ANCHORS │
│------------------------------------------------------------│
│ Bitcoin · Ethereum · Solana · Aptos · Sui · Celestia │
└────────────────────────────────────────────────────────────┘
Parwana is chain-aware, not chain-naive.
Different chains provide different guarantees.
The protocol models these differences explicitly.
| Chain | Role |
|---|---|
| Bitcoin | Commitment anchoring, SPV proofs |
| Ethereum | Smart contract settlement |
| Solana | High-throughput execution |
| Aptos | HotStuff checkpoint semantics |
| Sui | Object-centric state validation |
| Celestia | Data availability anchoring |
The protocol does not flatten all chains into fake uniformity.
Instead, it adapts to:
- finality models,
- proof structures,
- consensus assumptions,
- execution semantics.
Parwana assumes:
- chains reorg,
- RPC nodes lie,
- proofs are malformed,
- operators fail,
- runtimes crash,
- relayers equivocate,
- recovery replays occur.
Therefore, the system is designed around:
- deterministic replay prevention,
- explicit seal consumption,
- canonical proof semantics,
- constitutional invariants,
- cryptographic lineage,
- bounded recovery semantics.
Verification exists at multiple layers.
| Layer | Responsibility |
|---|---|
| Seal Layer | Ownership integrity |
| Validation Layer | Proof correctness |
| Protocol Layer | State legality |
| Runtime Layer | Execution survivability |
| Chain Layer | Commitment anchoring |
| Formal Models | Mathematical invariants |
Replay resistance is protocol-native.
The repository contains:
- replay algebra,
- replay databases,
- replay simulations,
- replay constitution tests,
- deterministic replay tracking.
Replay safety is part of the ownership model itself.
The protocol aggressively minimizes ambiguity.
The system includes:
- canonical serialization,
- canonical hashing,
- domain-separated commitments,
- proof normalization,
- stable commitment derivation.
This prevents:
- proof drift,
- serialization inconsistencies,
- commitment instability,
- cross-runtime divergence.
Parwana is intentionally designed for hostile environments.
The repository contains:
- Byzantine RPC simulations,
- crash recovery testing,
- reorg simulations,
- adversarial transfer tests,
- compile-fail invariant tests,
- differential verification suites,
- formal protocol models.
The system becomes stronger as failure conditions are exercised.
The repository includes:
- TLA+ models,
- Alloy specifications,
- constitutional tests,
- compile-fail invariants.
These formal systems encode:
- ownership semantics,
- replay safety,
- transition legality,
- seal consumption invariants.
| Crate | Responsibility |
|---|---|
csv-protocol |
State evolution + transfer rules |
csv-algebra |
Pure ownership algebra |
csv-runtime |
Execution orchestration |
csv-proof |
Proof systems + provenance |
csv-hash / csv-codec / csv-wire |
Hashing, canonical encoding, and transport types |
| Component | Responsibility |
|---|---|
seal.rs |
Seal primitives |
seal_protocol.rs |
Seal transition logic |
seal_consumption.rs |
Seal closure semantics |
consignment.rs |
Transfer consignments |
proof_provenance.rs |
Proof lineage |
selective_disclosure.rs |
Controlled proof revelation |
content_tree.rs |
Commitment structures |
| Adapter | Responsibility |
|---|---|
| Bitcoin | SPV anchoring |
| Ethereum | Smart contract verification |
| Solana | Program coordination |
| Aptos | Quorum checkpoint verification |
| Sui | Move-state integration |
| Celestia | DA commitments |
The repository already demonstrates:
The architecture clearly expresses client-side validated ownership semantics.
Replay resistance, seal consumption, canonical commitments, and deterministic recovery are deeply integrated.
The system validates itself through:
- compile-fail tests,
- replay simulations,
- Byzantine testing,
- formal models,
- differential verification.
The repository increasingly separates:
- ownership algebra,
- protocol semantics,
- runtime orchestration,
- chain anchoring,
- transport encoding.
The protocol integrates heterogeneous chains without collapsing semantic differences.
The architecture assumes hostile environments and designs around survivability.
The protocol is architecturally advanced but still undergoing hardening closure.
Some verification paths still require final implementation closure:
- aggregate signature verification,
- complete Merkle verification coverage,
- finality verification hardening,
- proof completeness guarantees.
Some constitutional invariants still need universal mechanical enforcement.
The final goal is:
- zero bypass paths,
- zero silent downgrades,
- zero ambiguous verification semantics,
- complete runtime-governed execution.
Boolean verification APIs should evolve toward proof-carrying verified types.
Example:
Verified<SealTransition>instead of permissive truth-return semantics.
Additional work remains around:
- distributed pressure propagation,
- Byzantine endpoint aggregation,
- adaptive capability negotiation,
- runtime isolation guarantees,
- stronger recovery containment.
Parwana is not a bridge.
It is not merely a transfer runtime.
It is not a blockchain application.
Parwana is evolving into a:
constitutional client-side validation protocol for cryptographic ownership, provenance, and multi-chain state evolution.