registry_fixtures
Constants
Binary addresses, as the request’s destination carries them
(#157 request-destination-binding). 0x60 is an enterprise payment-key address, 0x70
an enterprise script address, 0x00 a base address with both
credentials.
Registry-mode fixtures (#157): the shared vocabulary the cage’s row tests are written in.
Everything here is BUILT, never pasted. The tries are built by the
library’s own insert, and the proofs are built from the library’s
own combine/nibble/suffix primitives, so a fixture that does
not describe a real trie fails loudly at construction instead of
quietly proving nothing. A hand-typed root would agree with itself
forever.
The deposit a request rides with, over and above the tip. The fold returns it to the destination (#157 request-deposit-returned, the deposit-return requirement).
A SECOND registry held by the same state script (#157 NOTE-004): the same address, the same policy, a different cage token. Two registries can share a script — the script hash is the policy, and the token name is what tells them apart — so a fold of this one must not authorize a custody spend belonging to the other.
Registry keys. Under each token policy the asset name IS the key (#157 token-name-is-registry-key), so these double as asset names.
The request validator’s own address: where a deployed request UTxO actually sits (#157 custody-spend-requires-consuming-fold). It is NOT the cage’s address — the request script is parametrised by the state policy and the cage token, and hashes to something else entirely — so a custody rule that compared addresses would refuse every honest fold on chain.
Functions
A booking’s destination: the record address plus the datum the receiving output must carry.
A read’s destination: a plain wallet output with no datum.
An absence witness’s destination: its first component is the refund address, and it names no datum (the token goes to custody).
The one-step proof for myKey against a trie holding exactly
otherKey -> otherValue: the sibling leaf, with the skip the two
paths actually share.
The Branch step for myKey against a trie whose root node holds
the given occupied slots: the four sibling digests on myKey’s path
through the node’s binary merkle tree, in the order the library
reads them (neighbor_8 ‖ neighbor_4 ‖ neighbor_2 ‖ neighbor_1).
The slot entry a leaf occupies in the root node.
twoLeaves(
keyOne: ByteArray,
valueOne: ByteArray,
keyTwo: ByteArray,
valueTwo: ByteArray,
) -> ByteArray
The root of a trie holding exactly two leaves.
thirdLeafProof(
keyOne: ByteArray,
valueOne: ByteArray,
keyTwo: ByteArray,
valueTwo: ByteArray,
myKey: ByteArray,
) -> Proof
The proof that inserts a third leaf into a two-leaf trie.
The inclusion proof of myKey in a two-leaf trie whose other leaf is
otherKey -> otherValue.
The continuation carrying a state whose datum was tampered with.
approval(
edge: Int,
key: ByteArray,
owner: ByteArray,
destination: (ByteArray, Option<Data>),
) -> Value
The approval the application minted for this edge (#157 tree-edge-admission-by-approval, approval-asset-binding): one asset under the application policy whose name is the binding of exactly this request.
requestDatum(
key: ByteArray,
edge: Int,
owner: ByteArray,
destination: (ByteArray, Option<Data>),
) -> CageDatum
The request datum on the final wire (#183 slice b): the seven-admitted-edges row index
(edge 0-6) with no value bytes and no tip; deposit is the value
above the tip the request rides with (held - state.tip).
requestInput(
index: Int,
key: ByteArray,
edge: Int,
owner: ByteArray,
destination: (ByteArray, Option<Data>),
carried: Value,
lovelace: Int,
) -> Input
A request UTxO carrying its approval and its deposit.
lovelace must be tip + deposit; the fold checks held >= tip and
deposit == held - tip. Non-read rows must carry their approval;
reads carry none (tree-edge-admission-by-approval).
deliveryOutput(
policy: ByteArray,
key: ByteArray,
destinationAddress: ByteArray,
datum: Datum,
lovelace: Int,
) -> Output
The output a minted active or terminal token must land in.
deliveryOutputN(
policy: ByteArray,
key: ByteArray,
quantity: Int,
destinationAddress: ByteArray,
datum: Datum,
lovelace: Int,
) -> Output
The same, carrying quantity of the token: two requests minting one
(policy, key) in a batch owe a single carrier holding both.
The cage’s own custody of a minted absent token.
The old two-field wire at constructor index 2. It is deliberately built as raw data so this refusal control survives the production type correction.
A custody UTxO as a spent input.
A custody input whose complete value is supplied by the row. The datum is produced through the same helper as ordinary custody; only the asset extent is varied.
A plain payment to an address, the refund leg of custody.
An input holding an active token, the burn a terminal update needs.
foldTx(
root: ByteArray,
nextRoot: ByteArray,
requests: List<Input>,
extraInputs: List<Input>,
outputs: List<Output>,
mint: Value,
) -> Transaction
The fold transaction: the state input first, then the requests and whatever else the row needs; the continuation output first, then the outputs the fold owes.
foldTxWith(
root: ByteArray,
continuation: Output,
requests: List<Input>,
extraInputs: List<Input>,
outputs: List<Output>,
mint: Value,
) -> Transaction
The same, with the continuation supplied: the rows that tamper with a pinned field build their own.
custodyOutputWithExtra(
tokenKey: ByteArray,
refund: ByteArray,
lovelace: Int,
extra: Value,
) -> Output
A custody UTxO carrying another non-ADA asset: the shape absent-token-registry-custody refuses.
A custody token sitting in a wallet output instead of the cage’s own custody.
The cage token’s asset name. A function, not a field access on the constant: a module-qualified constant cannot be projected further.