Amaru Treasury - May 2026 85-Tx Lattice Report

Direct network-state SPARQL report running over a real 85-transaction on-chain lattice built end-to-end from tx-fetch + tx-graph + Apache Jena.

• Network-scope transaction set — the 85 txids that touch the amaru-treasury.network_compliance address during the report window. The report treats this list as an input boundary selected from the address history described below.
• Closure — fetched by tx-fetch from Blockfrost via /txs/<hash>/cbor only (no /utxos, no /inputs, no /outputs). Fetch depth is 0: no generic parent walk is needed for the network treasury final-state proof because every in-scope producer/spender transaction is already in the 85-tx list.
• Emission — tx-graph --rules rules.yaml --in-dir closure/cbor --out-dir closure indexes every fetched CBOR by computed transaction id and emits one canonical Turtle file per transaction.
• State boundary — the final UTxO state is recomputed from graph topology: outputs to the network treasury minus outputs whose (txid, index) is consumed by another transaction in the same 85-tx graph.
• Total graph size = 85 network-scope txs, each in its own canonical Turtle file under closure/<txid>.ttl.
• State-audit boundary — Queries 14-16 use the 85-tx network_compliance address history through the live snapshot boundary (block 13,467,438; slot 188,217,701). Query 14 is graph-only. Queries 15-16 compare that graph-derived state with the separate live snapshot in live-utxos.ttl.
• USDM accounting boundary — Queries 17-21 turn that complete network_compliance graph into a user-facing proof: the treasury starts with 0 USDM, receives 425,131.618692 USDM from swaps, pays 418,750 USDM to the CAG payee bridge, and retains 6,381.618692 USDM with zero accounting gap.
• Operator rules — rules.yaml carries on-chain entities, off-chain vendors, IPFS-anchored attestations, and CIP-57 blueprints.
• Engine — Apache Jena 5.6.0 sparql CLI.

flowchart LR
  blockfrost[Blockfrost CBOR API]
  txfetch[tx-fetch]
  cbor[CBOR closure]
  txgraph[tx-graph]
  rules[rules.yaml]
  closure[closure directory]
  scope[85 txid input list]
  live[live-utxos.ttl]
  jena[Apache Jena]
  answers[SPARQL answers]
  final[Final-state proof]

  scope --> txfetch
  blockfrost -->|CBOR only| txfetch
  txfetch --> cbor
  rules -->|entities blueprints attestations| txgraph
  cbor --> txgraph
  txgraph -->|Turtle per tx| closure
  closure --> jena
  jena --> answers
  jena --> final
  live --> final

Initial Conditions And Txid Selection

The SPARQL queries are integrals over a bounded transaction lattice. They prove conservation and final state for that interval; they do not magically infer the opening state. A correct report therefore needs two inputs before the queries make sense:

• a valid initial condition for the scope being audited,
• a txid set that is complete for all in-interval changes to that scope.

For this report, the boundary is not a generic parent walk and it is not the full ancestry of every transaction. It is the complete network_compliance address-history slice for the state interval being audited, paired with the initial condition that the scoped address held 0 USDM at the beginning of the interval.

The selection rule used here was:

1. Choose the scope address: amaru-treasury.network_compliance (addr1xyezq8wpaqnssdjvd3p220uf7e6nzjae44w6yu625y965rfjyqwur6p8pqmycmzz55lcnan4x99mnt2a5fe54ggt4gxs8thzgk).
2. Choose and document the initial condition. For the May 2026 report, the initial condition is that the scope address has 0 USDM at the start boundary.
3. Choose the end boundary used for the live-state comparison: block 13,467,438, slot 188,217,701.
4. Enumerate the Blockfrost address transaction history for the scope address through that boundary.
5. Keep the transactions in the report interval that touch the address, meaning transactions that either produce an output at the address or spend a previous output from the address.
6. Record the resulting 85 txids in the network-txs.txt boundary block rendered below.
7. Fetch exactly those 85 transactions with tx-fetch --depth 0, emit the graph with tx-graph, and verify terminal state with Queries 14-16.

