v1 covenant transaction rejected on testnet-10: "script units exceeded" even with computeBudget set

[jeffsiegel1965]

Environment

• Network: kaspatest testnet-10 (rpc api-tn10.kaspa.org)
• Tooling: Python SDK kaspa 2.0.1 (PyPI) + Rust kaspa-wasm 0.13.0
• Date: July 2026

What I'm trying to do

Deploy a simple timelock covenant on testnet-10:

1. Spend a v0 P2PK UTXO (40.928 KAS, Schnorr-signed)
2. Create a version-1 transaction with computeBudget = 65535 on the input
3. Output[0]: 1,000,000 sompi → P2SH-wrapped redeem script containing OP_CHECKLOCKTIMEVERIFY + Schnorr pubkey check, with CovenantBinding attached and covenant_id = blake2b(outpoint || authorized_outputs)
4. Output[1]: fee; output[2]: change
5. Sign with BIP-340 Schnorr via sign_transaction()
6. Broadcast via /transactions

The JSON we send includes "computeBudget": 65535 on each input, version: 1, sigOpCount: 1, Schnorr signature script.

What happens

The node consistently rejects with:

RPC Server (remote error) -> Rejected transaction <txid>:
failed to verify the signature script: script units exceeded the amount committed
in the input: used=100000, limit=9999

The value 9999 matches the free-script-unit allowance on the underlying v0 UTXO. The 100,000 figure is roughly the cost of verifying one Schnorr signature. The computeBudget = 65535 that I set on the v1 input is completely ignored.

What I've tried

#	Change	Result
1	Default compute_budget	rejected — same error
2	Smaller outputs (5 KAS total)	rejected
3	Split funds into many small UTXOs	rejected
4	Manually inject computeBudget: 200000 into the signed JSON	rejected
5	Monkey-patch Transaction.to_dict() in the Python SDK to serialize compute_budget	rejected — same error
6	sig_op_count = 0 on input (v1 covenant convention)	rejected

The transaction signs successfully and produces a valid txid locally; the problem is at consensus validation.

Questions

1. Field semantics: Is computeBudget the wrong field for raising the signature-verification limit? The error message says "the amount committed in the input" — that phrasing suggests the budget is derived from the UTXO itself (committed at spend time), not from the transaction that spends it. If so, what is the correct field to raise it?

2. v0 → v1 bootstrap: Can a v1 covenant transaction actually spend a v0 UTXO? Or does the protocol require that covenant transactions only spend UTXOs that were themselves created by v1 (covenant-aware) transactions? If a bootstrap path exists, I'd love to see it.

3. Signing scheme: Schnorr verification costs ~100K script units. If the input-side budget truly cannot exceed the v0 UTXO's 9999, does that mean covenant-input signature verification needs a cheaper scheme (ECDSA, or something else), or is the budget supposed to be raised via a different mechanism entirely?

4. Reference deployment: Has anyone successfully deployed any covenant on testnet-10 (or mainnet)? A single known-good txid would let me diff the structure byte-for-byte against what I'm sending.

What I've verified locally

• Covenant-id hash (blake2b(outpoint ‖ authorized_outputs)) matches the Rust SDK's own test vector.
• Transaction signs; local txid computation matches node-side rejection txid.
• Wallet side (getUtxosByAddresses, sendTransaction) is fine — the same wallet can send normal v0 payments without issue.

Repo references I checked

• wip/covenants — no working example found
• Consensus code under consensus/core/src/tx/ — I haven't been able to pinpoint where the 9999 limit is read without more time tracing through the script-unit accounting.

---

Happy to provide the signed tx hex / full JSON if that helps. Thanks for any pointer.

---

Posting recipe (for when user has 2 min)

# 1) install gh if not present (Ubuntu/Debian):
#    sudo mkdir -p -m 755 /etc/apt/keyrings
#    wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg \
#      | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null
#    echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] \
#      https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list
#    sudo apt update && sudo apt install gh -y

# 2) auth
gh auth login   # paste token, choose HTTPS, default everything

# 3) post
cd /home/jeff-siegel/.hermes/projects/kaspa-suite
gh issue create \
  --repo kaspanet/rusty-kaspa \
  --title "v1 covenant transaction rejected on testnet-10: \"script units exceeded\" even with computeBudget set" \
  --label question \

[Knitser]

hit exactly this wall a few weeks ago — the error is misleading and the numbers decode it. Answers to your four questions, then the fix.

What used=100000, limit=9999 actually means

Post-Toccata (v1) transactions replace the per-input sigOpCount: u8 with a per-input computeBudget: u16. 1 budget unit = 100 grams = 10,000 script units.
Every input gets a free allowance of 10,000 − 1 = 9,999 script units (free_script_units_per_input() in consensus/core/src/mass/units.rs). That's your limit=9999: the node saw your input with an effective budget of 0.
One Schnorr OpCheckSig costs mass_per_sig_op (1000 grams) × 100 units/gram = 100,000 script units. That's your used=100000. Witness bytes you push are charged 1:1 on top.

1. Is computeBudget the right field? Yes — and it's committed by the spending input, not derived from the UTXO. The catch: for v1 transactions the field is part of the sighash (consensus/core/src/hashing/tx.rs writes it whenever version >= 1). So it must be set before signing; injecting it into the JSON after sign_transaction() breaks the signature, and setting it on an object whose serializer doesn't know the field means it never reaches the wire. That's what's happening to you: the PyPI kaspa 2.0.1 / kaspa-wasm 0.13.0 wire formats predate Toccata — they serialize sigOpCount and silently drop computeBudget, so the node deserializes budget 0 and you get limit=9999 no matter what you set locally (your monkey-patch results table is consistent with this). You need a toolchain built against the post-Toccata consensus crates (a rusty-kaspa git rev at/after the fork) rather than the frozen SDK releases.

