How does a Kaspa covenant script confirm a previous transaction is genuine?

A Kaspa covenant script confirms a previous transaction is genuine by requiring the spender to attach a full copy of it as witness data, then hashing that copy and checking it equals the transaction ID already stored in the spending input. A transaction ID in Kaspa is a hash — a short fingerprint produced from the full transaction data. When a covenant needs to inspect the coin's history, it cannot work from the hash alone; it needs the original data. The spender provides that data, and the script uses the same hashing algorithm that produced the transaction ID in the first place to verify the copy is authentic, not fabricated. This process is described in KIP-0017, which also notes that a reference implementation of the transaction ID hashing and encoding logic is available. For a beginner, the key takeaway is that Kaspa's covenant design lets scripts enforce spending rules based on verified history — no trusted third party needed, because the math does the confirming.