The concrete provider calls are documented on the Blockfrost provider page. The persisted network-txs.txt file is the audit boundary; tx-fetch only retrieves and hash-verifies the CBOR for that boundary.

This selection is correct for a final-state proof when the initial condition is true and the selected txid set is state-complete for the scope address: every in-interval producer and spender of the address is included. If a previous address UTxO exists at the start boundary, the report must include that opening UTxO state explicitly. Moving the start boundary back to a point where the address is empty is just the special case where the opening state is zero.

With those inputs, the SPARQL queries behave like ledger integrals:

opening state + in-interval inflows - in-interval outflows = terminal state

If the equation does not match the live terminal state, the bug is in one of three places: the opening state is wrong, the txid set is incomplete, or the graph/query emission is wrong.

The report verifies the selection in two ways:

• Query 14 recomputes terminal UTxOs from graph topology alone.
• Queries 15-16 compare the graph-derived terminal UTxOs with the separate live UTxO snapshot at the selected end boundary. A non-zero diff means the txid set is incomplete or the boundary was chosen incorrectly.

Boundary Files

These are the proof inputs rendered from the exact files used by the report. They are shown here so the boundary can be inspected without leaving the documentation page.

rules.yamlnetwork-txs.txtlive-utxos.ttl

version: 1

entities:
  - name: amaru-treasury.contingency
    from-address: addr1x8ndhlcfy30t38z0tql64fpg8ply93r37xrgvdagfpsz5nhxm0lsjfz7hzwy7kpl42jzswr7gtz8ruvxscm6sjrq9f8qruq0ae
  - name: amaru-treasury.network_compliance
    from-address: addr1xyezq8wpaqnssdjvd3p220uf7e6nzjae44w6yu625y965rfjyqwur6p8pqmycmzz55lcnan4x99mnt2a5fe54ggt4gxs8thzgk
  - name: amaru.cag-payee
    from-address: addr1q8qrds2nnx7clx3kcpp2l0eu45twmdcahsfu9m0xcwy59j6xz3vs0hnfaz9nhje8z34kfnds4jyk7hs6dnrag6e2lfgqtyf4rl
  - name: amaru.swap-order
    from-address: addr1x8ax5k9mutg07p2ngscu3chsauktmstq92z9de938j8nqaejyqwur6p8pqmycmzz55lcnan4x99mnt2a5fe54ggt4gxst7gy3n
  - name: sundae.swap.v3.order
    script: fa6a58bbe2d0ff05534431c8e2f0ef2cbdc1602a8456e4b13c8f3077
  - name: amaru.network-operator
    from-address: addr1qx9aqvsf6gne2640jec828s25gzhk5wp2day8u24kf8mrs2v0zyuvk80fay35dx008p45ts0u6cdrv9g2maetq8jm8psznjcrz
  - name: amaru.antithesis
    role: fuzz-testing vendor
    paid-via: amaru.cag-payee
  - name: amaru.castellum
    role: engineering vendor
    paid-via: amaru.cag-payee

blueprints:
  - script: amaru-treasury.contingency
    datum: ../../test/fixtures/rewrite-redesign/blueprints/amaru-treasury.cip57.json
  - script: amaru-treasury.network_compliance
    datum: ../../test/fixtures/rewrite-redesign/blueprints/amaru-treasury.cip57.json
  - script: sundae.swap.v3.order
    datum: ../../test/fixtures/rewrite-redesign/blueprints/sundaeswap-v3/plutus.json

