Query 18 - Beneficiary USDM Payments

Result

This table is the CSV result produced by Apache Jena over the state-audit graph. ADA quantities are decimal ADA; USDM quantities are decimal USDM.

paymentTxId	outputIndex	payeeLabel	payeeAddress	ada	usdm	vendorsPaidViaPayee
affe90d1fa9a93b3e2a48009ef80634e9de8428640f5d673e85b002a86399982	1	amaru.cag-payee	addr1q8qrds2nnx7clx3kcpp2l0eu45twmdcahsfu9m0xcwy59j6xz3vs0hnfaz9nhje8z34kfnds4jyk7hs6dnrag6e2lfgqtyf4rl	1.189560	400000.000000	amaru.antithesis, amaru.castellum
c150d5c5c67658c8f2a3bc24e16a4852257d46a03224257ac990fcca6f6fde78	1	amaru.cag-payee	addr1q8qrds2nnx7clx3kcpp2l0eu45twmdcahsfu9m0xcwy59j6xz3vs0hnfaz9nhje8z34kfnds4jyk7hs6dnrag6e2lfgqtyf4rl	1.189560	18750.000000	amaru.antithesis, amaru.castellum

Total USDM paid to the CAG payee bridge:

400,000.000000 + 18,750.000000 = 418,750.000000

What

This query lists every USDM output paid to the configured CAG payee bridge during the state-audit interval. It is the payment side of Query 17's accounting equation.

Why

The remaining USDM is only meaningful if the outgoing payments are also explicit. Query 18 shows that the graph has two CAG-payee USDM outputs: one for 400,000 USDM and one for 18,750 USDM. Their sum is the 418,750,000,000 base-unit beneficiary payment total used in Query 17.

The vendorsPaidViaPayee column reports the vendor entities declared as using the CAG bridge. It is bridge configuration, not a per-output amount split; the graph proves the payee output amount and address.

Diagram

flowchart LR
  txs[Transactions]
  outputs[USDM outputs]
  cag[CAG payee bridge]
  vendors[Declared vendors paid via CAG]
  table[Payment rows]

  txs --> outputs
  outputs --> cag
  cag --> table
  vendors --> table

How

The query first resolves amaru.cag-payee to its bech32 address from the rules. It then scans every transaction output at that address and keeps only outputs carrying the pinned USDM asset id.

The payment rows are grouped by transaction id and output index, so the result is one row per ledger output. A separate optional join gathers the vendor labels that declare cardano:paidVia that same payee bridge.

Run

From the repository root, run this query through the tutorial setup script:

bash docs/may-2026-amaru-lattice/setup.sh \
  docs/may-2026-amaru-lattice/treasury-usdm-movement/18-beneficiary-usdm-payments.rq

SPARQL

PREFIX cardano: <https://lambdasistemi.github.io/cardano-knowledge-maps/vocab/cardano#>
PREFIX rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs:    <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd:     <http://www.w3.org/2001/XMLSchema#>

# USDM outputs paid to the configured CAG payee bridge.
#
# Query 17 uses this as the outgoing-payment term of the accounting equation.
# This detail query keeps one row per ledger output so the "beneficiary
# payments" aggregate can be audited transaction-by-transaction.
#
# The final column lists vendors declared as paid via that bridge. It is
# deliberately not used to split the amount: the graph can prove the
# payee output amount, while per-invoice attribution requires metadata
# or operator labels beyond the payment address itself.
SELECT ?paymentTxId ?outputIndex ?payeeLabel ?payeeAddress
       ((xsd:decimal(?lovelace) / 1000000) AS ?ada)
       ((xsd:decimal(?usdmRaw) / 1000000) AS ?usdm)
       (GROUP_CONCAT(DISTINCT ?vendorLabel; separator=", ") AS ?vendorsPaidViaPayee)
WHERE {
  {
    # Inner query: find actual ledger outputs to the CAG payee address that
    # carry the pinned USDM asset. The outer query adds bridge/vendor context.
    SELECT ?paymentTxId ?outputIndex ?payeeLabel ?payeeAddress ?lovelace (SUM(?qty) AS ?usdmRaw)
    WHERE {
      # Pin by policy+asset hex, not by ticker, so this cannot accidentally
      # match another token named USDM.
      VALUES ?usdmAssetId {
        "c48cbb3d5e57ed56e276bc45f99ab39abe94e6cd7ac39fb402da47ad0014df105553444d"
      }

      # Resolve the payee bridge through rules.yaml. This lets the query name
      # the semantic role while still matching the concrete bech32 address.
      {
        SELECT DISTINCT ?payeeLabel ?payeeAddress
        WHERE {
          ?payee rdfs:label ?payeeLabel ;
                 cardano:bech32 ?payeeAddress .
          VALUES ?payeeLabel { "amaru.cag-payee" }
        }
      }

      ?paymentTx cardano:hasTxId/cardano:bytesHex ?paymentTxId ;
                 cardano:hasOutput ?out .
      ?out cardano:hasIndex ?outputIndex ;
           cardano:atAddress/cardano:bech32 ?payeeAddress ;
           cardano:lovelace ?lovelace ;
           cardano:hasAssetValue/rdf:rest*/rdf:first ?asset .
      ?asset cardano:hasIdentifier/cardano:bytesHex ?usdmAssetId ;
             cardano:quantity ?qty .
    }

    # Keep output index in the grouping. Two outputs in the same transaction
    # are separate ledger facts and should not collapse into one row.
    GROUP BY ?paymentTxId ?outputIndex ?payeeLabel ?payeeAddress ?lovelace
  }

  # Optional metadata/context join. This does not prove a per-output invoice
  # split; it only reports which configured vendor entities declare that they
  # are paid through this bridge label.
  OPTIONAL {
    ?vendor rdfs:label ?vendorLabel ;
            cardano:paidVia ?bridge .
    ?bridge rdfs:label ?payeeLabel .
  }
}
GROUP BY ?paymentTxId ?outputIndex ?payeeLabel ?payeeAddress ?lovelace ?usdmRaw
ORDER BY ?paymentTxId ?outputIndex