feat(platform)!: update PlatformAddress encoding and HRP constants#3059
Conversation
📝 WalkthroughWalkthroughSingle-file update to Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
QuantumExplorer
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/rs-dpp/src/address_funds/platform_address.rs`:
- Around line 88-91: The change of HRP constants PLATFORM_HRP_MAINNET and
PLATFORM_HRP_TESTNET to "dash"/"tdash" breaks decoding of existing bech32m
addresses using "evo"/"tevo"; either document this as a breaking change and
update the comment in wasm-dpp2's address.rs (the doc near from_bech32m_string)
to reflect the new HRPs, or restore backward compatibility by modifying the
from_bech32m_string decoding logic to accept both the new HRPs ("dash","tdash")
and the old HRPs ("evo","tevo") during a transition (detect HRP and normalize to
current constants), then add a clear comment noting the transitional behavior
and a TODO to remove legacy support later.
| /// Human-readable part for Platform addresses on mainnet (DIP-0018) | ||
| pub const PLATFORM_HRP_MAINNET: &str = "evo"; | ||
| pub const PLATFORM_HRP_MAINNET: &str = "dash"; | ||
| /// Human-readable part for Platform addresses on testnet/devnet/regtest (DIP-0018) | ||
| pub const PLATFORM_HRP_TESTNET: &str = "tevo"; | ||
| pub const PLATFORM_HRP_TESTNET: &str = "tdash"; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for old HRP values in the codebase
rg -n '"evo"' --type rust
rg -n '"tevo"' --type rust
rg -n "evo" --type rust | grep -i hrpRepository: dashpay/platform
Length of output: 461
🏁 Script executed:
# Look for bech32m-related functions and their implementations
rg -n "from_bech32m|to_bech32m|bech32" --type rust -B 2 -A 10 | head -100Repository: dashpay/platform
Length of output: 8650
🏁 Script executed:
# Search for the file containing these constants to understand context
cat -n packages/rs-dpp/src/address_funds/platform_address.rs | head -120Repository: dashpay/platform
Length of output: 5010
🏁 Script executed:
# Search for the from_bech32m_string function implementation
rg -n "from_bech32m_string" --type rust -B 2 -A 15Repository: dashpay/platform
Length of output: 26057
🏁 Script executed:
# Search for the complete PlatformAddress implementation with bech32m handling
rg -n "fn from_bech32m|impl.*PlatformAddress" --type rust -A 20 | grep -A 20 "from_bech32m"Repository: dashpay/platform
Length of output: 7646
🏁 Script executed:
# Search for any migration or backward compatibility handling for old HRP values
rg -n "evo|tevo" --type rust -B 3 -A 3 | grep -i "compat\|migrat\|deprecat\|old"Repository: dashpay/platform
Length of output: 491
🏁 Script executed:
# Check if there's a CHANGELOG or breaking changes documentation
find . -maxdepth 2 -type f \( -name "CHANGELOG*" -o -name "BREAKING*" -o -name "MIGRATION*" \) | head -10Repository: dashpay/platform
Length of output: 74
🏁 Script executed:
# Look at the wasm-dpp2 file to see the full comment context about accepting old HRPs
sed -n '285,300p' packages/wasm-dpp2/src/platform_address/address.rsRepository: dashpay/platform
Length of output: 693
Breaking change: HRP values updated with no backward compatibility.
Changing HRP from "evo"/"tevo" to "dash"/"tdash" is a confirmed user-facing breaking change. The implementation strictly rejects old HRP values; any existing bech32m-encoded addresses using the old HRPs will fail to decode.
Additionally, the documentation in packages/wasm-dpp2/src/platform_address/address.rs (line 293) is outdated—it still claims "Accepts addresses with either mainnet ("evo") or testnet ("tevo") HRP," but the actual implementation in from_bech32m_string only accepts the new HRPs and returns an error for old ones.
Recommendations:
- Document this as a breaking change in the PR/release notes
- Update the wasm-dpp2 comment to reflect the current HRP requirements
- If backward compatibility is needed, implement support for both old and new HRPs during a transition period
🤖 Prompt for AI Agents
In `@packages/rs-dpp/src/address_funds/platform_address.rs` around lines 88 - 91,
The change of HRP constants PLATFORM_HRP_MAINNET and PLATFORM_HRP_TESTNET to
"dash"/"tdash" breaks decoding of existing bech32m addresses using "evo"/"tevo";
either document this as a breaking change and update the comment in wasm-dpp2's
address.rs (the doc near from_bech32m_string) to reflect the new HRPs, or
restore backward compatibility by modifying the from_bech32m_string decoding
logic to accept both the new HRPs ("dash","tdash") and the old HRPs
("evo","tevo") during a transition (detect HRP and normalize to current
constants), then add a clear comment noting the transitional behavior and a TODO
to remove legacy support later.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
2 participants
Issue being fixed or feature implemented
Update the
PlatformAddressencoding to use the correct Human-Readable Parts (HRP) and type bytes for both user-facing and storage representations.What was done?
How Has This Been Tested?
All existing unit tests were updated and passed successfully, ensuring that the new HRP and type byte changes work as intended.
Breaking Changes
None, but this unbreaks a breaking change.
Checklist
Summary by CodeRabbit
New Features
Changes