2. Can a v1 tx spend a v0 UTXO? Yes — that's the normal bootstrap path; there is no "covenant-aware UTXOs only" rule. Every covenant on TN10 starts from a plain faucet UTXO. The 9999 is not a property of the old UTXO.

3. Does Schnorr need replacing? No. Commit budget ≥ 10 on any input that does one signature check (10 × 10,000 covers the 100,000). Note the committed budget is charged as compute mass whether the script uses it or not, so the fee has to scale with it — commit ~10–20 per input, not 65535, or the fee wall gets you next. Also don't forget the plain fee/change input if you have one: it needs its own budget ≥ 10 for its own CheckSig — that one is the classic silent killer because it "never needed anything" pre-Toccata. (For reference, rusty-kaspa's own consensus-core::sign() stamps ComputeBudget(10) on every input of a v1 tx.)

4. Known-good reference deployment — here are two accepted TN10 txids you can diff byte-for-byte:

genesis (P2SH-committed contract + CovenantBinding, id = blake2b(outpoint ‖ authorized outputs) — same construction you verified): a9a7df1a71307c0518aa001920b42b9afecbaa503d61c279c08e45ee6bfc8bdb
the spend that reveals the program (witness = push(pk) ++ push(sig) ++ push(selector) ++ push(program), both inputs committing budget): 051288013eecf1cc3f890005236b96567f743423390a540650af65f50c4288b3
You can replay the second one through the real script engine with a curl (opcode-by-opcode trace, no setup):

curl -s https://kascov.io/data/testnet-10/debug/051288013eecf1cc3f890005236b96567f743423390a540650af65f50c4288b3
and the coin's whole lifecycle is browsable at https://kascov.io/testnet-10/c/b4ade48e3ad1eda5cfab75a8a9d757abf7faed20a557d274e3ca1fcacd990410

I wrote the full tested path up (keygen → faucet → deploy → spend → replay, including this exact trap): https://kascov.io/guide — the tx-building code behind it is open (MIT) at https://github.com/Knitser/kascov (kascov-labkit, see build_constrained_spend for the two-input budget/fee math). Happy to help debug your specific tx hex if you post it.

[IzioDev]

Hi, do you have a minimal repro case please?

You also can try this version (on testnet-10 only) of the SDK which supports ComputeCommit and should solve your issue (on which you can workaround but it shouldn't be the case): #1074

[Knitser]

import kaspa

ti = kaspa.TransactionInput.from_dict({
    "previousOutpoint": {"transactionId": "aa"*32, "index": 0},
    "signatureScript": "", "sequence": 0, "sigOpCount": 1,
    "computeBudget": 10,
})
print(ti.compute_budget)     # 10 — set in memory
print(ti.to_dict().keys())   # ['previousOutpoint', 'sequence', 'sigOpCount', 'signatureScript', 'utxo']
                             #  computeBudget is silently dropped on serialization

The field is carried in memory but dropped by the dict/JSON representation, so anything round-tripping through it submits an effective budget of 0 → used=100000, limit=9999, matching the OP's results. (Adjacent footgun: compute_budget snake_case in from_dict is silently ignored.)

And I can confirm #1074 fixes it at exactly that layer — on tmp/generator-changes, SerializableTransactionInput carries compute_budget in both wire shapes (version-gated, from the new ComputeCommit model). Round-trip test against the branch:

let input: SerializableTransactionInput = serde_json::from_str(
    r#"{ ..., "sigOpCount": 1, "computeBudget": 10, ... }"#)?;
assert_eq!(input.compute_budget, 10);
let out = serde_json::to_string(&input)?;
assert!(out.contains("\"computeBudget\":10")); // passes on the branch ✓

$ cargo test -p kaspa-consensus-client --test compute_budget_roundtrip
test compute_budget_survives_json_roundtrip ... ok

[IzioDev]

Cool, @Knitser can you add a comment on the PR to mention this fixes your bug, in a concise way? Thanks!

We'll keep this issue open until the PR is merged then.

[jeffsiegel1965]

Awesome thx!

…

On Mon, Jul 13, 2026 at 12:09 PM Romain Billot ***@***.***> wrote: *IzioDev* left a comment (kaspanet/rusty-kaspa#1073) <#1073 (comment)> Cool, @Knitser <https://github.com/Knitser> can you add a comment on the PR to mention this fixes your bug, in a concise way? Thanks! We'll keep this issue open until the PR is merged then. — Reply to this email directly, view it on GitHub <#1073?email_source=notifications&email_token=CGXVVXGG7GCONE4ELS3LAJL5EUCSPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJWGAYDENBQG43KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4960024076>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CGXVVXBAAJBASWRUD3YPZDL5EUCSPAVCNFSNUABFKJSXA33TNF2G64TZHM2TCNBZG44TCOJRHNEXG43VMU5TIOBTG44DAMBUGUY2C5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jeffsiegel1965]

Gents, please take a look at my wallet project

https://github.com/jeffsiegel1965/vida

Comments/suggestions appreciated

I think this issue can be closed. Thx