Verification of a signed receipt is two steps that get collapsed in conversation. Step one recomputes a digest over the payload bytes. Step two checks an Ed25519 signature against a public key [4]. Whether the scheme holds is decided entirely by which fields step one covers.
In ComputeLedger, according to its authors, the digest is `sha256Hex(canonicalizeToBytes(payload))`, and `publicKey` sits inside that payload rather than beside it [7][6]. The swap therefore dies at step one: a substituted key yields a different digest, the stored signature matches nothing, and `ledger verify` rejects the receipt before the signature code runs at all [8]. That early rejection is just the scope decision doing its job, a single control rather than a second one layered on top.
The failure this closes is the kind that survives review. A verifier that reads the key out of an envelope field and checks the signature against it is locally correct and passes every happy-path test [9]. It fails exactly one case: generate a fresh keypair, re-sign the same claim, submit. The authors say an internal security audit made them write that test before calling the feature done [9]. OWASP files this class under cryptographic failures rather than access control, because the primitive is fine and the scope is wrong [5].
Pinning the key answers one question: which key signed the bytes. It leaves the harder question untouched, namely whose key that is. A signature establishes that a specific byte string was signed by the holder of a specific private key, and nothing about whether that key is the one you meant to trust [10]. Putting it inside the hash removes the swap and leaves key distribution exactly where it was: you need the provider's public key over a channel that is not the receipt, plus an answer for what happens when it changes.
The load-bearing function in that expression is `canonicalizeToBytes`. There are two independently maintained implementations of the same receipt format, the npm CLI at 0.1.2 for Node 18+ and the PyPI CLI at 0.1.4 for Python 3.10+, and they now version independently instead of in lockstep [2]. That is two patch releases of drift between a signer and a verifier that different parties may be running [14]. For a Node-signed receipt to verify under the Python tool, both have to agree on field ordering and number formatting down to the byte. The write-up demonstrates key generation, a recorded receipt, and a ledger-integrity check against one binary [15]. Cross-implementation agreement is a separate exercise, and it is the one I would want published vectors for before treating a receipt as evidence in a billing dispute.
The demand argument rests on two neighbours: a multi-cloud job orchestrator at 10,463 GitHub stars and a CNCF cost-monitoring project at 6,670, both checked through the GitHub API on 2026-08-08, and neither signing a usage claim a stranger can check [12]. Added together that is 17,133 stars aimed at adjacent problems [13]. GitHub stars are a claim about someone else's workload too. They show that people want cost data. Whether any provider is willing to sign it is a separate question.
So for this format to be worth anything on your side, two things must be true that the code cannot supply: a provider willing to sign usage in it, and a key you obtained without asking the receipt for it. The dashboard problem the authors describe, one vendor's number on one vendor's stack with no third-party check [11], is a commercial problem. The field inside the hash is the part engineering can settle on its own.