attestations:
  - ipfs: ipfs://bafkreicnoadlgnc6cqxggxboho7yt532lkonxcusj3ndsxdnv5szyswyam
    label: Invoice INV-635
    of: amaru.antithesis
  - ipfs: ipfs://bafybeib3jef34ndw6oe24mkmifdvxe5jrv7ulh63rdllovyth27mqfj2da
    label: Contract
    of: amaru.castellum
  - ipfs: ipfs://bafybeigy37ui2ikn7bim2vw6cojcbxkcndpjwh7cj5fv3vzs4cszezipxu
    label: "Invoice #3508"
    of: amaru.castellum
  - ipfs: ipfs://bafybeihdmnitrbu2oir3r2fefnpqy3bk7zdz42olzmltmxyt5xag4i2t5a
    label: May 2026 cycle review
    of: amaru.castellum

64f27254f3c0311fb2e672cdb87de200089a596aa90dc09f8be4248540267cf0
dfd355530e2d3baef6fc4cb22369c8b64aa117b0a84ff2cdaadc24cdc3fbc7bc
10a5c1dafe7dd8d4ab680e35dc53b8b550da90bea55f2c758f36474064f2e598
cda0126e9ea7b336bbb338d2bfc7622a41b584e3bebc33c9c320e8895b9bc082
b5716ae98bb41b53c5fa2ebc6e8d5558879dc86d14fb998333e643095c6b233e
5b5be77ff0fa77ba50a21019f607b5087213d1aae9a444bbc597bfc4ec78e236
4a9a1acf4083f6d936ac5c1256b2cca6c3f78ad795d10b76bb2cb574f7ce69f7
26ef34aa02aecfb068e44f00e7d2f50deef377d168a7e33d1e7d01a11f32d46d
890ac3b9553fefa161ecbd4b0f43dbe3b1957e465d3a589a08eac87e34e4ebc0
f2791967f99ac04b33da17bd9c848b673c690a40d647b1e21e2651ff7a2f4657
3c3d5332cb159a5f0b42cf48a6f897f1603f94fb4405c6f0c1146d5feb627963
ea0f01a2e13930cdba2708a9bb29cde0f81d98faf12029a8497a591bbdbc66f3
2695f20941ac832a9b36fdbe4f0b78a8f5bafddf964b353b81aec360a13df3f3
b63aa2dd78c2a63b71aeba687cf45d445a98653a81f48774aa30236e47f30b86
8f25b442637df2d7b4cee3a5264a2b88ab0964739dbe117676eb3b1a9f4ce181
a044b2b0c42d3abe48bb2c37e4ba833c785493abaf0fd66ae042357a43ede1c5
5fc04113da630ec676a5a7a66d82f53c0e64527ee592c3e6c5e1dccad67732ea
76d6988cd15f1b302fc0832b3c4fa0f1e2c904baa9e8661bda82d938501d5511
ee4c3dbead1154a6f0fcbbff01256ce3ce54f9fe64cd38df3044d707f2951cdb
5262be893119bd6d43c1c2fce5b0b89f7ac15f8e7d3d3dd66d0eb01e42b875d7
bde8ee921e26480a389ca338ac3fcdfb128bd7491ca4314c79fe07b115f87ffa
856e3d0eeacfd9b4ec5f36445f7bd9122789aead0a2de5fd8a8086413d52f80f
a38cb99bab8eb9922454fc7ae61ca38ff31b54d0db4afa6b33933763ba1cfd09
02fce56796d2cdca3cef16804b05f78d9c0feefe670af62c12c9952e8152bd9e
c5e6215afb677ecaf2d50ccdf5c5b5d405acc695c69549380e3a76eef7438b20
107e439f247fad6bd05543d81b9139547c521f50e5409120bed9f3d80b644055
7ff3f76c6b5297c9b3bd993af909c35b091038e37fe4b977426ffce54570544c
1d553bb307d5175d320905c14bb2848c041bbc9783fcaa7d67cf49b7bb2ce210
9d3b688e79e323ecee6efe1ef0716da2bd16a036c69a72dda369ad38de1df3e6
b1fe257e4f0a089d30322ccfc51c024704be07464be14f270d7b5314ee771a2f
cf87cc63f28710a871f855d0780e06acebb349a16fd2ba5f1e3e7f9c34a39e46
013329ee0504d62c593491b76084bdd3958c0578037d28382c0de4611709c3f6
ad6ac0a1889733757f4503dac327ee57d3397dadf2948bff624f315ea0754aeb
8c3f683232a419dcfee68fccefe13671f45b516423b280cd0e7fe6b52d55e125
4672b92d72148fb93a976a982ec6dce7d7eccbc30a6bcb11dd96a007f4b61b04
c930e881c5e068da8b342e58162be8a8062cc8a8433a1709c987cdbce627fd30
52f1e3c747bbe74f8fb3d2e0dd425159bae3293c8ba096e385ddf5e0d6c30a5d
cf3cfb872ec5168bf8fda7245412e0d9f722df77d406b50083db84b387dee7f4
7ac5f9e3f5de550b72aaf9e1c476bac02837e44d22600ddc00f63c7b4e753d7f
2712775e11fa6266f05a45bb4d13e64fb6667d11ccd4712928e7e608b30ade7d
241eef10d85ae3d02dc422b1e12a30e6e8e28873ca3126f0ba56a64ec1d65ca1
b6c89a612d0a22a0072adf64c9b3fd1fcaa448d017b8c20dcc2ad13403ec3595
7a1ac8c39eec4822a8c633eca15e770e4f0977a6f5b3cd55a8313dfd505a28eb
9647a5127587b57946bf2d92954e86515062c9c911831068cde0d118cebad6bc
22e914892e83c22e19514937914ca32a0c059f9d1c5b555429edde0ea3406ae4
7e0d63c45ed70d2bd501729198bd5a80050d6b17c6bc2e384cb9aeaa2b11276b
0f9818a51aad4b404d5a9a0d3eeaf5d16f4849229ce03a7f9c77adb32b17518f
432eef5e39adcb65adbd9df5f8563701bdd4ef7a95a0d361fb2f9307b8dc601a
7fa113e902328268a7513a087dfc39b0d2ddf449f4305ff89c469d129d361f35
d0dba5b8f18fc3ce462fc49f54fa6c500b535be26e6426a920dc1594ca4293e0
4e2642080c8d171aad05baed11b076de498b76acecc1c2412660048fae8aefa3
26542f223ee27990e35555a7a328299c61e6f802b075b1e00b01befcdb597871
e96ce306b486d880526468a6546c6f8773afda9d8715c01944b9273f8ef0f98d
375c82a8a31640fe3fc19f5f60283fffd036a99ee1b10263bb12352e426c50ac
ee9d02118fce1dd7b5b9dd5ce516bd12550bb86b961a7dc2ab11ddd37d0be21b
59e10ca5e03b8d243c699fc45e1e18a2a825e2a09c5efa6954aec820a4d64dfe
a8bab7bfe1e2ed9d3a5b40189c8de51c5974a6e05c71fc1000a6abd57500b365
7353059f0e0f59e974887b3f2405019e26c2a06673a9ce45d3cfdcbd814d5896
04bb08742e4a6628bb2dd8ee61fe2c639079ab9a64d5b2785f023f7857cc8b81
36d57c1be24bd617d1b7eb1f4aa4a391c3f351aa5b6cc4ac32ebc1dd2ded4d84
3df69cf6f74a873c0be2fa85fac8357fb06eea13da289ee1180a7dddef3652b5
488e5b417aa4f573528057fd1d7ab6de4f7ad06e296f945ee4097d8a94ee62e7
8cf1c5189f67042a0fce930cb9a1551412de8d99ee9ccd646f1dd128cb565e52
18d57a4f104df4cc776104ce626958e2110122392e4c4c7671edc8861b48452e
9f119393a85bb9aa0c94f8c649288dabb956b88dcbe055b10e741a2237123420
68a1277af23755376967e788752c603044f45ea0d99220b3b5dfc7d617642b6b
415d927ab3f4790f5a49381fe5e5fc60e98bcdfdaf86da2da456c55e6cda98dc
77d687bc713dd707e357fc0da992fe7eb02a6baadef0a1cbe029563b54b10a27
151332baa8ca3f63a74cb1ed5af4e0cab42cafc50177cade447e8d51b6c7f9c3
8086a248e300e546e0b1d7264e25337fe3d07bea154b8366d94cd7888147ff24
b41077f8c2f0df03bd5b1920a8b555ccd2a22569e7cfeeb7841792acccd2b8c1
85b07746f93e8e1b670f55e14f98950f94c6cb52cad12c7c420050ee67c91bbf
ae4ca964ad316bd6ee76986a99432bc0b8deea8f8af4a7d484b17cc269c8b5dc
3ecffded917bb6aac602ae47ceb107b4c16c791e0956001565a920cfb1c03c6f
5990ce947962fcdea2f551c6a51efb139d34606aae668de255dd50d4c0ca3b53
cb56b9c0f40ec6d32f0126f946438625bce19097b228e51aa8c8e2aff6ec8b3a
44454ed0def64621ef645958830f599b488b699b28e3797cc37c4f4dd1463a79
77b1b046d1bfb1a09011d4606817ea45d13d8d9e0d02258984d0c6126e4cc9e9
c150d5c5c67658c8f2a3bc24e16a4852257d46a03224257ac990fcca6f6fde78
cb8f1a1254d650afc1c5b2a1e677df24ac72c4540e96eff52072bcb04b7274ba
019586ee09f54155379d36ea2c6aa010296dcf5b8e28564a668bec1a44d8f503
71ff129b5e0b5983ac01da968c6e345a8b6bc36d650a27f18c02ea9787a13dbe
65bfd93936abf4fb26a135e89bd3ef133bb4b02152b37199586ed443979a95b1
021e6b48610dd73b9c72c39f50986c1f2a34927fe7a764e0f06305f61b3b44ea
affe90d1fa9a93b3e2a48009ef80634e9de8428640f5d673e85b002a86399982

