WestwyrdWestwyrd/protocol
VenturesProtocol
PROTOCOL SPECIFICATION · DETERMINISTIC SETTLEMENT

Westwyrd
Protocol

A deterministic execution and verification layer engineered for institutional-grade settlement. The protocol enforces cryptographic validation of state transitions through zero-knowledge proofs, eliminating reliance on trust-based intermediaries while maintaining formal correctness guarantees across all execution paths.

ZK SETTLEMENTTHREE-LAYER ARCHDETERMINISTICNON-CUSTODIALCIRCUIT-BOUNDFORMALLY VERIFIED
Settlement Layers
3
Proof System
Groth16
Hash Primitive
Poseidon
Formal Proofs
Rocq/Coq
Constraints
10,924
Verify Latency
<100ms
FIGURE 01
LAYER ARCHITECTURE · HOVER TO INTERACT · 1–9 TO CYCLE STATES
L3
L2 BASE
L1 ETH
01PROTOCOL ARCHITECTURE

The Westwyrd Protocol operates across a three-layer architecture in which each stratum enforces a distinct class of invariant. Layer 1 serves as the immutable settlement foundation, anchoring all reserve claims through cryptographic proofs of inclusion verified against canonical chain state. Layer 2 manages the propagation of verified state between settlement domains through Merkle proof attestation, watchtower monitoring, and challenge-response mechanisms derived from optimistic rollup theory.

Layer 3 provides the deterministic execution fabric — a institutional rollup with its own sequencer, block production, and fraud proof system in which every state transition produces a verifiable proof of correct execution. This layered separation enforces a strict dependency hierarchy in which no higher-layer operation can override or circumvent the settlement guarantees established at the base layer.

The protocol does not custody assets, make discretionary decisions, or introduce probabilistic execution paths. All outcomes are derived from verifiable inputs, circuit-bound constraints, and on-chain enforcement — eliminating the class of systemic risks associated with intermediary discretion.

Settlement Parameters
Settlement Layers3 — L1 → L2 → L3
Proof SystemGroth16 (zk-SNARK)
Hash PrimitivePoseidon (algebraic)
Formal VerificationRocq / Coq
Constraint Count10,924 R1CS variables
Verification Time<100ms on-chain
Formal Invariants
Protocol invariants are maintained through formal proofs compiled using Rocq. These proofs bind circuit semantics to deployed contract logic, ensuring the on-chain verifier accepts only proofs from the intended circuit.
02L1 SETTLEMENT FOUNDATION

Layer 1 establishes the immutable reserve anchor for the entire protocol stack. All base assets are verified at this level through cryptographic proofs of inclusion computed against the canonical chain state. Settlement guarantees are enforced through smart contract logic formally verified using Rocq, with each contract function bound to specific circuit constraints that prevent divergence between the proof system and the execution logic.

The L1 layer serves as the root of trust for the entire protocol stack. Its security model is inherited directly from the underlying blockchain consensus mechanism — Ethereum's proof-of-stake consensus provides probabilistic finality within approximately 12 minutes (two epochs), after which state is considered irreversible. No higher-layer operation can override or circumvent the settlement guarantees established at this level.

Settlement Finality
Once a state transition has been verified at L1 and the proof accepted by the on-chain verifier, the resulting state is final. There is no mechanism within the protocol to reverse a verified settlement.
Reserve Verification
Merkle DepthVariable — up to 2^32 leaves
State Root CadenceEvery L3 epoch (~12s)
Challenge Window7 days (optimistic)
Gas Per Proof~230,000 (~$0.50 at 30 gwei)
Batch SavingUp to 85% per-verification
Consensus BindingImmutable bytecode
03L2 STATE TRANSPORT
Bridge Security Model
DepositLock-and-mint with Merkle proof
WithdrawalBurn-and-release with ZK attestation
RelayWatchtower N-of-M redundancy
Fraud ProofInteractive bisection protocol
SequencerForced inclusion escape hatch
Cross-Domain Guarantees
No unverified state is permitted to cross domain boundaries. Every bridge message carries a ZK proof of the source-domain state root.

Layer 2 manages the propagation of verified state between settlement domains. Bridge operations are secured through Merkle proofs of inclusion verified by on-chain contracts, watchtower monitoring that provides liveness guarantees, and challenge-response mechanisms that allow any honest observer to contest fraudulent state roots.

State transitions at this layer are validated through zero-knowledge proofs before propagation. The proving circuit encodes the state transition function as a system of R1CS equations. The verifier — deployed as an immutable smart contract on L1 — checks the proof against the circuit's verification key, accepting only proofs that demonstrate correct execution. This provides the same security guarantees as re-executing every transaction at a fraction of the cost.

The relay infrastructure employs a 3-of-5 watchtower model in which five independent observers monitor cross-domain message passing. A message is considered valid if at least three watchtowers attest to its correctness — Byzantine fault-tolerant up to two adversarial nodes.

04L3 EXECUTION FABRIC

Layer 3 enforces execution integrity through deterministic computation bound to circuit constraints. The execution environment operates as a institutional rollup with its own sequencer, block production cadence, and fraud proof system. Every state transition produces a verifiable proof of correct execution committed to L1 for final settlement. The forced-inclusion mechanism guarantees censorship resistance: if the sequencer refuses to include a valid transaction, the user can submit it directly to L1.

