arc-verify 0.8.0

• Receipt 1.9.0 names a third provider: a swap on Arc through Circle's App Kit
  Swap (Circle's swap adapter on Arc, the plan signed by Circle's Stablecoin
  Service). Its quote's source is CIRCLE_STABLECOIN_SERVICE, and Ryntra's fee
  is Circle's custom fee: mechanism CIRCLE_APP_KIT_CUSTOM_FEE, landing
SAME_TRANSACTION. The person pays the whole fee; Circle's fee collector
  pays nine tenths of it to Ryntra's fee address and one tenth to Arc in the
  same transaction — actual is what reached Ryntra, protocolShare what
  reached Arc. Circle's own 0.02 % is swap.providerFee.
• ryntraFee.feeClass states the class the rate came from (MEME,
  TRENDING, MAJOR, STABLE, AS_NOW), on swaps that carry it.
• A Circle receipt states one more limitation,
  A_TENTH_OF_RYNTRA_FEE_GOES_TO_ARC. Every 1.9.0 receipt through KyberSwap
  or Relay reads and verifies as before.
• A token whose symbol is an official asset's (USDC, EURC, cirBTC, WETH) at
  another address on Arc Mainnet is said to be «not the real one» in the
  verifier's checks; the receipt keeps the symbol its contract states. The
  verifier matches the exact symbol only — a look-alike spelling (another
  alphabet's letter, a prefix or suffix) is not marked by it.
• The receipt stays 1.9.0 with the new values added, so a verifier older than
  0.8.0 refuses a Circle receipt as malformed: read Circle receipts with 0.8.0
  or newer.

arc-verify 0.7.0 — returned app fee verification

• Verify KyberSwap receipts when the signing wallet also receives the app
  fee. Wallet amounts remain net: an input fee returned to that wallet is
  accounted for separately, and an output fee is separated from the swap's
  minimum received amount.
• Match the fee against the pinned router's transaction calldata, its Fee
  event and an exact token transfer. Missing, conflicting or ambiguous
  evidence does not become a verified fee.
• Include the relevant calldata and fee event in agreement checks between
  RPC responses. Full receipts and their public summaries use the same fee
  proof, including when the signed minimum is stricter than the quoted cap.
• Receipt schema 1.9.0 remains compatible. No signing, fee-rate change or
  transaction submission is part of this verifier.

arc-verify 0.6.0 — a swap through Relay

• Receipt 1.9.0 names a second provider: a swap on Arc through Relay (Relay's
  approval proxy and router, the swap itself through 0x's Settler). Its
  quote's source is RELAY_QUOTE_V2, and Ryntra's fee is Relay's app fee:
  mechanism RELAY_APP_FEE, landing PROVIDER_BALANCE, state
ACCRUED_AT_PROVIDER when Relay's own record of the swap says it credited
  it. What Relay itself took is a line of its own, swap.providerFee, absent
  when the provider takes nothing. Every 1.9.0 receipt through KyberSwap reads
  and verifies as before.
• checkAgainstArc holds a Relay swap to everything the chain shows — the
  contract called, what left and what reached the signing wallet, the signed
  floor, the network fee — and states Ryntra's fee as NOT_RECORDED: kept by
  the provider and credited off-chain, there is no Transfer of it in the
  transaction to check. It is never read as a missing Transfer.
• The public summary of a 1.9.0 swap says where Ryntra's fee landed
  (ryntraFeeLanding) and what the provider's own fee was
  (providerFeeQuoted).

v0.5.0 — swap receipts 1.9.0

• Receipt 1.9.0: a swap on Arc through an aggregator's router. It records
  what left the wallet and what reached it, each read from the swap's own
  Transfer events, the quote at signing beside them — what was expected, the
  floor the router enforced, the price impact and the pools — and Ryntra's fee
  as its own line: the rate, the side it was taken from, what was quoted and
  what the Transfer to Ryntra in the same transaction actually carried. Sealed
  under its own hash domain, ryntra:swap-route-receipt:1.9.0; it ships as
  schema/swap-receipt.schema.json.
• checkAgainstArc reads a 1.9.0 swap back from Arc: the router it names was
  called, no native value was attached, what left and what arrived in the
  signing wallet are the recorded amounts, at least the signed floor arrived,
  Ryntra's fee is a Transfer of exactly the recorded amount in the same
  transaction, and the network fee is the one recorded. From the public
  summary the same checks run without a wallet address.
• A 1.9.0 receipt that itself records Ryntra's fee as not collected is
  NOT_RECORDED on that check, never contradicted by the missing Transfer;
  its effects' feeAmount (the provider's own fee) is never read as the
  network fee.
• Nothing that 1.0.0–1.8.0 receipts verify changes.

v0.4.0 — route receipts 1.8.0

• Receipt 1.8.0: a route across networks on any rail the Ryntra bridge offers
  — Relay, Across, or Circle's bridge with the integrator's fee. It records
  what left on one network and what arrived on the other, each read from its
  own chain (a network Ryntra does not read is marked as reported by the
  provider), the quote at signing beside the actual amounts, and the
  integrator's fee as its own line: the rate, how it is collected, what was
  quoted and what was actually collected, and where that was read. Sealed
  under its own hash domain, ryntra:bridge-route-receipt:1.8.0; it ships as
  schema/route-receipt.schema.json.
• A route receipt answers to its own id, both seals, the transaction on Arc
  and both sides' transactions; publicSummary names the rail and the fee's
  state and never a wallet address.
• Nothing that 1.0.0–1.7.0 receipts verify changes.

v0.3.1 — the package names its release

The package names its release

• The hash domains of every receipt version — the received-payment receipt (1.6.0) and the bridge receipt (1.7.0) among them — and the function that picks a receipt's domain by its schema version now live beside the canonical serializer in lib/guard/canonical.ts. lib/guard/payout-canonical.ts re-exports them unchanged: no receipt hashes differently, and nothing a receipt verifies changes.
• The package's version names this release; 0.2.0 and 0.3.0 were tagged while it still said 0.1.0.

v0.3.0 — a CCTP transfer into or out of Arc as a receipt anyone can check

A transfer into or out of Arc through Circle's CCTP is a receipt anyone can check

Receipt 1.7.0 records a transfer between Arc and another network through Circle's CCTP: the burn on one network, Circle's attested message and the mint on the other, the amount sent, the amount received and the fee, each read from its own chain and sealed under its own hash domain, so it can never be read as a transfer or a payout. It ships as schema/bridge-receipt.schema.json. checkSeal recomputes both seals, and publicSummary gives the verifier's projection with both transactions and without a wallet address. The command line recomputes the seals and asks the verifier; it does not read the two networks back itself yet, so a bridge receipt stops at INCOMPLETE with the reason stated. Network-free tests cover the seals, the references and the summary.

v0.2.0 — the received-payment receipt

• @ryntra/arc-verify reads the received-payment receipt (receipt schema 1.6.0).
• The Arc Mainnet registry names the operator's switch as the whole gate for sends.

v0.1.0 — check a Ryntra settlement receipt yourself

• @ryntra/arc-verify 0.1.0, the first release: check a Ryntra settlement
  receipt yourself.
  • The receipt schema as JSON Schema 2020-12, generated from the schema the
    product validates with.
  • The canonical serialization and both seals — the receipt hash under its
    schema version's domain and the integrity hash over it — from the modules
    the product seals with.
  • The receipt as a document: its references, its chain, both seals
    recomputed, the public summary a stranger may see. Ryntra's receipt
    verifier route imports them from this module.
  • One transaction read from Arc's published JSON-RPC endpoints, compared
    across two of them, and every fact of a transfer, payout or USDC/EURC
    exchange receipt held against it: status, token contract, amounts, the
    wallets a payout names, block, network fee, total debit, time.
  • The arc-verify command line: CONFIRMED, CONTRADICTED or
    INCOMPLETE, with exit status 0, 1 or 2.
  • Network-free tests over complete receipts sealed with the product's own
    functions.