TRON signature length is a byte count, not proof that a signature is valid or authorized. The current TIP-935 draft preserves a 65–68-byte compatibility window at named transaction boundaries. It does not impose a universal exact 65-byte rule, and this review does not establish that its proposed rules are active on Mainnet.
We reviewed the September 15 proposal as updated October 28, 2026, then checked its current text and one public transaction on November 3. Our original material includes a raw-data hash check, eight local length fixtures and five scalar-boundary fixtures. No private key, wallet, signature creation, node upgrade or transaction broadcast was used.
Table of Contents
Read the current draft rather than an isolated older comment
The official TIP-935 discussion remains labelled Draft in our saved source. Its current specification distinguishes deployment-time admission and query policies from governance-activated consensus behavior. Earlier discussion comments are part of the history; they should not silently replace the current normative text.
This distinction matters for signature length because the discussion includes earlier exact 65-byte suggestions. The saved current text instead retains 65 through 68 bytes inclusive for the specified boundaries, while preserving accepted transaction bytes. We are reporting that dated specification, not announcing a new enforcing release or recommending that readers modify their signatures.
The draft also retains High-S compatibility. Length, component bounds and a low-S signing recommendation are different ideas. A reader should not label every High-S value invalid merely because the proposal hardens other recovery checks. Our local work did not perform elliptic-curve recovery or certify a signature under either validation mode.
Our actual public transaction observation
We read one public Mainnet block through wallet/getnowblock at api.trongrid.io and selected the first returned transaction containing raw_data_hex and a signature array. Its block number was 87669202. The transaction identifier was ce42f6a73283a53722b877990b0f500cb2558eccaa8bb3c711d7a3f5459dfeb1. This is an observed record, not a hypothetical transfer or a claim of control over its sender.
The first supplied signature decoded to 65 bytes. We hashed the exact bytes from raw_data_hex with SHA-256 and obtained the same transaction identifier supplied by the provider. The check used the retained byte string rather than recreating raw_data from possibly reformatted JSON fields.
| Observed item | Result | Scope |
|---|---|---|
| Public block | 87669202 | One provider snapshot |
| First signature | 65 bytes | One signature in one record |
| SHA-256 of raw_data_hex | Matched provider txID | Identity-byte consistency |
| Recovered signer or permission threshold | Not tested | No authorization conclusion |
A successful hash comparison establishes a narrow correspondence between saved raw bytes and the supplied identifier. It does not independently validate the block, reconstruct every signature, prove the economic meaning of a transfer or establish whether a different payload would be admitted by a serving node.
Original signature length fixture matrix
Using the captured signature’s first 65 bytes as a local byte fixture, we constructed shortened or padded strings at eight sizes. The local gate tested only whether the length lay between 65 and 68 inclusive. These derived strings were never sent to a node and must not be treated as ready-to-broadcast transactions.
| Synthetic length, bytes | Our local gate output | Evidence class |
|---|---|---|
| 0 | Reject at this length gate | Local fixture only |
| 64 | Reject at this length gate | Local fixture only |
| 65 | Continue other checks | Local fixture only |
| 66 | Continue other checks | Local fixture only |
| 67 | Continue other checks | Local fixture only |
| 68 | Continue other checks | Local fixture only |
| 69 | Reject at this length gate | Local fixture only |
| 96 | Reject at this length gate | Local fixture only |
“Continue other checks” deliberately avoids the word valid. The model does not recover a public key, verify a digest, inspect a permission, enforce network state or evaluate every rule at a particular entry point. A correctly sized random string could reach this gate’s continuation branch while failing the real cryptographic checks.
The zero-length row represents a supplied empty signature fixture. It is not the same object as a transaction containing no signature entries. The draft preserves a separate unsigned-query behavior, so collapsing an empty list and an empty list element into one condition would lose a meaningful structural distinction.
Component bounds are another check, not a substitute
The current draft specifies nonzero r and s components smaller than the secp256k1 group order n before strict recovery proceeds. We tested the local integer range expression at 0, 1, n−1, n and n+1. Only 1 and n−1 passed that range gate. Those five fixtures verify boundary arithmetic in our reader, not recovery on the elliptic curve.
A complete verifier still needs the proper digest, recovery identifier, entry-specific encoding, curve checks and subsequent authorization rules. The source distinguishes transaction and witness wire aliases from the narrower TVM precompile inputs. This article does not use a transaction alias table to broaden a different entry point’s accepted input.
We also do not supply an attack transaction, a permission-changing workflow or a private-key recovery claim. The practical task is preserving evidence and identifying which check a statement describes. If a tool claims that length alone proves ownership or account access, its conclusion exceeds the checks shown here.
Why a matching txID does not justify trimming signature bytes
The draft explains that transaction identity is derived from serialized raw_data, while the block’s transaction commitment includes the signed transaction representation. Signature bytes can therefore change without changing that raw-data identity. Preserving an identifier does not mean every other commitment remains unchanged.
In our local fixtures, the raw_data_hex input remained constant, so its SHA-256 result stayed the same across the signature-length examples. Each derived signature also had its own byte fingerprint. We did not compute a real block Merkle root or call those fingerprints Merkle leaves; they are simply hashes of the fixture byte strings.
The safe record-preservation rule is to retain the original payload and label every derivative separately. Do not silently replace a 68-byte saved signature with its 65-byte prefix and then represent the file as the original signed record. A separate local display can show a length or prefix without rewriting the retained evidence.
Deployment, activation and historical replay differ
| Draft context | What the source distinguishes | What we did not establish |
|---|---|---|
| New transaction admission on upgraded software | Named length policy at deployment | That a particular public node deployed it |
| Auxiliary signature queries | Strict recovery independent of later governance activation | A successful query for our fixture |
| Consensus and TVM activation | Legacy in maintenance block H; strict from H+1 | A Mainnet activating block |
| Historical replay | Original applicable rules and transaction bytes | An independent archive replay |
A GitHub issue status, software deployment and active governance state are separate evidence items. The source’s target release label is not a current-node capability test. Likewise, a local helper returning success cannot certify that the same exact bytes will pass a query, broadcast, consensus and execution.
The block-witness path has another scope in the draft: its normalization rules do not authorize rewriting transaction signatures. Keep the field being discussed explicit. A block header’s witness signature, a transaction’s signature array and a TVM recovery input are not interchangeable just because all contain signature bytes.
How to repeat our read-only preservation check
- Save the primary draft URL and its status, creation date and update date. Identify which entry point and software stage the claim concerns.
- Read a public transaction from the intended network and preserve the original response. Our input came from one Mainnet getnowblock response.
- Decode the signature hex to bytes and count them. Do not count hex characters as bytes; two hex characters represent one byte.
- Hash the exact raw_data_hex bytes and compare with the supplied txID. A mismatch requires investigation, not an automatic rewrite.
- If creating local boundary fixtures, keep them in separate files and label the checks they perform. Do not broadcast them or infer cryptographic validity from a structural result.
Success is a retained source record, a reproducible byte count and a clearly bounded hash check. This procedure does not require signing, wallet connection or a paid service. Unavailable original bytes should remain an evidence gap; an explorer screenshot or a reconstructed JSON object cannot automatically replace them.
For context, use our TRONSCAN record-selection guide, transaction-ID verification method, and account-permission reading guide. Those cover broader navigation, raw-data identity and authorization state, respectively.
The Tronscan News home page organizes independent English education. AI assisted preparation. The primary draft, captured public block and thirteen local structural fixtures were checked November 3, 2026. This is a BlogPosting review of documented behavior and original local evidence, not a claim that TIP-935 launched today.
Frequently asked questions
Does the current draft reject every signature length above 65 bytes?
No. At its specified boundaries, the current text preserves 65–68 bytes. That is a draft rule, not our measurement of every serving node.
Does a 65-byte signature prove a valid signer?
No. Our actual record had that length, but we did not perform recovery or authorization verification.
Does TIP-935 require every High-S signature to fail?
The saved current draft explicitly preserves High-S compatibility. Do not substitute a low-S recommendation for its verification rules.
Can two different signature encodings share a txID?
The txID hashes raw_data. Changing signature bytes need not change that raw-data identity, but other commitments and validation outcomes can differ.
Were the shortened or padded fixtures broadcast?
No. All eight length fixtures and five scalar-boundary checks were local structural tests. No wallet, signature creation or transaction submission was used.
Leave a Reply