Custom transaction extensions cannot be marked as authorization extensions
@DenzelPenzel is already working on this.
Since Sep 12, 2026.
- Dominant language
- Rust
- Stars
- 489
- Forks
- 293
- Avg merge
- 18h 35m
- Merged PRs (30d)
- 3
Description
Context
DefaultTransactionExtensions lets callers supply metadata-encoded values for
chain-specific transaction extensions that Subxt has no typed support for, via
DefaultExtrinsicParamsBuilder::custom_extension.
Its is_authorization_extension implementation forwards only to the known typed
extensions:
fn is_authorization_extension(&self, name: &str) -> bool {
frame_decode::extrinsics::TransactionExtensions::is_authorization_extension(
&self.known,
name,
)
}
So a chain-specific extension supplied through custom_extension always reports
false, even if that extension authorizes the transaction.
Why it matters
In V5, frame-decode excludes the value and implicit bytes of the last
authorization extension and of every extension before it from the signer
payload. If a chain declares its own authorization extension and a user supplies
it via custom_extension, Subxt would sign over bytes the runtime excludes,
producing a signer payload the runtime will not agree with.
VerifySignature (VerifyMultiSignature) is currently the only authorization
extension Subxt knows about, so this is latent rather than an active bug, and
custom_extension documents custom authorization extensions as unsupported.
Raised in review of #2273:
https://github.com/paritytech/subxt/pull/2273#discussion_r3904192456
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.