fix(aptos): Enforce address hex representation length to 32 bytes except special address#4730
Open
sergei-boiko-trustwallet wants to merge 3 commits intomasterfrom
Open
fix(aptos): Enforce address hex representation length to 32 bytes except special address#4730sergei-boiko-trustwallet wants to merge 3 commits intomasterfrom
sergei-boiko-trustwallet wants to merge 3 commits intomasterfrom
Conversation
…ept special address
Contributor
There was a problem hiding this comment.
Pull request overview
This PR standardizes Aptos address handling across tw_aptos by introducing/propagating a custom Address type with stricter parsing and normalized formatting rules (full 32-byte hex for most addresses; short form only for special 0x0..=0xa).
Changes:
- Implemented stricter Aptos
Addressparsing/formatting/serialization rules, including special-address short form handling. - Propagated the new
Addresstype through transaction building/signing and related modules (NFT, liquid staking, move package helpers). - Updated Aptos tests and golden JSON fixtures to reflect enforced 32-byte hex formatting.
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| rust/chains/tw_aptos/src/address.rs | Adds strict address parsing rules + special-address formatting and custom Serialize. |
| rust/chains/tw_aptos/src/transaction.rs | Switches raw transaction sender from AccountAddress to Address and updates JSON output formatting. |
| rust/chains/tw_aptos/src/transaction_payload.rs | Parses Move address arguments via the new Address parser (then converts to AccountAddress). |
| rust/chains/tw_aptos/src/transaction_builder.rs | Updates builder/factory APIs to accept/store Address consistently. |
| rust/chains/tw_aptos/src/signer.rs | Passes Address directly into the transaction builder. |
| rust/chains/tw_aptos/src/compiler.rs | Passes Address directly into the transaction builder for compilation paths. |
| rust/chains/tw_aptos/src/nft.rs | Migrates NFT ops address fields/serialization to Address + new string formatting. |
| rust/chains/tw_aptos/src/liquid_staking.rs | Migrates liquid staking addresses to Address, converting to inner AccountAddress only where required by Move types. |
| rust/chains/tw_aptos/src/aptos_move_packages.rs | Updates Move package helper APIs to take Address and uses normalized string formatting in JSON args. |
| rust/chains/tw_aptos/src/aptos_move_types.rs | Removes now-unneeded From<&...> impls after refactor. |
| rust/chains/tw_aptos/tests/signer.rs | Updates test vectors to use enforced 32-byte hex formatting and new Address type. |
| rust/tw_tests/tests/chains/aptos/aptos_address.rs | Expands normalization/valid/invalid coverage for special vs non-special addresses and strict prefix/length rules. |
| rust/tw_tests/tests/chains/aptos/test_cases.rs | Updates golden JSON fixture addresses to include required leading zero. |
| rust/coverage.stats | Updates coverage baseline. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Binary size comparison➡️ aarch64-apple-ios: - 14.34 MB
+ 14.34 MB -2 KB➡️ aarch64-apple-ios-sim: - 14.34 MB
+ 14.34 MB -1 KB➡️ aarch64-linux-android: - 18.77 MB
+ 18.77 MB -3 KB➡️ armv7-linux-androideabi: - 16.20 MB
+ 16.20 MB -2 KB➡️ wasm32-unknown-emscripten: - 13.68 MB
+ 13.68 MB +1 KB |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Aptos — Stricter Address Format
The Aptos address format is now strictly validated to conform with the official Aptos address specification.
Why this change matters
Aptos addresses are 32 bytes long, while Ethereum addresses are 20 bytes. Before this fix, Trust Wallet Core accepted Aptos addresses without leading zeros — e.g.
0x7968dab…3f30(63 hex chars).This meant a 20-byte Ethereum address could be silently accepted as a valid Aptos address by prepending 12 zero bytes (24 leading hex zeros).
A user could therefore accidentally send Aptos funds to what looks like an Aptos address, but is really an Ethereum address with padded zeros — funds that would be permanently lost with no way to recover them.
Enforcing the full 32-byte (64 hex char) representation closes this attack surface.
Breaking change 1 — Address input format
Any Aptos address passed to the library (as
sender,to,auth_key,receiver,creator,smart_contract_address,metadata_address, etc. inSigningInputor related messages) must now be one of:0x0through0xa(short form, exactly 3 characters including the0xprefix).0xprefix followed by exactly 64 hex characters (no more, no less). All leading zeros must be present.Previously, the
0xprefix was optional and addresses shorter than 64 hex chars were silently accepted. Both of these are now rejected.0x07968dab936c1bad187c60ce4082f307d030d780e91e694ae03aef16aba73f300x7968dab936c1bad187c60ce4082f307d030d780e91e694ae03aef16aba73f307968dab936c1bad187c60ce4082f307d030d780e91e694ae03aef16aba73f300xprefix)0x10xb0xbis not a special address)Action required: Ensure all Aptos addresses your app reads from user input, QR codes, deep links, or external APIs include the
0xprefix and the full 64 hex characters with leading zeros before passing them to Trust Wallet Core.Breaking change 2 — Address display output
Addresses returned by Trust Wallet Core (e.g. from key derivation,
TWAnyAddress, JSON signing output) will now always include leading zeros, producing a full 64 hex character address.0x7968dab936c1bad187c60ce4082f307d030d780e91e694ae03aef16aba73f300x07968dab936c1bad187c60ce4082f307d030d780e91e694ae03aef16aba73f30Special addresses (
0x0–0xa) are not affected and continue to be displayed in their short form.Action required: Update any hardcoded address strings, UI snapshots, or test fixtures that rely on the old trimmed representation. To automatically re-derive and update all stored Aptos addresses in a
TWStoredKeywallet, call:This will re-generate the correct 64-char address for every Aptos account in the keystore without requiring the user to re-import their wallet.
Breaking change 3 — Blind signing (
SigningInput.any_encoded)The
any_encodedfield inSigningInputis used for smart-contract and dApp blind-signing flows. The raw hex-encoded transaction insideany_encodedmay contain embedded Aptos addresses. Those addresses are now validated with the same strict rules above.If a dApp constructs a transaction that contains a short-form address (e.g.
0x7968dab…with only 63 hex chars), the signing request will fail and return an error instead of producing a signature.Impact: Some dApps that generate transactions with non-padded addresses may stop working for Trust Wallet users until the dApp is updated to emit fully-padded 64-char Aptos addresses.
Action required (dApp integrators): Ensure all Aptos addresses embedded in serialised transactions passed via
any_encodedconform to the new format (64 hex chars with0xprefix, or a valid special address0x0–0xa).