@prefix live: <https://lambdasistemi.github.io/cardano-tx-tools/proof/live#> .

# Live mainnet UTxO snapshot for network_compliance.
# Source: cardano-cli conway query utxo --mainnet
# Tip observed before snapshot: block 13467438, slot 188217701.
[] a live:CurrentUtxo ;
  live:txId "44454ed0def64621ef645958830f599b488b699b28e3797cc37c4f4dd1463a79" ;
  live:index 1 ;
  live:lovelace 2000000 ;
  live:usdm 0 .

[] a live:CurrentUtxo ;
  live:txId "68a1277af23755376967e788752c603044f45ea0d99220b3b5dfc7d617642b6b" ;
  live:index 1 ;
  live:lovelace 2306000 ;
  live:usdm 5011215241 .

[] a live:CurrentUtxo ;
  live:txId "affe90d1fa9a93b3e2a48009ef80634e9de8428640f5d673e85b002a86399982" ;
  live:index 0 ;
  live:lovelace 120299272 ;
  live:usdm 1349523953 .

[] a live:CurrentUtxo ;
  live:txId "cda0126e9ea7b336bbb338d2bfc7622a41b584e3bebc33c9c320e8895b9bc082" ;
  live:index 1 ;
  live:lovelace 2306000 ;
  live:usdm 10439974 .

[] a live:CurrentUtxo ;
  live:txId "cda0126e9ea7b336bbb338d2bfc7622a41b584e3bebc33c9c320e8895b9bc082" ;
  live:index 2 ;
  live:lovelace 2306000 ;
  live:usdm 10439524 .

Report Queries

Every query linked below runs against the same 85-transaction lattice. The tree is grouped by the question a reader is trying to answer first.

To reproduce the graph and execute the queries locally, use the Run the report tutorial. The Blockfrost provider page lists every external API shape used before the local graph and query stages. Each query page also contains a copyable command that runs just that query.

The query pages are listed in the site navigation under this report, grouped by boundary shape, terminal state, USDM movement, swaps, and supporting transaction-body checks.