Block production follows a deterministic ordering protocol in which transactions are sequenced by arrival time within each epoch. The sequencer has no discretionary reordering capability — eliminating MEV extraction by the sequencer operator. This is critical for institutional settlement where predictable execution ordering is a prerequisite for regulatory compliance and fiduciary obligation.

The proving pipeline operates asynchronously: transactions are executed immediately, and proofs are generated in a parallel pipeline running approximately 2–4 minutes behind the execution frontier. This provides low-latency execution while maintaining full ZK proof security guarantees.

Execution Environment
Block Time~2 seconds
Throughput~500 TPS (batch-proven)
Proof Latency2–4 min behind execution
Batch Size100–500 tx per proof
MEV ProtectionDeterministic FIFO
Data AvailabilityL1 calldata (EIP-4844)
Escape HatchL1 forced inclusion
05DESIGN PRINCIPLES
Determinism

Every unit of value is mathematically provable and independently verifiable. State transitions are deterministic and circuit-bound — given the same inputs and pre-state, the protocol always produces the same output. There are no probabilistic execution paths or discretionary decision points. This property is enforced at the circuit level where the R1CS constraint system rejects any non-satisfying witness.

Non-Custodial Execution

The protocol does not custody, rehypothecate, or exercise control over user assets at any point in the settlement lifecycle. Asset ownership is determined exclusively by cryptographic key possession and state transitions require explicit cryptographic authorization from the asset owner. This eliminates counterparty risk in the custodial sense — a property that distinguishes the protocol from centralized settlement systems.

Cryptographic Enforcement

Settlement outcomes are resistant to manipulation through cryptographic enforcement. The security model does not rely on economic incentives, game-theoretic assumptions, or behavioral expectations. Correctness is guaranteed by the soundness of Groth16, the collision resistance of Poseidon, and the binding property of Pedersen commitments.

06WEFT · PROVABLE MEDIA

WEFT is a source medium, not an effect. Where generative models optimize for plausibility — media that looks real — WEFT optimizes for provenance: media that is verifiable. A WEFT frame carries a proof of the physics and the recipe that produced it. Not “this file was not edited,” but “this image is the verified render of this provable field under this law.”

This defines a category: Provable Media. It does not compete with generative AI — it is the complement. Every convincing synthetic frame raises the market value of one that can prove what it is. The more the industry generates, the more a verifiable frame is worth.

The distinction is structural, not incremental. A diffusion model cannot produce a proof of its own process even in principle — its generation is stochastic sampling, with no deterministic recipe to fold into a root. To offer what WEFT offers, a generative system would have to abandon its architecture and become a physics engine. Provability is not a missing feature; it is a property their foundation excludes.

Provable Media Parameters
EngineWEFT — weave energy, fold truth
ProcessDeterministic physics
Proof SystemSTARK · Poseidon root
Repeatabilitysame input ⇒ same root
The Frame's Claim“check me”
The Moat
A diffusion model cannot prove its own process. WEFT’s recipe is the artifact — it folds to a root. That is architecture, not headstart.
Generative AI vs. WEFT
Axis
Generative AI
WEFT
Optimizes for
plausibility — looks real
provenance — is verifiable
Process
stochastic sampling
deterministic physics
Repeatability
same prompt, new output
same input ⇒ same root
Explainability
no recipe to inspect
the recipe is the artifact
Relationship
vending machine
instrument, played live
The claim
"trust me"
"check me"
07WYRD · ADVERSARIAL COLLABORATION

WEFT was built under a protocol — WYRD: adversarial collaboration for heterogeneous AI agents. No shared framework, no common vendor, no orchestration runtime; a git repository, append-only text files, and discipline. It turns agents from different labs — different vendors, sizes, context windows — into a system where no claim survives unexamined and every artifact carries its provenance.

Wyrd — Old English for “that which has been woven”: the binding, unwritable record of deeds from which present truth is read. The ninth-century word for an append-only ledger of witnessed actions determining trust. The backronym and the etymology say the same sentence — the mark of a name that was already true.

Protocol Status
VersionDRAFT 0.2.1
LicenseMIT (operator-chosen)
EditionsEnglish · 中文
Demonstrated4 agents · 4 labs · 2026-07-18
Repository
github.com/WI-L3-DEV/wyrd-protocol — spec (EN/中文), an optional config-driven gateway, templates, and a parity gate with its sabotage test.
View on GitHub ↗
The Cycle — W · Y · R · D
W
Witness
见证

Work becomes a claim only when witnessed — scoped, evidenced, written before checking.

Y
Yield
让渡

The seat yields its claim to adversarial verification. The humility is structural.

R
Record
封存

The verdict lands append-only. Git is the audit log. Nothing unwritten.

D
Determine
定夺

The record determines trust — what stands written is what you build on.

The Five Commitments
01
Seats, not swarms

Named roles with charters — Operator, Conductor, Implementer, Verifier, Wisdom.

02
The ledger

Append-only proof-of-work plus a board. Git history is the audit log.

03
Gates that can fail

Every gate is proven able to fail, in a sandbox, before it is trusted.

04
The covenant

Assert don’t launder; verify don’t trust; one writer per file; the operator’s hand on every irreversible act.

05
Minimal mechanics

A gateway directory, an optional config-driven server, and a git repo.

Westwyrd Protocol · WEFT · WYRD · Groth16 · Poseidon · STARK · Rocq · chainId 7777 · Ethereum L1