> ## Documentation Index > Fetch the complete documentation index at: https://docs.inkwell.finance/llms.txt > Use this file to discover all available pages before exploring further. # SIMD packing > How Dagon packs a batch of participants into a compact FHE layout that evaluates every curve in parallel at the cost of one. > **CONFIDENTIAL & PROPRIETARY © 2026 Inkwell Finance, Inc. All Rights Reserved.** > > This document is for informational purposes only and does not constitute legal, tax, or investment advice, nor an offer to sell or a solicitation to buy any security or other financial instrument. Any examples, structures, or flows described here are design intent only and may change. Dagon's matching state is not a set of encrypted rows, one per participant. It is a compact per-parameter layout: each schedule parameter (curve shape, balances, identity, admission bounds) becomes one ciphertext whose internal slots carry every participant's value for that parameter. The matching graph operates on every participant's curve simultaneously, inside a single bootstrap cycle, at the same cost as operating on one. ## The layout A participant's schedule is a structured pricing curve plus admission metadata. Dagon sorts these into a small number of families: * **Curve shape parameters** — how aggressively the participant quotes as price moves. * **Balance parameters** — the two sides of the pair, bounding what can be filled. * **Admission parameters** — minimum fill fractions and order ordering, used to gate who clears at what price. * **Identity parameters** — the encrypted owner binding, and the side flag (A or B) — both encrypted so the engine can't discriminate by side or identity during the search. Each family becomes its own ciphertext. Every participant occupies one slot-position inside every ciphertext. Slot *i* across all ciphertexts is "participant *i*'s view of the batch." ## The SIMD property FHE schemes that support SIMD packing treat a ciphertext as a vector: one pointwise operation (add, multiply, compare) applies across every slot in parallel, at the same cost as a single-slot operation. Given that every participant lives at slot *i* across every parameter ciphertext, the matching graph's curve evaluation — applied once to each parameter ciphertext — evaluates every participant's curve simultaneously. This is not a compromise around batch size. It is why the batch has a natural shape in the first place: one pointwise FHE op on one slot costs the same as the pointwise op on all of them. ## Lane geometry The batch splits into two sides — a bid side and an ask side — with lanes on each. The FHE graph doesn't treat the two sides asymmetrically during the clearing search. An encrypted side flag tells the graph which half of the batch each slot belongs to, and the graph uses it (blindly) to mask out off-side contributions at match time. ## The four outputs The matching graph emits four ciphertexts per batch: * a single encrypted **clearing price** * a one-bit flag indicating whether the search **converged** * two encrypted **per-lane fills**, one for each side None of the inputs are revealed. The clearing price is a single encrypted scalar. The fills are per-lane encrypted vectors, and each participant decrypts only their own lane via a proxy re-encryption step — see [Life of an order](/dagon/concepts/life-of-an-order). ## See also How the compiled graph actually searches for the clearing price once the lanes are packed. Hover a lane to trace its slot across every parameter ciphertext.