feat(sdk): support platform address state transitions in JS SDK #2931
Conversation
📝 WalkthroughWalkthroughAdds extensive WASM bindings, Rust-to-WASM conversions, JS facade methods, fee-strategy and signer utilities, settings parsing, broadcast/wait flows, platform-address input/output types, identity/address state-transition APIs, and many unit tests across wasm-dpp2, wasm-sdk, and js-evo-sdk. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant JS as JS AddressesFacade
participant WASM as WasmSdk
participant DPP as DPP Core
participant Net as Network/Node
rect rgba(220,235,255,0.6)
JS->>WASM: transfer(options)
WASM->>WASM: validate options, build inputs/outputs, resolve signer & fee strategy
WASM->>DPP: build AddressFundsTransferTransition
DPP-->>WASM: transition
WASM->>Net: broadcast_and_wait(transition, settings)
Net-->>WASM: Map<PlatformAddress, PlatformAddressInfo>
WASM-->>JS: return address infos Map
end
sequenceDiagram
autonumber
participant JS as JS AddressesFacade
participant WASM as WasmSdk
participant DPP as DPP Core
participant Net as Network/Node
rect rgba(230,255,230,0.6)
JS->>WASM: createIdentity(options)
WASM->>WASM: validate, extract identity & inputs, resolve signers
WASM->>DPP: put_with_address_funding(...)
DPP-->>WASM: state transition
WASM->>Net: broadcast_and_wait(...)
Net-->>WASM: created identity + address infos
WASM-->>JS: IdentityCreateFromAddressesResult
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (10)
packages/wasm-sdk/src/settings.rs (1)
231-238: Consider validatinguserFeeIncreaserange before casting.The TypeScript interface documents
userFeeIncreaseas 0-65535, but values outside this range passed from JS will silently truncate when cast tou16. Consider clamping or returning an error for out-of-range values.🔎 Proposed validation
// Parse userFeeIncrease if let Ok(fee_increase_js) = js_sys::Reflect::get(&settings_value, &JsValue::from_str("userFeeIncrease")) { if let Some(fee) = fee_increase_js.as_f64() { - put_settings.user_fee_increase = Some(fee as u16); + let clamped = fee.clamp(0.0, u16::MAX as f64) as u16; + put_settings.user_fee_increase = Some(clamped); } }packages/wasm-dpp2/tests/unit/AddressFundsTransfer.spec.mjs (1)
41-42: Skipped test suite noted.The
AddressFundsTransferTransitiontest suite is properly marked as skipped with a TODO comment. The test structure serves as good documentation for the expected API. Consider tracking this with an issue to ensure the implementation is completed.Would you like me to open an issue to track the
AddressFundsTransferTransitionWASM binding implementation?packages/wasm-dpp2/src/enums/withdrawal.rs (1)
15-50: LGTM with a note on potential refactoring.The manual
Deserializeimplementation correctly handles both string and numeric inputs. There's some logic duplication with theTryFrom<JsValue>implementation below (lines 72-106), but this is acceptable since they serve different purposes (serde deserialization vs. WASM binding conversion).If desired, the string-to-enum and number-to-enum logic could be extracted into helper methods to reduce duplication:
Optional refactor to reduce duplication
impl PoolingWasm { fn from_str_value(s: &str) -> Option<Self> { match s.to_lowercase().as_str() { "never" => Some(PoolingWasm::Never), "ifavailable" => Some(PoolingWasm::IfAvailable), "standard" => Some(PoolingWasm::Standard), _ => None, } } fn from_numeric_value(n: u64) -> Option<Self> { match n { 0 => Some(PoolingWasm::Never), 1 => Some(PoolingWasm::IfAvailable), 2 => Some(PoolingWasm::Standard), _ => None, } } }packages/wasm-sdk/src/state_transitions/broadcast.rs (1)
98-101: Same Debug format issue as wait_for_response.This has the same concern as
wait_for_response- the Debug format string may not be suitable for JavaScript consumers.packages/wasm-dpp2/src/identity_signer.rs (1)
66-68: Consider reusing Secp256k1 context.Creating a new
Secp256k1context for eachadd_keycall has minor overhead. For high-frequency key additions, consider caching the context. However, this is acceptable for typical usage patterns.packages/wasm-dpp2/src/platform_address/input_output.rs (2)
142-151: Potential precision loss when deserializing f64 to Credits.JavaScript's
Numbertype (f64) can only precisely represent integers up to 2^53. For larger credit amounts, the castvalue as Creditsmay silently lose precision. Consider adding a check or documenting that string format is required for amounts exceedingNumber.MAX_SAFE_INTEGER.🔎 Optional: Add precision check for large values
fn visit_f64<E>(self, value: f64) -> Result<Self::Value, E> where E: de::Error, { if value < 0.0 { Err(E::custom("credits cannot be negative")) + } else if value > 9007199254740992.0 { + // 2^53 - beyond this, f64 cannot represent all integers precisely + Err(E::custom("credits value too large for precise float representation, use string format")) } else { Ok(value as Credits) } }
325-395: Consider reordering: struct definition before itsDeserializeimpl.The
Deserializeimpl forPlatformAddressOutputWasm(lines 325-384) appears before the struct definition (lines 386-395). While valid Rust, placing the struct definition first improves readability.packages/wasm-sdk/src/state_transitions/addresses.rs (3)
466-470: Unnecessary.clone()on already-owned value.
output.address()returns an ownedPlatformAddressWasm, so.clone()is redundant before.into().🔎 Remove unnecessary clone
let change_output = parsed.change_output.map(|output| { - let address = output.address().clone().into(); + let address = output.address().into(); let amount = output.amount_value(); (address, amount) });
810-813: Consider moving imports to module level.While scoped imports inside functions are valid Rust, placing them at the module level (lines 1-26) is more conventional and allows the compiler to better optimize.
844-848: Same unnecessary.clone()pattern appears in multiple places.Lines 846, 1037, and 1045 have the same redundant
.clone().into()pattern. Consider removing.clone()calls whenaddress()already returns an owned value.Also applies to: 1034-1048
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (28)
packages/js-evo-sdk/src/addresses/facade.tspackages/js-evo-sdk/src/wasm.tspackages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-dpp2/src/enums/withdrawal.rspackages/wasm-dpp2/src/identity/model.rspackages/wasm-dpp2/src/identity_signer.rspackages/wasm-dpp2/src/lib.rspackages/wasm-dpp2/src/platform_address/address.rspackages/wasm-dpp2/src/platform_address/fee_strategy.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/state_transitions/base/state_transition.rspackages/wasm-dpp2/tests/unit/AddressFundsTransfer.spec.mjspackages/wasm-dpp2/tests/unit/IdentitySigner.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddress.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressInput.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressOutput.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjspackages/wasm-sdk/src/lib.rspackages/wasm-sdk/src/queries/address.rspackages/wasm-sdk/src/settings.rspackages/wasm-sdk/src/state_transitions/addresses.rspackages/wasm-sdk/src/state_transitions/broadcast.rspackages/wasm-sdk/src/state_transitions/mod.rspackages/wasm-sdk/tests/unit/IdentityTopUpFromAddressesResult.spec.mjspackages/wasm-sdk/tests/unit/IdentityTransferToAddressesResult.spec.mjs
💤 Files with no reviewable changes (1)
- packages/js-evo-sdk/src/wasm.ts
🧰 Additional context used
📓 Path-based instructions (3)
**/*.rs
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.rs: Rust code must passcargo clippy --workspacelinter checks
Rust code must be formatted usingcargo fmt --all
**/*.rs: Use 4-space indent for Rust files
Follow rustfmt defaults and keep code clippy-clean for Rust modules
Use snake_case for Rust module names
Use PascalCase for Rust type names
Use SCREAMING_SNAKE_CASE for Rust constants
Files:
packages/wasm-sdk/src/state_transitions/mod.rspackages/wasm-dpp2/src/platform_address/address.rspackages/wasm-dpp2/src/identity/model.rspackages/wasm-sdk/src/settings.rspackages/wasm-dpp2/src/enums/withdrawal.rspackages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/lib.rspackages/wasm-sdk/src/state_transitions/broadcast.rspackages/wasm-dpp2/src/identity_signer.rspackages/wasm-sdk/src/queries/address.rspackages/wasm-dpp2/src/state_transitions/base/state_transition.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-sdk/src/lib.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-sdk/src/state_transitions/addresses.rspackages/wasm-dpp2/src/platform_address/fee_strategy.rs
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{js,jsx,ts,tsx}: Use 2-space indent for JS/TS files
Use camelCase for variables and functions in JS/TS
Use PascalCase for class names in JS/TS
Use ESLint with Airbnb/TypeScript rules for JS/TS files
Files:
packages/js-evo-sdk/src/addresses/facade.ts
packages/**/!(node_modules)/**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Use kebab-case for filenames within JS packages
Files:
packages/js-evo-sdk/src/addresses/facade.ts
🧠 Learnings (33)
📓 Common learnings
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Applies to **/swift-sdk/**/*.{swift,h,m,c} : iOS SDK must combine both Core (SPV wallet) and Platform (identity/documents) functionality in the unified SDK with proper function naming: `dash_core_sdk_*` prefix for Core functions, `dash_sdk_*` prefix for Platform functions, and `dash_unified_sdk_*` prefix for unified functions
📚 Learning: 2024-11-06T07:27:01.722Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Applied to files:
packages/wasm-dpp2/tests/unit/PlatformAddressInput.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddress.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressOutput.spec.mjspackages/wasm-dpp2/tests/unit/IdentitySigner.spec.mjspackages/wasm-dpp2/tests/unit/AddressFundsTransfer.spec.mjspackages/wasm-sdk/tests/unit/IdentityTopUpFromAddressesResult.spec.mjspackages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs
📚 Learning: 2025-09-02T13:30:17.703Z
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json via the loadApiDefinitions() function that fetches './api-definitions.json'. The UI doesn't have hardcoded transition definitions - instead it populates categories, types, inputs, and labels from this JSON configuration file at runtime.
Applied to files:
packages/wasm-sdk/src/state_transitions/mod.rspackages/wasm-sdk/src/state_transitions/broadcast.rspackages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2025-10-09T15:59:28.329Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2716
File: packages/rs-dapi/src/services/platform_service/broadcast_state_transition.rs:181-187
Timestamp: 2025-10-09T15:59:28.329Z
Learning: In `packages/rs-dapi/src/services/platform_service/broadcast_state_transition.rs`, the maintainer requires logging full state transition bytes (`tx_bytes = hex::encode(st_bytes)`) at debug level when a state transition passes CheckTx but is removed from the block by the proposer, to facilitate debugging of this rare edge case.
Applied to files:
packages/wasm-sdk/src/state_transitions/mod.rspackages/wasm-sdk/src/state_transitions/broadcast.rs
📚 Learning: 2025-09-02T13:30:17.703Z
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json rather than being hardcoded in the HTML file. The UI loads transition categories, types, inputs, and labels from this JSON configuration file.
Applied to files:
packages/wasm-sdk/src/state_transitions/mod.rspackages/wasm-sdk/src/state_transitions/broadcast.rspackages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2024-10-09T00:22:57.778Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2201
File: packages/rs-platform-version/src/version/v2.rs:1186-1188
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the `IdentityTransitionVersions` structure within `packages/rs-platform-version/src/version/v2.rs`, the field `credit_withdrawal` does not need the `identity_` prefix since it is already encompassed within identity state transitions.
Applied to files:
packages/wasm-sdk/src/state_transitions/mod.rspackages/wasm-dpp2/src/identity/model.rspackages/wasm-dpp2/src/lib.rspackages/wasm-dpp2/src/state_transitions/base/state_transition.rspackages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2024-11-28T13:49:17.301Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2317
File: packages/rs-dapi-client/src/address_list.rs:175-180
Timestamp: 2024-11-28T13:49:17.301Z
Learning: In Rust code in `packages/rs-dapi-client/src/address_list.rs`, do not change the interface of deprecated methods like `add_uri`, even to fix potential panics.
Applied to files:
packages/wasm-sdk/src/state_transitions/mod.rspackages/wasm-dpp2/src/platform_address/address.rspackages/wasm-sdk/src/queries/address.rs
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WASM bindings to connect Rust and JavaScript code
Applied to files:
packages/wasm-dpp2/src/platform_address/address.rspackages/wasm-dpp2/src/identity/model.rspackages/wasm-sdk/src/settings.rspackages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/lib.rspackages/wasm-sdk/src/state_transitions/broadcast.rspackages/wasm-dpp2/src/identity_signer.rspackages/wasm-sdk/src/queries/address.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-sdk/src/state_transitions/addresses.rspackages/wasm-dpp2/src/platform_address/fee_strategy.rs
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WebAssembly as a bridge between Rust and JavaScript implementations
Applied to files:
packages/wasm-dpp2/src/platform_address/address.rspackages/wasm-dpp2/src/identity/model.rspackages/wasm-sdk/src/settings.rspackages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/lib.rspackages/wasm-sdk/src/queries/address.rspackages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2024-10-09T00:22:57.778Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Applied to files:
packages/wasm-dpp2/src/identity/model.rspackages/wasm-dpp2/src/identity_signer.rspackages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2025-07-28T20:00:08.502Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Applied to files:
packages/wasm-dpp2/src/identity/model.rspackages/wasm-sdk/src/settings.rspackages/wasm-sdk/tests/unit/IdentityTransferToAddressesResult.spec.mjspackages/wasm-dpp2/tests/unit/IdentitySigner.spec.mjspackages/js-evo-sdk/src/addresses/facade.tspackages/wasm-dpp2/src/lib.rspackages/wasm-dpp2/src/identity_signer.rspackages/wasm-sdk/tests/unit/IdentityTopUpFromAddressesResult.spec.mjspackages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-sdk/src/lib.rspackages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2024-11-20T16:05:40.200Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2257
File: packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs:148-151
Timestamp: 2024-11-20T16:05:40.200Z
Learning: In `packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs`, when converting public keys from `QuorumForSavingV0` to `VerificationQuorum`, it's acceptable to use `.expect()` for public key conversion, as the conversion has been verified and panics are acceptable in this context.
Applied to files:
packages/wasm-dpp2/src/identity/model.rspackages/wasm-dpp2/src/private_key.rs
📚 Learning: 2024-11-20T10:01:50.837Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2257
File: packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs:94-94
Timestamp: 2024-11-20T10:01:50.837Z
Learning: In `packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs`, when converting with `PublicKey::try_from`, it's acceptable to use `.expect()` to handle potential conversion errors.
Applied to files:
packages/wasm-dpp2/src/identity/model.rspackages/wasm-dpp2/src/private_key.rspackages/wasm-sdk/src/queries/address.rspackages/wasm-dpp2/src/state_transitions/base/state_transition.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2025-08-05T13:55:39.147Z
Learnt from: thephez
Repo: dashpay/platform PR: 2718
File: packages/wasm-sdk/index.html:0-0
Timestamp: 2025-08-05T13:55:39.147Z
Learning: The get_identity_keys_with_proof_info function in the Rust WASM bindings does not support the "search" key request type and lacks the searchPurposeMap parameter. When proof mode is enabled with keyRequestType === 'search', the implementation falls back to the non-proof version (get_identity_keys) to maintain functionality.
Applied to files:
packages/wasm-dpp2/src/identity/model.rspackages/wasm-sdk/src/queries/address.rs
📚 Learning: 2024-11-20T20:43:41.185Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2257
File: packages/rs-drive-abci/tests/strategy_tests/masternodes.rs:212-220
Timestamp: 2024-11-20T20:43:41.185Z
Learning: In `packages/rs-drive-abci/tests/strategy_tests/masternodes.rs`, the pattern of generating a `PrivateKey`, converting it to bytes, and reconstructing a `BlsPrivateKey` from those bytes is intentional. Avoid suggesting to simplify this code in future reviews.
Applied to files:
packages/wasm-dpp2/src/identity/model.rspackages/wasm-dpp2/src/private_key.rs
📚 Learning: 2024-12-05T12:59:22.044Z
Learnt from: lklimek
Repo: dashpay/platform PR: 1924
File: packages/rs-dapi-client/src/request_settings.rs:74-74
Timestamp: 2024-12-05T12:59:22.044Z
Learning: The `AppliedRequestSettings` struct in `packages/rs-dapi-client/src/request_settings.rs` is intended for internal use within the monorepo and is not part of the public API.
Applied to files:
packages/wasm-sdk/src/settings.rspackages/wasm-sdk/src/lib.rs
📚 Learning: 2025-09-03T14:42:29.958Z
Learnt from: thephez
Repo: dashpay/platform PR: 2754
File: packages/wasm-sdk/docs.html:1970-1971
Timestamp: 2025-09-03T14:42:29.958Z
Learning: In packages/wasm-sdk/, the docs.html file is auto-generated from api-definitions.json. Any documentation fixes should be made in api-definitions.json rather than directly in docs.html, as manual changes to docs.html would be overwritten during regeneration.
Applied to files:
packages/wasm-sdk/src/settings.rspackages/wasm-sdk/src/lib.rs
📚 Learning: 2025-09-03T14:41:16.196Z
Learnt from: thephez
Repo: dashpay/platform PR: 2754
File: packages/wasm-sdk/AI_REFERENCE.md:766-766
Timestamp: 2025-09-03T14:41:16.196Z
Learning: In packages/wasm-sdk/, the AI_REFERENCE.md file is auto-generated from api-definitions.json. Any documentation fixes should be made in api-definitions.json rather than directly in AI_REFERENCE.md, as manual changes to AI_REFERENCE.md would be overwritten during regeneration.
Applied to files:
packages/wasm-sdk/src/settings.rspackages/wasm-sdk/src/lib.rs
📚 Learning: 2024-10-29T14:44:01.184Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2277
File: packages/rs-dapi-client/src/executor.rs:38-38
Timestamp: 2024-10-29T14:44:01.184Z
Learning: In `packages/rs-dapi-client/src/executor.rs`, for the structs `ExecutionError<E>` and `ExecutionResponse<R>`, only the serde derives (`Serialize`, `Deserialize`) should be conditional based on the "mocks" feature; the other derives (`Debug`, `Clone`, `Eq`, `PartialEq`) should always be present.
Applied to files:
packages/wasm-dpp2/src/enums/withdrawal.rs
📚 Learning: 2024-11-25T01:17:02.001Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2347
File: packages/rs-drive/tests/query_tests.rs:438-460
Timestamp: 2024-11-25T01:17:02.001Z
Learning: In Rust test files (`packages/rs-drive/tests/query_tests.rs`), when code is used only in tests, defining explicit enums for fields (like the `status` field in the `Withdrawal` struct) may not be necessary; using primitive types is acceptable.
Applied to files:
packages/wasm-dpp2/src/enums/withdrawal.rs
📚 Learning: 2024-11-20T14:14:54.721Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2337
File: packages/rs-dapi-client/src/executor.rs:161-212
Timestamp: 2024-11-20T14:14:54.721Z
Learning: In `packages/rs-dapi-client/src/executor.rs`, the `WrapWithExecutionResult` trait supports on-the-fly type conversions using the `From` trait, which is useful when using the `?` operator to return errors.
Applied to files:
packages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/state_transitions/base/state_transition.rs
📚 Learning: 2025-07-28T20:04:48.458Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/index.html:4360-4416
Timestamp: 2025-07-28T20:04:48.458Z
Learning: In packages/wasm-sdk, the wallet helper `derive_key_from_seed_with_path` (Rust function in src/wallet/key_derivation.rs) is synchronous; its JS wrapper returns a value immediately, so `await` is unnecessary.
Applied to files:
packages/wasm-dpp2/src/private_key.rs
📚 Learning: 2025-07-28T20:00:24.323Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/docs.html:2359-2383
Timestamp: 2025-07-28T20:00:24.323Z
Learning: In packages/wasm-sdk/docs.html, QuantumExplorer confirmed that placeholder private keys in documentation examples are acceptable as they are not real keys, though field name accuracy for the SDK API should still be maintained.
Applied to files:
packages/wasm-sdk/tests/unit/IdentityTransferToAddressesResult.spec.mjspackages/wasm-dpp2/tests/unit/IdentitySigner.spec.mjspackages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs
📚 Learning: 2024-10-30T11:19:59.163Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
Applied to files:
packages/wasm-sdk/tests/unit/IdentityTransferToAddressesResult.spec.mjspackages/wasm-sdk/tests/unit/IdentityTopUpFromAddressesResult.spec.mjspackages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2025-06-18T03:44:14.385Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2673
File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_update/mod.rs:1164-1197
Timestamp: 2025-06-18T03:44:14.385Z
Learning: QuantumExplorer determined that a CodeRabbit suggestion about fixing signable_bytes calculation in identity update tests with contract-bound keys was incorrect - the code flow is working as intended without the suggested changes.
Applied to files:
packages/wasm-dpp2/tests/unit/IdentitySigner.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs
📚 Learning: 2025-11-25T13:10:38.019Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: packages/swift-sdk/SwiftExampleApp/CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:38.019Z
Learning: Applies to packages/swift-sdk/SwiftExampleApp/**/*Test*.swift : Use TestSigner for transaction signing in test files
Applied to files:
packages/wasm-dpp2/tests/unit/IdentitySigner.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs
📚 Learning: 2024-10-08T13:28:03.529Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2227
File: packages/rs-drive-abci/src/platform_types/platform_state/mod.rs:141-141
Timestamp: 2024-10-08T13:28:03.529Z
Learning: When converting `PlatformStateV0` to `PlatformStateForSavingV1` in `packages/rs-drive-abci/src/platform_types/platform_state/mod.rs`, only version `0` needs to be handled in the match on `platform_state_for_saving_structure_default` because the changes are retroactive.
Applied to files:
packages/wasm-sdk/src/queries/address.rspackages/wasm-dpp2/src/state_transitions/base/state_transition.rs
📚 Learning: 2024-10-29T14:40:54.727Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2277
File: packages/rs-sdk/src/core/transaction.rs:0-0
Timestamp: 2024-10-29T14:40:54.727Z
Learning: In `packages/rs-sdk/src/platform/document_query.rs` and `packages/rs-sdk/src/core/transaction.rs`, certain places don't implement `IntoInner`, so direct error mappings cannot be simplified using `IntoInner`. A TODO comment has been added to address this in a future PR.
Applied to files:
packages/wasm-sdk/src/queries/address.rs
📚 Learning: 2024-10-18T15:37:36.387Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2024-10-18T15:37:21.329Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2025-02-10T11:26:36.709Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2024-10-10T10:30:19.883Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2232
File: packages/rs-sdk/src/mock/sdk.rs:90-95
Timestamp: 2024-10-10T10:30:19.883Z
Learning: In `packages/rs-sdk/src/mock/sdk.rs`, the `load_expectations` method in `MockDashPlatformSdk` remains asynchronous (`async`) for backward compatibility, even though it now delegates to the synchronous `load_expectations_sync` method.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2025-09-03T15:44:33.889Z
Learnt from: thephez
Repo: dashpay/platform PR: 2754
File: packages/wasm-sdk/docs.html:0-0
Timestamp: 2025-09-03T15:44:33.889Z
Learning: In packages/wasm-sdk/docs.html, thephez prefers to keep realistic-looking private key placeholders in documentation examples rather than using obvious fake placeholders, despite secret scanner warnings.
Applied to files:
packages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs
🔇 Additional comments (52)
packages/wasm-dpp2/src/state_transitions/base/state_transition.rs (1)
62-66: LGTM!The
From<&StateTransitionWasm>implementation correctly clones the innerStateTransition, providing a convenient conversion from borrowed wasm wrappers. This complements the existing owned conversions and aligns with similar patterns used elsewhere in the PR (e.g.,PrivateKeyWasm,IdentityWasm).packages/wasm-dpp2/src/identity/model.rs (2)
26-30: LGTM!Clean conversion implementation that moves the inner
Identityout of the wrapper.
99-103: Verify JS consumer updates for optional return value.The signature change returns
Option<IdentityPublicKeyWasm>instead of a non-optional value, ensuring JS code receivesundefinedwhen a key is not found. Verify that all JS/TS consumers properly handle this optional return type, checking for any code paths that assume a non-null value.packages/wasm-dpp2/src/private_key.rs (1)
14-27: LGTM!The
Clonederive and bidirectionalFromimplementations enable proper interop with the signer types (IdentitySignerWasm,PlatformAddressSignerWasm) that require cloning and converting between wrapper and core types.packages/wasm-sdk/src/settings.rs (2)
1-99: Well-structured settings parsing module.The TypeScript interface definitions are clear and well-documented. The parsing logic correctly handles optional fields and null/undefined values.
101-284: LGTM for PutSettings parsing.The nested parsing of
stateTransitionCreationOptionsis well-implemented, and the overall structure mirrors the simplerRequestSettingsparser appropriately.packages/wasm-dpp2/src/platform_address/fee_strategy.rs (2)
1-88: LGTM!Clean WASM bindings for fee strategy steps with clear constructors and getters. The helper functions (
fee_strategy_from_steps,default_fee_strategy,fee_strategy_from_steps_or_default) provide good ergonomics for building strategies.
90-152: Well-implemented custom Deserialize.The visitor-based deserialization correctly handles the
{ type, index }structure with proper error messages for missing, duplicate, and unknown fields/variants.packages/wasm-sdk/src/lib.rs (2)
10-10: LGTM!The new
settingsmodule is correctly exposed, making the parsing utilities available for use by other SDK modules.
18-18: LGTM!Formatting consolidation of re-exports; no functional change.
packages/wasm-dpp2/tests/unit/PlatformAddressOutput.spec.mjs (1)
1-87: Good test coverage for PlatformAddressOutput.Tests appropriately cover:
- Multiple construction paths (PlatformAddress, bech32m string, Uint8Array)
- Edge cases (large amounts, zero, negative rejection)
- Property accessors
The negative amount test correctly expects an error to be thrown.
packages/wasm-sdk/src/state_transitions/mod.rs (1)
1-2: LGTM!New
addressesandbroadcastsubmodules correctly added to the state_transitions module, expanding the SDK's capability for address-based state transitions.packages/wasm-dpp2/src/platform_address/address.rs (1)
11-13: LGTM!Adding
PartialOrdandOrdderives is appropriate for enabling ordered collections (e.g.,BTreeMap,BTreeSet) and sorting operations onPlatformAddressWasm. This is a non-breaking, additive change.packages/wasm-dpp2/tests/unit/IdentitySigner.spec.mjs (1)
1-90: LGTM!Comprehensive test coverage for
IdentitySignerincluding construction, key addition via multiple formats (WIF, hex, bytes), multi-key scenarios, key replacement behavior, and error handling for invalid WIF. The test structure follows established patterns in the codebase.packages/wasm-dpp2/tests/unit/PlatformAddressInput.spec.mjs (1)
1-110: LGTM!Solid test coverage for
PlatformAddressInputincluding multiple construction paths, boundary testing for nonce values (zero, negative rejection, u32 overflow), large amount handling with BigInt, and getter validation. Error case testing properly validates rejection of invalid inputs.packages/wasm-dpp2/tests/unit/AddressFundsTransfer.spec.mjs (1)
9-39: LGTM!The
FeeStrategySteptests provide good coverage for bothdeductFromInputandreduceOutputfactory methods, including non-zero index validation and flag assertions.packages/wasm-dpp2/tests/unit/PlatformAddress.spec.mjs (1)
1-239: LGTM!Excellent test coverage for
PlatformAddressincluding all factory methods (fromBytes,fromBech32m,fromHex,fromP2pkhHash,fromP2shHash), constructor variations, serialization methods, and a bech32m roundtrip test. Error cases properly validate rejection of invalid inputs with meaningful error messages.packages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs (1)
1-158: LGTM!Comprehensive test suite for
PlatformAddressSignercovering construction, key management (addKeywith various input formats), key lookup (hasKey), key replacement behavior, andgetPrivateKeysBytesstructure validation. The tests properly verify both the address hash (20 bytes) and private key (32 bytes) lengths in the returned entries.packages/wasm-dpp2/src/enums/withdrawal.rs (1)
7-13: LGTM!Adding
CloneandCopyderives is appropriate for this simple enum and enables more flexible usage patterns.packages/wasm-sdk/tests/unit/IdentityTopUpFromAddressesResult.spec.mjs (1)
1-120: LGTM!This test suite appropriately focuses on export verification and interface documentation for
IdentityTopUpFromAddressesResult, since the type has a private constructor and instances are only obtained from SDK methods. The tests serve as valuable API documentation, validating that expected types (PlatformAddressInfo,PlatformAddress) are exported and that BigInt handling patterns are documented.packages/wasm-sdk/tests/unit/IdentityTransferToAddressesResult.spec.mjs (1)
1-203: Well-structured API surface validation tests.The test file provides comprehensive coverage for validating the
IdentityTransferToAddressesResultexports, including constructor validation, BigInt handling, semantic differences from related types, and integration withIdentitySigner. The documentation-style tests appropriately clarify expected usage patterns.packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs (2)
71-102: Good test coverage for the new transfer() method.The test properly creates typed SDK objects (PlatformAddress, PrivateKey, PlatformAddressSigner, PlatformAddressInput, PlatformAddressOutput) and verifies that
addressFundsTransferis called with the correct options structure.
140-269: Comprehensive test coverage for new facade methods.The tests for
topUpIdentity,withdraw,transferFromIdentity,fundFromAssetLock, andcreateIdentityproperly verify method forwarding to the underlying wasm-sdk methods. Using empty objects for mock signers/identities is acceptable here since the focus is on verifying delegation, not actual signing behavior.packages/wasm-dpp2/src/platform_address/mod.rs (1)
1-15: Clean module organization.The module structure properly declares submodules and consolidates public re-exports for the platform address WASM bindings. This follows idiomatic Rust patterns for organizing related functionality.
packages/wasm-sdk/src/queries/address.rs (2)
22-30: Good use of idiomatic From trait conversion.The
From<AddressInfo>implementation standardizes the conversion pathway and is correctly used at all call sites. The implementation properly converts nested types using.into()for the address field.
141-141: Clone is necessary here.The
info.clone()is required becauseinfois a reference obtained from theaddress_infosmap, andFrom<AddressInfo>takes ownership. This is the correct approach.packages/wasm-dpp2/src/lib.rs (3)
23-23: New identity_signer module properly declared.
34-36: Well-organized new exports.The exports for
CoreScriptWasm,PoolingWasm, andIdentitySignerWasmare properly grouped and follow the established naming convention for WASM wrapper types.
50-55: Consolidated platform_address exports.The expanded re-export block cleanly groups all platform address-related utilities, making the public API surface clear and organized.
packages/js-evo-sdk/src/addresses/facade.ts (2)
58-92: Well-documented transfer method with helpful example.The comprehensive JSDoc documentation with a complete code example will help developers understand how to use the transfer flow correctly. The implementation follows the established facade pattern.
94-295: Consistent implementation across all new facade methods.All six new methods (
topUpIdentity,withdraw,transferFromIdentity,fundFromAssetLock,createIdentity) follow the same clean delegation pattern and include comprehensive JSDoc documentation with practical examples. The TypeScript types properly reflect the expected wasm-sdk signatures.packages/wasm-dpp2/src/identity_signer.rs (4)
26-31: Secure key storage design.Storing private keys mapped by their public key hash (20 bytes) enables efficient lookup during signing while keeping the signer implementation straightforward.
33-39: Good security practice: Debug hides key material.The Debug implementation correctly exposes only the key count, preventing accidental logging of sensitive private key data.
104-162: Correct Signer trait implementation.The
Signer<IdentityPublicKey>implementation properly:
- Validates key type is ECDSA_HASH160
- Validates public key hash length (20 bytes)
- Looks up private key and signs data
- Creates appropriate
AddressWitness::P2pkhfor witness creationThe restriction to ECDSA_HASH160 is documented and consistently enforced across all trait methods.
204-213: Clean TryFrom conversion for JS interop.The implementation correctly uses
to_wasmfor type-safe conversion fromJsValueand clones the boxed value since WASM bindings return boxed references.packages/wasm-dpp2/src/platform_address/input_output.rs (4)
1-23: LGTM!The struct definition and imports are well-organized. The documentation clearly explains the purpose of
PlatformAddressInputWasm.
25-43: LGTM!The BigInt conversion helpers correctly handle range validation with clear error messages.
213-224: LGTM!The f64 to u32 conversion for nonce is safe since
u32::MAXis well within f64's precise integer range.
447-459: Duplicate addresses are silently overwritten when collecting to BTreeMap.When converting vectors to
BTreeMap, if duplicate addresses are present, later entries overwrite earlier ones without warning. If duplicates should be an error, consider validating uniqueness before collection.#!/bin/bash # Check if there's any validation for duplicate addresses in the callers of these functions rg -n "inputs_to_btree_map|outputs_to_btree_map" --type rust -A 5 -B 2packages/wasm-dpp2/src/platform_address/signer.rs (4)
14-31: LGTM!The struct design is clean with appropriate
CloneandDefaultderives. TheDebugimpl wisely only showskey_countrather than exposing key material.
82-95: LGTM!The implementation correctly exposes key data for cross-package access. While
Reflect::setresults are discarded, failures on freshly created objects are highly unlikely in practice.
117-130: LGTM!The
sign_create_witnesscorrectly handles P2PKH addresses and provides a clear error for unsupported P2SH addresses. The trait implementation is sound.
149-164: LGTM!The
try_from_optionshelper provides a clean API for extracting signers from JS option objects with appropriate validation.packages/wasm-sdk/src/state_transitions/addresses.rs (9)
1-26: LGTM!Clean module documentation and well-organized imports from the SDK and wasm-dpp2 crates.
27-36: TypeScript interface saysPlatformAddressInput[]but Rust struct usesPlatformAddressOutputWasm.The TypeScript interface at line 89 declares
inputs: PlatformAddressInput[], but the Rust struct at line 32 usesVec<PlatformAddressOutputWasm>. The TS comment mentions "nonces fetched automatically", suggesting this is intentional, but the type mismatch may confuse consumers. Consider either:
- Updating the TS interface to use
PlatformAddressOutput[]for consistency, or- Using
PlatformAddressInputWasmin Rust if nonce information is neededAlso applies to: 78-116
139-184: LGTM!The
address_funds_transferimplementation correctly orchestrates the transfer flow with proper error handling and result conversion.
187-211: Same type mismatch: Rust usesPlatformAddressOutputWasmwhile TS declaresPlatformAddressInput[].Consistent with the earlier finding, but reinforces the need to align types or documentation.
273-337: LGTM!The implementation correctly fetches the identity, prepares inputs, and returns a structured result with both address info and updated balance.
339-369: LGTM!The withdrawal options struct correctly captures all required parameters including
core_fee_per_byteandpoolingstrategy.
528-612: LGTM!The implementation correctly uses
IdentitySignerWasmfor identity-initiated transfers and properly handles the optionalsigning_transfer_key_idparameter.
838-850: LGTM!The outputs map correctly wraps amounts in
Some()as expected by thetop_uptrait method's signature.
997-1104: LGTM!The dual-signer approach correctly separates identity key signing from address input signing. The implementation properly handles both concerns.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
packages/wasm-dpp2/src/identity/transitions/pooling.rs (2)
15-50: Consider consolidating duplicate string parsing logic.The string parsing logic for pooling values is duplicated between the
Deserializeimplementation (lines 23-33) andTryFrom<JsValue>(lines 80-88). Both perform identical case-insensitive matching against "never", "ifavailable", and "standard".🔎 Proposed refactor to extract common parsing logic
+fn parse_pooling_string(s: &str) -> Result<PoolingWasm, String> { + match s.to_lowercase().as_str() { + "never" => Ok(PoolingWasm::Never), + "ifavailable" => Ok(PoolingWasm::IfAvailable), + "standard" => Ok(PoolingWasm::Standard), + _ => Err(format!("unsupported pooling value ({})", s)), + } +} + impl<'de> Deserialize<'de> for PoolingWasm { fn deserialize<D>(deserializer: D) -> Result<Self, D::Error> where D: Deserializer<'de>, { let value: serde_json::Value = Deserialize::deserialize(deserializer)?; // Try as string first if let Some(s) = value.as_str() { - return match s.to_lowercase().as_str() { - "never" => Ok(PoolingWasm::Never), - "ifavailable" => Ok(PoolingWasm::IfAvailable), - "standard" => Ok(PoolingWasm::Standard), - _ => Err(serde::de::Error::custom(format!( - "unsupported pooling value ({})", - s - ))), - }; + return parse_pooling_string(s).map_err(serde::de::Error::custom); } // ... rest of implementationThen similarly update
TryFrom<JsValue>to use the shared helper.Also applies to: 72-106
108-116: Note: String serialization uses capitalized variants.The
From<PoolingWasm> for Stringimplementation returns capitalized variants ("Never", "IfAvailable", "Standard"), while theDeserializeandTryFromimplementations accept case-insensitive input. This asymmetry is intentional and not a bug, but be aware that serialized output will always be capitalized regardless of input casing.packages/wasm-dpp2/src/platform_address/input_output.rs (1)
24-29: Consider more descriptive error message for BigInt conversion.The error message "value must be a valid u64" doesn't explain what went wrong during the BigInt to u64 conversion. The conversion can fail due to negative values or overflow, but the user won't know which issue occurred.
🔎 Proposed improvement
fn bigint_to_u64(value: BigInt) -> Result<u64, WasmDppError> { value .try_into() - .map_err(|_| WasmDppError::invalid_argument("value must be a valid u64")) + .map_err(|_| WasmDppError::invalid_argument( + "amount must be a non-negative integer within u64 range (0 to 18446744073709551615)" + )) }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
packages/js-evo-sdk/src/addresses/facade.tspackages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-dpp2/src/enums/mod.rspackages/wasm-dpp2/src/identity/transitions/credit_withdrawal_transition.rspackages/wasm-dpp2/src/identity/transitions/mod.rspackages/wasm-dpp2/src/identity/transitions/pooling.rspackages/wasm-dpp2/src/lib.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/tests/unit/PlatformAddressInput.spec.mjs
💤 Files with no reviewable changes (1)
- packages/wasm-dpp2/src/enums/mod.rs
🧰 Additional context used
📓 Path-based instructions (3)
**/*.rs
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.rs: Rust code must passcargo clippy --workspacelinter checks
Rust code must be formatted usingcargo fmt --all
**/*.rs: Use 4-space indent for Rust files
Follow rustfmt defaults and keep code clippy-clean for Rust modules
Use snake_case for Rust module names
Use PascalCase for Rust type names
Use SCREAMING_SNAKE_CASE for Rust constants
Files:
packages/wasm-dpp2/src/identity/transitions/mod.rspackages/wasm-dpp2/src/identity/transitions/credit_withdrawal_transition.rspackages/wasm-dpp2/src/identity/transitions/pooling.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/lib.rs
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{js,jsx,ts,tsx}: Use 2-space indent for JS/TS files
Use camelCase for variables and functions in JS/TS
Use PascalCase for class names in JS/TS
Use ESLint with Airbnb/TypeScript rules for JS/TS files
Files:
packages/js-evo-sdk/src/addresses/facade.ts
packages/**/!(node_modules)/**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Use kebab-case for filenames within JS packages
Files:
packages/js-evo-sdk/src/addresses/facade.ts
🧠 Learnings (15)
📓 Common learnings
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
📚 Learning: 2024-10-09T00:22:57.778Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2201
File: packages/rs-platform-version/src/version/v2.rs:1186-1188
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the `IdentityTransitionVersions` structure within `packages/rs-platform-version/src/version/v2.rs`, the field `credit_withdrawal` does not need the `identity_` prefix since it is already encompassed within identity state transitions.
Applied to files:
packages/wasm-dpp2/src/identity/transitions/mod.rspackages/wasm-dpp2/src/identity/transitions/credit_withdrawal_transition.rspackages/wasm-dpp2/src/lib.rs
📚 Learning: 2024-09-30T12:11:35.148Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2186
File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_credit_withdrawal/mod.rs:48-54
Timestamp: 2024-09-30T12:11:35.148Z
Learning: In the identity credit withdrawal transition code, the field `platform_version.drive_abci.validation_and_processing.state_transitions.identity_credit_withdrawal_state_transition.transform_into_action` is not an `Option` type, so handling `None` cases is unnecessary.
Applied to files:
packages/wasm-dpp2/src/identity/transitions/credit_withdrawal_transition.rs
📚 Learning: 2025-08-05T13:55:39.147Z
Learnt from: thephez
Repo: dashpay/platform PR: 2718
File: packages/wasm-sdk/index.html:0-0
Timestamp: 2025-08-05T13:55:39.147Z
Learning: The get_identity_keys_with_proof_info function in the Rust WASM bindings does not support the "search" key request type and lacks the searchPurposeMap parameter. When proof mode is enabled with keyRequestType === 'search', the implementation falls back to the non-proof version (get_identity_keys) to maintain functionality.
Applied to files:
packages/wasm-dpp2/src/identity/transitions/credit_withdrawal_transition.rs
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WASM bindings to connect Rust and JavaScript code
Applied to files:
packages/wasm-dpp2/src/identity/transitions/credit_withdrawal_transition.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/lib.rs
📚 Learning: 2024-11-06T07:27:01.722Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Applied to files:
packages/wasm-dpp2/tests/unit/PlatformAddressInput.spec.mjspackages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2024-10-18T15:37:36.387Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2024-10-18T15:37:21.329Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2025-07-28T20:00:08.502Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/js-evo-sdk/src/addresses/facade.tspackages/wasm-dpp2/src/lib.rs
📚 Learning: 2025-02-10T11:26:36.709Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2025-07-28T20:00:24.323Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/docs.html:2359-2383
Timestamp: 2025-07-28T20:00:24.323Z
Learning: In packages/wasm-sdk/docs.html, QuantumExplorer confirmed that placeholder private keys in documentation examples are acceptable as they are not real keys, though field name accuracy for the SDK API should still be maintained.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2024-10-10T10:30:19.883Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2232
File: packages/rs-sdk/src/mock/sdk.rs:90-95
Timestamp: 2024-10-10T10:30:19.883Z
Learning: In `packages/rs-sdk/src/mock/sdk.rs`, the `load_expectations` method in `MockDashPlatformSdk` remains asynchronous (`async`) for backward compatibility, even though it now delegates to the synchronous `load_expectations_sync` method.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2024-10-30T11:19:59.163Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WebAssembly as a bridge between Rust and JavaScript implementations
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/lib.rs
📚 Learning: 2024-11-28T13:49:17.301Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2317
File: packages/rs-dapi-client/src/address_list.rs:175-180
Timestamp: 2024-11-28T13:49:17.301Z
Learning: In Rust code in `packages/rs-dapi-client/src/address_list.rs`, do not change the interface of deprecated methods like `add_uri`, even to fix potential panics.
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rs
🧬 Code graph analysis (4)
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs (6)
packages/wasm-dpp2/tests/unit/IdentitySigner.spec.mjs (12)
privateKey(26-26)privateKey(34-34)privateKey(43-43)privateKey(63-63)signer(17-17)signer(25-25)signer(33-33)signer(41-41)signer(50-50)signer(62-62)signer(76-76)signer(83-83)packages/wasm-dpp2/tests/unit/AddressFundsTransfer.spec.mjs (20)
privateKey(63-63)privateKey(128-128)privateKey(155-155)privateKey(193-193)signer(62-62)signer(101-101)signer(127-127)signer(154-154)signer(173-173)signer(192-192)input(58-58)input(124-124)input(151-151)input(190-190)input(211-211)output(59-59)output(125-125)output(152-152)output(171-171)output(215-215)packages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs (9)
privateKey(28-28)privateKey(38-38)privateKey(49-49)privateKey(79-79)privateKey(107-107)privateKey(126-126)privateKey(145-145)signer(17-17)signer(25-25)packages/wasm-dpp2/tests/unit/PlatformAddressInput.spec.mjs (9)
input(15-15)input(26-26)input(35-35)input(45-45)input(54-54)input(63-63)input(73-73)input(83-83)input(91-91)packages/wasm-dpp2/tests/unit/PlatformAddressOutput.spec.mjs (7)
output(15-15)output(25-25)output(33-33)output(43-43)output(51-51)output(73-73)output(83-83)packages/wasm-sdk/tests/unit/IdentityTransferToAddressesResult.spec.mjs (1)
resultMap(102-102)
packages/wasm-dpp2/src/platform_address/input_output.rs (1)
packages/wasm-dpp2/src/platform_address/address.rs (10)
value(65-67)value(78-78)try_from(47-51)try_from(57-90)try_from(96-98)try_from(104-109)from(27-29)from(33-35)from(39-41)into_inner(324-326)
packages/js-evo-sdk/src/addresses/facade.ts (2)
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs (7)
options(92-96)options(130-134)options(155-159)options(181-187)options(209-213)options(232-237)options(259-264)packages/js-evo-sdk/src/sdk.ts (1)
wasm(71-74)
packages/wasm-dpp2/src/lib.rs (2)
packages/wasm-dpp2/src/platform_address/input_output.rs (6)
platform_address(80-82)platform_address(147-149)extract_addresses(172-174)extract_amounts(177-179)inputs_to_btree_map(158-162)outputs_to_btree_map(165-169)packages/wasm-dpp2/src/platform_address/fee_strategy.rs (3)
default_fee_strategy(77-79)fee_strategy_from_steps(72-74)fee_strategy_from_steps_or_default(82-88)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
- GitHub Check: Rust packages (wasm-sdk) / Unused dependencies
- GitHub Check: Rust packages (wasm-dpp2) / Linting
- GitHub Check: Rust packages (wasm-sdk) / Linting
- GitHub Check: Rust packages (wasm-sdk) / Tests
- GitHub Check: Rust packages (wasm-dpp2) / Tests
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (RS-DAPI, rs-dapi, rs-dapi) / Build RS-DAPI image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build JS packages / Build JS
- GitHub Check: Rust crates security audit
🔇 Additional comments (11)
packages/wasm-dpp2/src/identity/transitions/credit_withdrawal_transition.rs (1)
4-4: LGTM! Clean import path update.The import path correctly references the new pooling module location under
super::pooling, aligning with the module reorganization introduced in this PR.packages/wasm-dpp2/src/identity/transitions/mod.rs (1)
5-5: LGTM! Proper module exposure.The pooling module is correctly added to the public module surface, following the existing pattern of other transition modules.
packages/wasm-dpp2/tests/unit/PlatformAddressInput.spec.mjs (1)
1-95: Excellent test coverage!The test suite comprehensively validates PlatformAddressInput construction from multiple input types (PlatformAddress object, bech32m string, Uint8Array) and covers important boundary cases including zero nonce, max u32 nonce, and large BigInt amounts. The getter tests ensure proper value retrieval. Well-structured and thorough.
packages/wasm-dpp2/src/lib.rs (2)
23-23: LGTM! Clean module and re-export additions.The new
identity_signermodule and re-exports forCoreScriptWasm,PoolingWasm, andIdentitySignerWasmproperly extend the public API surface without breaking existing functionality.Also applies to: 34-36
50-55: Good consolidation of platform_address exports.The grouped re-export block cleanly exposes multiple platform_address items (input/output types, fee strategy utilities, and signer) in a single statement, improving maintainability over scattered individual exports.
packages/wasm-dpp2/src/platform_address/input_output.rs (2)
15-155: Excellent WASM bindings implementation!The
PlatformAddressInputWasmandPlatformAddressOutputWasmtypes are well-designed with:
- Clear documentation and parameter descriptions
- Proper WASM bindgen annotations for JS interop
- Serde configuration for camelCase compatibility
- Comprehensive accessor methods for both external (JS) and internal (Rust) use
- Consistent patterns between input and output types
157-179: Well-designed helper functions.The conversion and extraction helpers (
inputs_to_btree_map,outputs_to_btree_map,extract_addresses,extract_amounts) provide clean utilities for working with collections of inputs/outputs, properly leveraging the internal accessor methods.packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs (3)
71-102: LGTM!The test properly creates PlatformAddress, PrivateKey, and PlatformAddressSigner objects, then verifies the transfer method forwards options correctly and returns the expected result structure.
104-138: LGTM!Good test coverage for the Success result type. The test correctly verifies that the transfer method can handle different result shapes.
140-242: LGTM!All four tests (topUpIdentity, withdraw, transferFromIdentity, fundFromAssetLock) properly verify that facade methods forward options to the underlying WASM SDK methods and return expected results.
packages/js-evo-sdk/src/addresses/facade.ts (1)
89-262: LGTM!The five new methods (topUpIdentity, withdraw, transferFromIdentity, fundFromAssetLock, createIdentity) are well-implemented with:
- Proper delegation to WASM SDK methods
- Comprehensive JSDoc documentation with realistic examples
- Return types that match test expectations
- Consistent patterns with existing facade methods
| async transfer(options: wasm.AddressFundsTransferOptions): Promise<Map<wasm.PlatformAddress, wasm.PlatformAddressInfo>> { | ||
| const w = await this.sdk.getWasmSdkConnected(); | ||
| return w.addressFundsTransfer(options); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for addressFundsTransfer definition in wasm-sdk
rg -nP --type=ts --type=d.ts 'addressFundsTransfer' --max-count=20Repository: dashpay/platform
Length of output: 88
🏁 Script executed:
# Find test files for the transfer method
fd -t f 'facade.*test\|.*\.spec\.ts' packages/js-evo-sdkRepository: dashpay/platform
Length of output: 42
🏁 Script executed:
# Search for AddressFundsTransfer related types
rg -nP --type=ts --type=d.ts 'AddressFundsTransfer(Result|Options)' --max-count=20Repository: dashpay/platform
Length of output: 88
🏁 Script executed:
# Search for addressFundsTransfer more broadly
rg -n 'addressFundsTransfer' packages/Repository: dashpay/platform
Length of output: 762
🏁 Script executed:
# Find test files more broadly
find packages/js-evo-sdk -type f -name '*.test.ts' -o -name '*.spec.ts'Repository: dashpay/platform
Length of output: 42
🏁 Script executed:
# Look for facade-related test files
find packages/js-evo-sdk -type f -name '*facade*'Repository: dashpay/platform
Length of output: 521
🏁 Script executed:
# Search for AddressFundsTransfer types in wasm-sdk
rg -n 'AddressFundsTransfer' packages/wasm-sdk/Repository: dashpay/platform
Length of output: 845
🏁 Script executed:
# Read the test file to see actual return values
cat packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjsRepository: dashpay/platform
Length of output: 10867
🏁 Script executed:
# Read the Rust source for addressFundsTransfer
cat packages/wasm-sdk/src/state_transitions/addresses.rsRepository: dashpay/platform
Length of output: 38593
Return type does not match test expectations.
The declared return type Promise<Map<wasm.PlatformAddress, wasm.PlatformAddressInfo>> contradicts what the test file expects. Tests stub addressFundsTransfer to return a discriminated union object (lines 22-25, 105-108) with a type field containing either 'VerifiedAddressInfos' (with addressInfos array) or 'Success' (with message string), not a Map. Update the return type in facade.ts to match the actual WASM SDK return shape, or verify that the WASM binding's return type definition is correct.
🤖 Prompt for AI Agents
In packages/js-evo-sdk/src/addresses/facade.ts around lines 84-87, the declared
return type Promise<Map<wasm.PlatformAddress, wasm.PlatformAddressInfo>> does
not match what tests (and the WASM stub) actually return — a discriminated-union
with type 'VerifiedAddressInfos' (containing addressInfos array) or 'Success'
(containing message). Change the transfer method's return type to the actual
WASM return shape (e.g., Promise<wasm.AddressFundsTransferResult> or an explicit
union like Promise<{type: 'VerifiedAddressInfos'; addressInfos: ...} | {type:
'Success'; message: string}>), keep the implementation calling
w.addressFundsTransfer(options) unchanged, and/or update the WASM binding type
if that definition is incorrect so the facade signature reflects the real return
value.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/wasm-sdk/src/settings.rs (1)
93-157: Consider using TypeScript extends to reduce duplication.The PutSettings interface duplicates all RequestSettings fields instead of extending it. While this provides clear documentation, it creates maintenance overhead.
💡 Optional: Use TypeScript extends pattern
Consider restructuring the TypeScript interface to extend RequestSettings:
export interface PutSettings extends RequestSettings { /** * Timeout in milliseconds for waiting for the state transition result. * Only applies to broadcast and wait operations. */ waitTimeoutMs?: number; // ... remaining Put-specific fields }This would ensure consistency if RequestSettings changes in the future.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/wasm-sdk/src/settings.rs
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rs
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.rs: Rust code must passcargo clippy --workspacelinter checks
Rust code must be formatted usingcargo fmt --all
**/*.rs: Use 4-space indent for Rust files
Follow rustfmt defaults and keep code clippy-clean for Rust modules
Use snake_case for Rust module names
Use PascalCase for Rust type names
Use SCREAMING_SNAKE_CASE for Rust constants
Files:
packages/wasm-sdk/src/settings.rs
🧠 Learnings (4)
📓 Common learnings
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Applies to **/swift-sdk/**/*.{swift,h,m,c} : iOS SDK must combine both Core (SPV wallet) and Platform (identity/documents) functionality in the unified SDK with proper function naming: `dash_core_sdk_*` prefix for Core functions, `dash_sdk_*` prefix for Platform functions, and `dash_unified_sdk_*` prefix for unified functions
📚 Learning: 2024-12-05T12:59:22.044Z
Learnt from: lklimek
Repo: dashpay/platform PR: 1924
File: packages/rs-dapi-client/src/request_settings.rs:74-74
Timestamp: 2024-12-05T12:59:22.044Z
Learning: The `AppliedRequestSettings` struct in `packages/rs-dapi-client/src/request_settings.rs` is intended for internal use within the monorepo and is not part of the public API.
Applied to files:
packages/wasm-sdk/src/settings.rs
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WASM bindings to connect Rust and JavaScript code
Applied to files:
packages/wasm-sdk/src/settings.rs
📚 Learning: 2025-07-28T20:00:08.502Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Applied to files:
packages/wasm-sdk/src/settings.rs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)
- GitHub Check: Rust packages (wasm-dpp2) / Linting
- GitHub Check: Rust packages (wasm-sdk) / Linting
- GitHub Check: Rust packages (wasm-sdk) / Tests
- GitHub Check: Rust packages (wasm-sdk) / Unused dependencies
- GitHub Check: Build Docker images (RS-DAPI, rs-dapi, rs-dapi) / Build RS-DAPI image
- GitHub Check: Build JS packages / Build JS
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Rust crates security audit
🔇 Additional comments (4)
packages/wasm-sdk/src/settings.rs (4)
1-87: LGTM! Well-structured RequestSettings implementation.The RequestSettings section follows wasm-bindgen best practices:
- Clear TypeScript interface with helpful documentation and defaults
- Proper serde deserialization with camelCase field renaming
- Safe type conversions (u32 → usize, milliseconds → Duration)
- Defensive null/undefined checks before deserialization
The parse function pattern of returning
Nonefor invalid/missing settings is appropriate for optional configuration.
165-186: Excellent use of serde composition patterns.The
#[serde(flatten)]attribute on line 179 elegantly composesRequestSettingsInputintoPutSettingsInput, avoiding field duplication at the Rust level. The#[serde(default)]attributes ensure proper fallback values for the boolean signing options.
188-213: LGTM! Proper conversion logic for PutSettings.The From implementation correctly:
- Reuses the RequestSettingsInput conversion via
.into()on line 206- Maps state transition creation options to dash_sdk types with appropriate field assignments
- Converts milliseconds to Duration for wait_timeout
- Propagates all optional fields appropriately
215-227: The parse_put_settings function properly handles deserialization errors and optional settings. Callers correctly handle the Option result by passing it to downstream functions (broadcast, wait_for_response, broadcast_and_wait) that are designed to accept Optional types, ensuring that None values are processed appropriately by the underlying implementations.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
packages/wasm-dpp2/src/platform_address/signer.rs (1)
79-95: Consider adding a security warning to the documentation.While the method is clearly intended for internal cross-package access, consider adding an explicit warning in the doc comment that this method exposes sensitive private key material and should only be used internally.
📝 Suggested documentation enhancement
- /// Returns all private keys as an array of {addressHash: Uint8Array, privateKey: Uint8Array}. - /// This is used internally for cross-package access. + /// Returns all private keys as an array of {addressHash: Uint8Array, privateKey: Uint8Array}. + /// + /// ⚠️ WARNING: This method exposes sensitive private key material. It is intended + /// for internal cross-package access only and should not be used in public APIs. + /// This is used internally for cross-package access.packages/wasm-dpp2/src/platform_address/input_output.rs (1)
171-185: Consider clarifying the None case in the documentation.The function wraps all amounts in
Some(), but the comment suggests thatNonevalues are meaningful ("None means the system distributes the asset lock funds automatically"). This could be confusing since this function never producesNonevalues.📝 Suggested documentation clarification
/// Converts a vector of PlatformAddressOutput into a BTreeMap with optional amounts. /// -/// Used for asset lock funding where the amount is optional (None means -/// the system distributes the asset lock funds automatically). +/// Used for asset lock funding. This function wraps all amounts in Some(). +/// The Option type allows callers to insert None values separately when the +/// system should distribute asset lock funds automatically. pub fn outputs_to_optional_btree_map(Alternatively, if None values should be supported, consider adding a constructor parameter or separate function.
packages/wasm-dpp2/src/identity/signer.rs (1)
76-80: Key replacement behavior on duplicate public key hash.When
add_keyis called with a private key that derives to the same public key hash as an existing entry, the old key is silently replaced (line 79). This appears intentional based on the test coverage mentioned in the AI summary ("replacement semantics"), but callers should be aware of this behavior.Optional: Consider logging or returning indication of replacement
If it would be helpful for debugging, you could optionally return a boolean indicating whether a key was replaced:
pub fn add_key(&mut self, private_key: &PrivateKeyWasm) -> WasmDppResult<bool> { // ... existing derivation code ... let was_replaced = self.private_keys.insert(public_key_hash, key_array).is_some(); Ok(was_replaced) }However, since the current behavior matches the
PlatformAddressSignerpattern and tests validate the replacement semantics, the existing implementation is acceptable.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
packages/wasm-dpp2/src/identity/signer.rspackages/wasm-dpp2/src/lib.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-sdk/src/state_transitions/addresses.rs
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/wasm-sdk/src/state_transitions/addresses.rs
- packages/wasm-dpp2/src/lib.rs
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rs
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.rs: Rust code must passcargo clippy --workspacelinter checks
Rust code must be formatted usingcargo fmt --all
**/*.rs: Use 4-space indent for Rust files
Follow rustfmt defaults and keep code clippy-clean for Rust modules
Use snake_case for Rust module names
Use PascalCase for Rust type names
Use SCREAMING_SNAKE_CASE for Rust constants
Files:
packages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/identity/signer.rspackages/wasm-dpp2/src/platform_address/signer.rs
🧠 Learnings (8)
📓 Common learnings
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WASM bindings to connect Rust and JavaScript code
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json via the loadApiDefinitions() function that fetches './api-definitions.json'. The UI doesn't have hardcoded transition definitions - instead it populates categories, types, inputs, and labels from this JSON configuration file at runtime.
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json rather than being hardcoded in the HTML file. The UI loads transition categories, types, inputs, and labels from this JSON configuration file.
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WebAssembly as a bridge between Rust and JavaScript implementations
Learnt from: shumkov
Repo: dashpay/platform PR: 2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WASM bindings to connect Rust and JavaScript code
Applied to files:
packages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/identity/signer.rs
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WebAssembly as a bridge between Rust and JavaScript implementations
Applied to files:
packages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2024-11-20T10:01:50.837Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2257
File: packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs:94-94
Timestamp: 2024-11-20T10:01:50.837Z
Learning: In `packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs`, when converting with `PublicKey::try_from`, it's acceptable to use `.expect()` to handle potential conversion errors.
Applied to files:
packages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/platform_address/signer.rs
📚 Learning: 2024-11-28T13:49:17.301Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2317
File: packages/rs-dapi-client/src/address_list.rs:175-180
Timestamp: 2024-11-28T13:49:17.301Z
Learning: In Rust code in `packages/rs-dapi-client/src/address_list.rs`, do not change the interface of deprecated methods like `add_uri`, even to fix potential panics.
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2024-10-06T16:11:34.946Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-06T16:11:34.946Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Applied to files:
packages/wasm-dpp2/src/identity/signer.rs
📚 Learning: 2025-07-28T20:00:08.502Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Applied to files:
packages/wasm-dpp2/src/identity/signer.rs
📚 Learning: 2025-08-05T13:55:39.147Z
Learnt from: thephez
Repo: dashpay/platform PR: 2718
File: packages/wasm-sdk/index.html:0-0
Timestamp: 2025-08-05T13:55:39.147Z
Learning: The get_identity_keys_with_proof_info function in the Rust WASM bindings does not support the "search" key request type and lacks the searchPurposeMap parameter. When proof mode is enabled with keyRequestType === 'search', the implementation falls back to the non-proof version (get_identity_keys) to maintain functionality.
Applied to files:
packages/wasm-dpp2/src/identity/signer.rs
🧬 Code graph analysis (3)
packages/wasm-dpp2/src/platform_address/input_output.rs (1)
packages/wasm-dpp2/src/platform_address/address.rs (10)
value(65-67)value(78-78)try_from(47-51)try_from(57-90)try_from(96-98)try_from(104-109)from(27-29)from(33-35)from(39-41)into_inner(324-326)
packages/wasm-dpp2/src/identity/signer.rs (3)
packages/wasm-dpp2/src/platform_address/signer.rs (7)
fmt(26-30)new(37-41)add_key(48-56)struct_name(59-61)key_count(65-67)sign(99-115)try_from(180-185)packages/wasm-sdk/src/error.rs (1)
invalid_argument(75-77)packages/wasm-dpp2/src/private_key.rs (1)
from_wif(42-47)
packages/wasm-dpp2/src/platform_address/signer.rs (1)
packages/wasm-dpp2/src/platform_address/address.rs (12)
try_from(47-51)try_from(57-90)try_from(96-98)try_from(104-109)struct_name(188-190)from(27-29)from(33-35)from(39-41)hash(250-252)inner(319-321)value(65-67)value(78-78)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)
- GitHub Check: Rust packages (wasm-sdk) / Tests
- GitHub Check: Rust packages (wasm-dpp2) / Unused dependencies
- GitHub Check: Rust packages (wasm-sdk) / Linting
- GitHub Check: Rust packages (wasm-sdk) / Unused dependencies
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build Docker images (RS-DAPI, rs-dapi, rs-dapi) / Build RS-DAPI image
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build JS packages / Build JS
- GitHub Check: Rust crates security audit
🔇 Additional comments (22)
packages/wasm-dpp2/src/platform_address/mod.rs (1)
1-15: LGTM! Clean module organization.The module structure is well-organized with clear submodules and a logical public API surface. Naming conventions follow Rust standards (snake_case for modules, PascalCase for types).
packages/wasm-dpp2/src/platform_address/signer.rs (6)
1-23: LGTM! Well-structured signer with appropriate security considerations.The use of
BTreeMapprovides deterministic ordering, and the struct design is clean. The wasm_bindgen attribute correctly exposes this to JavaScript as "PlatformAddressSigner".
25-31: LGTM! Security-conscious Debug implementation.Showing only
key_countinstead of the actual private keys prevents accidental exposure in logs or debug output. This is a good security practice.
33-77: LGTM! Well-designed public API.The methods follow wasm-bindgen conventions correctly, with appropriate error handling and flexible input types via
unchecked_param_type. The API surface is intuitive for JavaScript consumers.
98-136: LGTM! Robust Signer implementation with clear limitations.The
Signer<PlatformAddress>implementation is well-structured:
- Proper error handling for missing keys with descriptive messages including the address hash
- Explicit rejection of P2SH addresses with a clear error message
- Clean separation of concerns between signing and witness creation
138-175: LGTM! Useful helper methods for Rust-side and JS interop.The helper methods provide:
- Internal access to the signer state (
inner(),private_keys())- Convenient extraction from JavaScript options objects with clear error messages
- Flexible field name specification for different use cases
177-186: LGTM! Standard TryFrom implementation for WASM interop.The conversion follows the established pattern using
to_wasmwith appropriate error handling and a clear error message for invalid inputs.packages/wasm-dpp2/src/platform_address/input_output.rs (9)
1-22: LGTM! Well-structured input type with proper serialization.The struct design is clean with appropriate derives. The
#[serde(rename_all = "camelCase")]attribute ensures compatibility with JavaScript naming conventions.
24-29: LGTM! Appropriate BigInt to u64 conversion with error handling.The conversion correctly handles cases where the BigInt value exceeds
u64::MAXby returning a clear error message. This is the right approach for credit amounts that must fit in a u64.
31-52: LGTM! Robust constructor with flexible input handling.The constructor properly handles multiple address formats via
unchecked_param_typeand includes appropriate error handling for all conversions. The design allows JavaScript callers to pass addresses as PlatformAddress objects, Uint8Arrays, or bech32m strings.
54-71: LGTM! Standard getter pattern for WASM interop.The getters correctly expose the internal state:
address()returns the wrapped PlatformAddressWasm (which implements Copy based on the usage pattern)nonce()returns the primitive u32 directlyamount()converts back to BigInt for JavaScript consumption
73-93: LGTM! Internal helper methods for Rust-side usage.These methods provide convenient access for Rust code:
into_inner()provides move semantics for efficient conversion to BTreeMap entriesplatform_address(),nonce_value(), andamount_value()provide typed access without consuming self
95-138: LGTM! Consistent Output structure following the Input pattern.The
PlatformAddressOutputWasmappropriately omits the nonce field (not needed for outputs) and follows the same design patterns as the Input type for consistency.
140-155: LGTM! Consistent internal methods.The helper methods follow the same pattern as the Input type, providing efficient conversion and access methods for Rust-side code.
157-169: LGTM! Efficient conversion helpers.The functions use an efficient iterator chain to convert vectors to BTrees. The use of
BTreeMapprovides deterministic ordering, which is important for consensus-critical code.
187-195: LGTM! Useful extraction utilities.These helper functions provide clean, efficient ways to extract addresses or amounts from output collections. The implementations are straightforward and efficient.
packages/wasm-dpp2/src/identity/signer.rs (6)
1-21: LGTM! Well-structured imports and documentation.The module documentation clearly describes the purpose, and all imports are relevant to the implementation.
22-39: LGTM! Secure Debug implementation.The Debug implementation correctly hides private key material by only displaying the key count, which is a good security practice for logging and debugging.
83-102: LGTM! Clean delegation and accessor methods.The
add_key_from_wifmethod properly delegates WIF parsing toPrivateKeyWasm::from_wif(which handles errors) and then callsadd_key. The accessor methods are straightforward and well-documented.
104-179: LGTM! Robust Signer trait implementation.The implementation correctly:
- Validates key types and enforces ECDSA_HASH160-only support with clear error messages
- Looks up private keys by public key hash with proper error handling
- Uses the standard
dpp::dashcore::signer::signfunction- Creates P2pkh witnesses that rely on signature-based public key recovery (standard for ECDSA)
- Implements the predicate method
can_sign_withwithout throwing errors
181-224: LGTM! Well-designed helper methods for JS interop.The helper methods provide clean extraction of the signer from JS options objects:
try_from_optionsprovides a convenient default for the common casetry_from_options_with_fieldoffers flexibility for custom field namesTryFrom<&JsValue>implementation uses the standardIntoWasmtrait pattern- All error paths provide clear, actionable messages
66-74: The code correctly uses compressed public key format (33 bytes) for ECDSA_HASH160 keys, which aligns with Bitcoin/Dash standards. ECDSA_HASH160 is defined as RIPEMD160(SHA256(pubkey)), where the pubkey is serialized in compressed form for P2PKH addresses. Theserialize()call on line 72 returns the compressed format by default, and the hash160 result on lines 73-74 is the correct output for ECDSA_HASH160 keys used in the DPP protocol.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
packages/wasm-sdk/src/state_transitions/addresses.rs (1)
509-672: Implementation is correct with good optional key handling.The identity-to-address transfer properly:
- Validates the optional signing key exists in the identity before use
- Uses
transpose()correctly to convertOption<Result<T>>toResult<Option<T>>- Employs the appropriate
IdentitySignerfor identity key operationsMinor organizational note: The implementation appears before its supporting types and helpers (lines 580-672), which is unconventional but doesn't impact functionality.
packages/wasm-dpp2/src/platform_address/input_output.rs (1)
24-29: Consider a more descriptive error message.The error message "value must be a valid u64" is generic. Consider providing more specific feedback about why the conversion failed (e.g., "value out of range for u64" or "negative values not supported").
🔎 Proposed improvement
fn bigint_to_u64(value: BigInt) -> Result<u64, WasmDppError> { value .try_into() - .map_err(|_| WasmDppError::invalid_argument("value must be a valid u64")) + .map_err(|_| WasmDppError::invalid_argument("value must be a non-negative integer within u64 range (0 to 2^64-1)")) }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
packages/wasm-dpp2/src/lib.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-sdk/src/settings.rspackages/wasm-sdk/src/state_transitions/addresses.rspackages/wasm-sdk/src/state_transitions/broadcast.rs
✅ Files skipped from review due to trivial changes (1)
- packages/wasm-sdk/src/settings.rs
🚧 Files skipped from review as they are similar to previous changes (3)
- packages/wasm-dpp2/src/lib.rs
- packages/wasm-dpp2/src/platform_address/mod.rs
- packages/wasm-sdk/src/state_transitions/broadcast.rs
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rs
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.rs: Rust code must passcargo clippy --workspacelinter checks
Rust code must be formatted usingcargo fmt --all
**/*.rs: Use 4-space indent for Rust files
Follow rustfmt defaults and keep code clippy-clean for Rust modules
Use snake_case for Rust module names
Use PascalCase for Rust type names
Use SCREAMING_SNAKE_CASE for Rust constants
Files:
packages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-sdk/src/state_transitions/addresses.rs
🧠 Learnings (10)
📓 Common learnings
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Applies to **/swift-sdk/**/*.{swift,h,m,c} : iOS SDK must combine both Core (SPV wallet) and Platform (identity/documents) functionality in the unified SDK with proper function naming: `dash_core_sdk_*` prefix for Core functions, `dash_sdk_*` prefix for Platform functions, and `dash_unified_sdk_*` prefix for unified functions
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WASM bindings to connect Rust and JavaScript code
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json via the loadApiDefinitions() function that fetches './api-definitions.json'. The UI doesn't have hardcoded transition definitions - instead it populates categories, types, inputs, and labels from this JSON configuration file at runtime.
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json rather than being hardcoded in the HTML file. The UI loads transition categories, types, inputs, and labels from this JSON configuration file.
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WebAssembly as a bridge between Rust and JavaScript implementations
Learnt from: thephez
Repo: dashpay/platform PR: 2754
File: packages/wasm-sdk/api-definitions.json:1285-1285
Timestamp: 2025-09-03T19:33:21.688Z
Learning: In packages/wasm-sdk/api-definitions.json, thephez prefers to keep the existing "ripemd160hash20bytes1234" placeholder for ECDSA_HASH160 data field in documentation examples rather than using a valid base64-encoded format, maintaining consistency with the previous documentation approach.
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WASM bindings to connect Rust and JavaScript code
Applied to files:
packages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2024-11-20T10:01:50.837Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2257
File: packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs:94-94
Timestamp: 2024-11-20T10:01:50.837Z
Learning: In `packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs`, when converting with `PublicKey::try_from`, it's acceptable to use `.expect()` to handle potential conversion errors.
Applied to files:
packages/wasm-dpp2/src/platform_address/signer.rs
📚 Learning: 2024-11-28T13:49:17.301Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2317
File: packages/rs-dapi-client/src/address_list.rs:175-180
Timestamp: 2024-11-28T13:49:17.301Z
Learning: In Rust code in `packages/rs-dapi-client/src/address_list.rs`, do not change the interface of deprecated methods like `add_uri`, even to fix potential panics.
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WebAssembly as a bridge between Rust and JavaScript implementations
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2024-10-18T15:39:51.172Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2254
File: packages/rs-sdk/src/sdk.rs:585-585
Timestamp: 2024-10-18T15:39:51.172Z
Learning: The 'platform' project uses Rust version 1.80, so code in 'packages/rs-sdk' can use features available in Rust 1.80, such as the `abs_diff()` method.
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2025-07-28T20:00:08.502Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Applied to files:
packages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2025-09-02T13:30:17.703Z
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json via the loadApiDefinitions() function that fetches './api-definitions.json'. The UI doesn't have hardcoded transition definitions - instead it populates categories, types, inputs, and labels from this JSON configuration file at runtime.
Applied to files:
packages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2025-09-02T13:30:17.703Z
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json rather than being hardcoded in the HTML file. The UI loads transition categories, types, inputs, and labels from this JSON configuration file.
Applied to files:
packages/wasm-sdk/src/state_transitions/addresses.rs
📚 Learning: 2024-10-09T00:22:57.778Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2201
File: packages/rs-platform-version/src/version/v2.rs:1186-1188
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the `IdentityTransitionVersions` structure within `packages/rs-platform-version/src/version/v2.rs`, the field `credit_withdrawal` does not need the `identity_` prefix since it is already encompassed within identity state transitions.
Applied to files:
packages/wasm-sdk/src/state_transitions/addresses.rs
🧬 Code graph analysis (3)
packages/wasm-dpp2/src/platform_address/signer.rs (2)
packages/wasm-dpp2/src/identity/signer.rs (13)
fmt(34-38)new(45-49)add_key(57-81)try_from(218-223)struct_name(93-95)key_count(99-101)sign(105-139)sign_create_witness(141-162)can_sign_with(164-178)inner(183-185)try_from_options(192-194)try_from_options_with_field(200-212)value(219-220)packages/wasm-dpp2/src/platform_address/address.rs (13)
new(199-204)try_from(47-51)try_from(57-90)try_from(96-98)try_from(104-109)struct_name(188-190)from(27-29)from(33-35)from(39-41)hash(250-252)inner(319-321)value(65-67)value(78-78)
packages/wasm-dpp2/src/platform_address/input_output.rs (1)
packages/wasm-dpp2/src/platform_address/address.rs (11)
value(65-67)value(78-78)new(199-204)try_from(47-51)try_from(57-90)try_from(96-98)try_from(104-109)from(27-29)from(33-35)from(39-41)into_inner(324-326)
packages/wasm-sdk/src/state_transitions/addresses.rs (4)
packages/wasm-dpp2/src/platform_address/input_output.rs (6)
address(56-58)address(114-116)outputs_to_btree_map(133-137)outputs_to_optional_btree_map(143-153)new(39-52)new(99-110)packages/wasm-sdk/src/queries/utils.rs (1)
deserialize_required_query(11-28)packages/wasm-dpp2/src/identity/signer.rs (4)
new(45-49)value(219-220)try_from_options(192-194)try_from_options_with_field(200-212)packages/wasm-sdk/src/error.rs (3)
generic(71-73)invalid_argument(75-77)not_found(83-85)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: Rust packages (wasm-sdk) / Linting
- GitHub Check: Rust packages (wasm-sdk) / Tests
- GitHub Check: Build Docker images (RS-DAPI, rs-dapi, rs-dapi) / Build RS-DAPI image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build JS packages / Build JS
- GitHub Check: Rust crates security audit
🔇 Additional comments (26)
packages/wasm-dpp2/src/platform_address/signer.rs (10)
1-23: LGTM: Clean struct definition with proper WASM bindings.The use of
BTreeMapensures deterministic ordering of keys, which is appropriate for cryptographic operations. The struct is well-documented and follows proper wasm_bindgen patterns.
25-31: Good security practice: Debug output excludes sensitive key material.The Debug implementation correctly avoids exposing private keys, showing only the key count. This matches the pattern used in IdentitySigner.
58-67: LGTM: Standard getter methods.Both
struct_nameandkey_countare correctly implemented following established patterns.
69-77: LGTM: Correct key existence check.The
has_keymethod properly converts the address and checks for key existence.
79-97: LGTM: Correct JS interop for exposing key data.The
get_private_keys_bytesmethod properly constructs a JavaScript-friendly array structure with address hashes and private key bytes. The conversion fromPlatformAddressWasmtoPlatformAddressis valid, and error handling for Reflect operations is appropriate.
100-117: LGTM: Correct sign implementation.The
signmethod properly:
- Looks up the private key by address
- Provides a helpful error message with the address hash
- Uses the DPP dashcore signer for the actual signing operation
- Returns the signature in the expected format
119-132: LGTM: Appropriate witness creation with clear P2SH exclusion.The
sign_create_witnessmethod correctly creates a witness for P2PKH addresses and explicitly rejects P2SH addresses with a clear error message. This design choice is intentional and well-communicated.
134-138: LGTM: Simple and correct capability check.The
can_sign_withmethod correctly checks if the signer has a private key for the given address.
140-177: LGTM: Well-designed helper methods.The accessor methods and options extraction helpers follow the established pattern from
IdentitySigner. The error handling is appropriate, and the documentation clearly explains the intended use cases.
179-188: LGTM: Standard WASM conversion implementation.The
TryFrom<&JsValue>implementation correctly uses theto_wasmhelper and provides a clear error message. The type name matches the value returned bystruct_name().packages/wasm-sdk/src/state_transitions/addresses.rs (8)
1-28: LGTM! Well-structured imports and documentation.The module documentation clearly describes the purpose, and all imports are relevant to the address-based state transition functionality.
29-52: Helper function is well-implemented with appropriate error handling.The
address_infos_to_js_maphelper correctly converts SDK results to JavaScript Map format and provides clear error messages when address info is unexpectedly missing after an operation.
54-197: Well-implemented transfer operation with proper validation and error handling.The address funds transfer implementation follows a clean pattern:
- Validates required inputs/outputs
- Properly extracts and converts all options
- Uses SDK methods correctly
- Provides comprehensive TypeScript interface documentation
199-337: LGTM! Identity top-up implementation is robust.The implementation correctly:
- Fetches the identity before attempting top-up
- Validates inputs are provided
- Returns appropriate
not_founderror when identity doesn't exist- Converts the new balance to BigInt for JavaScript compatibility
339-508: Excellent implementation with comprehensive documentation.The withdrawal implementation handles the complexity well:
- Supports optional change outputs for remaining credits
- Includes pooling strategies for optimizing withdrawal batching
- Properly extracts and validates the Core output script
- TypeScript documentation clearly explains all options including pooling behavior
674-831: Asset lock funding implementation is well-structured.This complex operation correctly:
- Extracts and validates the asset lock proof and private key
- Uses
outputs_to_optional_btree_mapfor optional credit amounts (allowing automatic distribution from the asset lock)- Leverages the
TopUpAddresstrait pattern for extensible top-up sources- Provides clear documentation on asset lock proof types
833-1006: Excellent implementation of the most complex operation.Identity creation from addresses correctly handles:
- Dual signer requirements (identity keys and address inputs)
- Uses
try_from_options_with_fieldto extract named signers, avoiding field name conflicts- Supports optional change output for returning unused credits
- Comprehensive TypeScript documentation explaining the two-signer pattern
The implementation demonstrates good understanding of the SDK's
PutIdentitytrait pattern.
1-1006: Overall: High-quality WASM bindings with excellent documentation.This file demonstrates strong understanding of:
- WASM bindgen patterns for Rust-JavaScript interop
- Trait-based SDK design with proper method delegation
- Comprehensive input validation and error handling
- TypeScript interface definitions that match the Rust implementation
The consistent pattern across all six operations (deserialize → validate → extract components → call SDK → convert result) makes the code maintainable and predictable.
packages/wasm-dpp2/src/platform_address/input_output.rs (8)
1-9: LGTM!The imports are well-organized and appropriate for WASM bindings with JavaScript interop. All necessary types are included.
11-22: LGTM!The struct definition follows WASM binding best practices with appropriate attributes, derives, and clear documentation.
31-71: LGTM!The constructor and getter implementations are correct, with proper error handling and type conversions for JavaScript interop.
73-78: LGTM!The
into_innermethod provides a clean conversion to native types for internal Rust operations.
80-90: LGTM!The struct definition is consistent with
PlatformAddressInputWasmand follows WASM binding best practices.
92-123: LGTM!The implementation follows the same correct patterns as
PlatformAddressInputWasmwith appropriate error handling.
125-130: LGTM!The
into_innermethod provides clean conversion to native types.
132-137: LGTM!The function provides a clean, idiomatic conversion from Vec to BTreeMap for internal Rust usage.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs (1)
262-262: Fix Chai assertion syntax error.The
existproperty should not be invoked as a function. In Chai,existis a property, not a method.🔎 Proposed fix
- expect(result.identity).to.exist(); + expect(result.identity).to.exist;packages/js-evo-sdk/src/addresses/facade.ts (1)
83-86: Return type does not match test expectations.The declared return type
Promise<Map<wasm.PlatformAddress, wasm.PlatformAddressInfo>>contradicts the test stubs which return a discriminated union object with atypefield ('VerifiedAddressInfos'or'Success'). Update the return type to match the actual WASM SDK return shape.
🧹 Nitpick comments (1)
packages/wasm-dpp2/src/platform_address/input_output.rs (1)
24-29: Consider more specific error message for BigInt conversion.The error message could be more informative about what went wrong (e.g., negative value, overflow).
🔎 Optional improvement
fn bigint_to_u64(value: BigInt) -> Result<u64, WasmDppError> { value .try_into() - .map_err(|_| WasmDppError::invalid_argument("value must be a valid u64")) + .map_err(|_| WasmDppError::invalid_argument("value must be a non-negative integer that fits in u64")) }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (18)
packages/js-evo-sdk/src/addresses/facade.tspackages/js-evo-sdk/tests/.eslintrc.ymlpackages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/rs-dpp/src/address_funds/platform_address.rspackages/wasm-dpp2/src/identity/model.rspackages/wasm-dpp2/src/identity/signer.rspackages/wasm-dpp2/src/identity/transitions/credit_withdrawal_transition.rspackages/wasm-dpp2/src/identity/transitions/pooling.rspackages/wasm-dpp2/src/lib.rspackages/wasm-dpp2/src/platform_address/fee_strategy.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/platform_address/mod.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/tests/unit/AddressFundsTransfer.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjspackages/wasm-sdk/src/lib.rspackages/wasm-sdk/src/settings.rs
🚧 Files skipped from review as they are similar to previous changes (7)
- packages/wasm-dpp2/src/identity/transitions/credit_withdrawal_transition.rs
- packages/wasm-dpp2/src/platform_address/mod.rs
- packages/wasm-sdk/src/settings.rs
- packages/wasm-dpp2/tests/unit/AddressFundsTransfer.spec.mjs
- packages/wasm-dpp2/src/identity/model.rs
- packages/wasm-dpp2/src/identity/transitions/pooling.rs
- packages/wasm-dpp2/src/identity/signer.rs
🧰 Additional context used
📓 Path-based instructions (3)
**/*.rs
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.rs: Rust code must passcargo clippy --workspacelinter checks
Rust code must be formatted usingcargo fmt --all
**/*.rs: Use 4-space indent for Rust files
Follow rustfmt defaults and keep code clippy-clean for Rust modules
Use snake_case for Rust module names
Use PascalCase for Rust type names
Use SCREAMING_SNAKE_CASE for Rust constants
Files:
packages/wasm-sdk/src/lib.rspackages/rs-dpp/src/address_funds/platform_address.rspackages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/platform_address/fee_strategy.rspackages/wasm-dpp2/src/lib.rs
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{js,jsx,ts,tsx}: Use 2-space indent for JS/TS files
Use camelCase for variables and functions in JS/TS
Use PascalCase for class names in JS/TS
Use ESLint with Airbnb/TypeScript rules for JS/TS files
Files:
packages/js-evo-sdk/src/addresses/facade.ts
packages/**/!(node_modules)/**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Use kebab-case for filenames within JS packages
Files:
packages/js-evo-sdk/src/addresses/facade.ts
🧠 Learnings (32)
📓 Common learnings
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Applies to **/swift-sdk/**/*.{swift,h,m,c} : iOS SDK must combine both Core (SPV wallet) and Platform (identity/documents) functionality in the unified SDK with proper function naming: `dash_core_sdk_*` prefix for Core functions, `dash_sdk_*` prefix for Platform functions, and `dash_unified_sdk_*` prefix for unified functions
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WASM bindings to connect Rust and JavaScript code
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WebAssembly as a bridge between Rust and JavaScript implementations
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use Rust for core platform components (Drive, DAPI server, DPP implementation)
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json via the loadApiDefinitions() function that fetches './api-definitions.json'. The UI doesn't have hardcoded transition definitions - instead it populates categories, types, inputs, and labels from this JSON configuration file at runtime.
Learnt from: lklimek
Repo: dashpay/platform PR: 2405
File: packages/wasm-sdk/src/lib.rs:13-17
Timestamp: 2025-01-23T09:43:25.080Z
Learning: The codebase uses tracing_wasm for WebAssembly tracing as it provides sufficient functionality for the project's needs.
Learnt from: thephez
Repo: dashpay/platform PR: 2739
File: packages/wasm-sdk/test/ui-automation/tests/state-transitions.spec.js:1-171
Timestamp: 2025-09-02T13:30:17.703Z
Learning: In packages/wasm-sdk/index.html, state transition definitions are loaded dynamically from api-definitions.json rather than being hardcoded in the HTML file. The UI loads transition categories, types, inputs, and labels from this JSON configuration file.
Learnt from: lklimek
Repo: dashpay/platform PR: 2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: lklimek
Repo: dashpay/platform PR: 2254
File: packages/rs-sdk/src/sdk.rs:585-585
Timestamp: 2024-10-18T15:39:51.172Z
Learning: The 'platform' project uses Rust version 1.80, so code in 'packages/rs-sdk' can use features available in Rust 1.80, such as the `abs_diff()` method.
Learnt from: lklimek
Repo: dashpay/platform PR: 2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` is currently only used in tests, and its WebAssembly implementation is deferred until there's a user request for it.
📚 Learning: 2025-11-25T13:10:47.943Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T13:10:47.943Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Use ESLint with Airbnb/TypeScript rules for JS/TS files
Applied to files:
packages/js-evo-sdk/tests/.eslintrc.yml
📚 Learning: 2025-11-25T13:10:47.943Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T13:10:47.943Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Use 2-space indent for JS/TS files
Applied to files:
packages/js-evo-sdk/tests/.eslintrc.yml
📚 Learning: 2024-12-03T05:49:08.409Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2365
File: packages/dashmate/src/listr/tasks/ssl/VerificationServer.js:6-6
Timestamp: 2024-12-03T05:49:08.409Z
Learning: The project requires Node.js version 20 or higher, so features available from Node.js 20 onwards can be used without concern for backward compatibility.
Applied to files:
packages/js-evo-sdk/tests/.eslintrc.yml
📚 Learning: 2024-10-18T15:37:36.387Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2024-10-18T15:37:21.329Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2025-07-28T20:00:08.502Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-dpp2/src/lib.rspackages/js-evo-sdk/src/addresses/facade.ts
📚 Learning: 2025-10-29T11:37:57.299Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2818
File: packages/dashmate/test/unit/templates/dynamicCompose.spec.js:1-4
Timestamp: 2025-10-29T11:37:57.299Z
Learning: In the dashpay/platform repository's dashmate package (packages/dashmate), test files do not need to import `expect` from chai because test/bootstrap.js sets it up globally with `global.expect = expect;`. The bootstrap file is automatically loaded by Mocha.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2025-06-18T03:44:14.385Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2673
File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_update/mod.rs:1164-1197
Timestamp: 2025-06-18T03:44:14.385Z
Learning: QuantumExplorer determined that a CodeRabbit suggestion about fixing signable_bytes calculation in identity update tests with contract-bound keys was incorrect - the code flow is working as intended without the suggested changes.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs
📚 Learning: 2024-11-06T07:27:01.722Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs
📚 Learning: 2025-02-10T11:26:36.709Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2025-07-28T20:00:24.323Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/docs.html:2359-2383
Timestamp: 2025-07-28T20:00:24.323Z
Learning: In packages/wasm-sdk/docs.html, QuantumExplorer confirmed that placeholder private keys in documentation examples are acceptable as they are not real keys, though field name accuracy for the SDK API should still be maintained.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjspackages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjspackages/wasm-dpp2/src/platform_address/signer.rs
📚 Learning: 2024-10-10T10:30:19.883Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2232
File: packages/rs-sdk/src/mock/sdk.rs:90-95
Timestamp: 2024-10-10T10:30:19.883Z
Learning: In `packages/rs-sdk/src/mock/sdk.rs`, the `load_expectations` method in `MockDashPlatformSdk` remains asynchronous (`async`) for backward compatibility, even though it now delegates to the synchronous `load_expectations_sync` method.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2024-10-30T11:19:59.163Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs
📚 Learning: 2024-12-05T12:59:22.044Z
Learnt from: lklimek
Repo: dashpay/platform PR: 1924
File: packages/rs-dapi-client/src/request_settings.rs:74-74
Timestamp: 2024-12-05T12:59:22.044Z
Learning: The `AppliedRequestSettings` struct in `packages/rs-dapi-client/src/request_settings.rs` is intended for internal use within the monorepo and is not part of the public API.
Applied to files:
packages/wasm-sdk/src/lib.rs
📚 Learning: 2025-09-03T14:41:16.196Z
Learnt from: thephez
Repo: dashpay/platform PR: 2754
File: packages/wasm-sdk/AI_REFERENCE.md:766-766
Timestamp: 2025-09-03T14:41:16.196Z
Learning: In packages/wasm-sdk/, the AI_REFERENCE.md file is auto-generated from api-definitions.json. Any documentation fixes should be made in api-definitions.json rather than directly in AI_REFERENCE.md, as manual changes to AI_REFERENCE.md would be overwritten during regeneration.
Applied to files:
packages/wasm-sdk/src/lib.rs
📚 Learning: 2024-11-20T20:43:41.185Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2257
File: packages/rs-drive-abci/tests/strategy_tests/masternodes.rs:212-220
Timestamp: 2024-11-20T20:43:41.185Z
Learning: In `packages/rs-drive-abci/tests/strategy_tests/masternodes.rs`, the pattern of generating a `PrivateKey`, converting it to bytes, and reconstructing a `BlsPrivateKey` from those bytes is intentional. Avoid suggesting to simplify this code in future reviews.
Applied to files:
packages/rs-dpp/src/address_funds/platform_address.rspackages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2024-11-20T10:01:50.837Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2257
File: packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs:94-94
Timestamp: 2024-11-20T10:01:50.837Z
Learning: In `packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs`, when converting with `PublicKey::try_from`, it's acceptable to use `.expect()` to handle potential conversion errors.
Applied to files:
packages/rs-dpp/src/address_funds/platform_address.rspackages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/platform_address/signer.rs
📚 Learning: 2024-11-20T16:05:40.200Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2257
File: packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs:148-151
Timestamp: 2024-11-20T16:05:40.200Z
Learning: In `packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs`, when converting public keys from `QuorumForSavingV0` to `VerificationQuorum`, it's acceptable to use `.expect()` for public key conversion, as the conversion has been verified and panics are acceptable in this context.
Applied to files:
packages/rs-dpp/src/address_funds/platform_address.rspackages/wasm-dpp2/src/platform_address/signer.rs
📚 Learning: 2024-10-10T05:10:50.059Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2235
File: packages/rs-dpp/src/identity/identity_public_key/v0/methods/mod.rs:8-9
Timestamp: 2024-10-10T05:10:50.059Z
Learning: In the codebase, importing `Secp256k1` from `dashcore::key::Secp256k1` is acceptable.
Applied to files:
packages/rs-dpp/src/address_funds/platform_address.rs
📚 Learning: 2024-10-21T01:03:42.458Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2227
File: packages/rs-dpp/src/core_types/validator_set/v0/mod.rs:299-299
Timestamp: 2024-10-21T01:03:42.458Z
Learning: In the `test_serialize_deserialize_validator_set_v0` test within `packages/rs-dpp/src/core_types/validator_set/v0/mod.rs`, deterministic BLS keys cannot be easily used; therefore, using `BlsPublicKey::generate()` is acceptable.
Applied to files:
packages/rs-dpp/src/address_funds/platform_address.rspackages/wasm-dpp2/src/platform_address/signer.rs
📚 Learning: 2024-10-09T00:22:57.778Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Applied to files:
packages/rs-dpp/src/address_funds/platform_address.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WASM bindings to connect Rust and JavaScript code
Applied to files:
packages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/platform_address/signer.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/platform_address/fee_strategy.rspackages/wasm-dpp2/src/lib.rs
📚 Learning: 2025-11-25T13:10:23.481Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:23.481Z
Learning: Use WebAssembly as a bridge between Rust and JavaScript implementations
Applied to files:
packages/wasm-dpp2/src/private_key.rspackages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/lib.rs
📚 Learning: 2025-09-03T19:33:21.688Z
Learnt from: thephez
Repo: dashpay/platform PR: 2754
File: packages/wasm-sdk/api-definitions.json:1285-1285
Timestamp: 2025-09-03T19:33:21.688Z
Learning: In packages/wasm-sdk/api-definitions.json, thephez prefers to keep the existing "ripemd160hash20bytes1234" placeholder for ECDSA_HASH160 data field in documentation examples rather than using a valid base64-encoded format, maintaining consistency with the previous documentation approach.
Applied to files:
packages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs
📚 Learning: 2025-09-03T15:44:33.889Z
Learnt from: thephez
Repo: dashpay/platform PR: 2754
File: packages/wasm-sdk/docs.html:0-0
Timestamp: 2025-09-03T15:44:33.889Z
Learning: In packages/wasm-sdk/docs.html, thephez prefers to keep realistic-looking private key placeholders in documentation examples rather than using obvious fake placeholders, despite secret scanner warnings.
Applied to files:
packages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjspackages/wasm-dpp2/src/platform_address/signer.rs
📚 Learning: 2025-11-25T13:10:38.019Z
Learnt from: CR
Repo: dashpay/platform PR: 0
File: packages/swift-sdk/SwiftExampleApp/CLAUDE.md:0-0
Timestamp: 2025-11-25T13:10:38.019Z
Learning: Applies to packages/swift-sdk/SwiftExampleApp/**/*.swift : Always validate private keys match their public keys using KeyValidation.validatePrivateKeyForPublicKey before cryptographic operations
Applied to files:
packages/wasm-dpp2/src/platform_address/signer.rs
📚 Learning: 2024-11-28T13:49:17.301Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2317
File: packages/rs-dapi-client/src/address_list.rs:175-180
Timestamp: 2024-11-28T13:49:17.301Z
Learning: In Rust code in `packages/rs-dapi-client/src/address_list.rs`, do not change the interface of deprecated methods like `add_uri`, even to fix potential panics.
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2024-09-30T12:11:35.148Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2186
File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_credit_withdrawal/mod.rs:48-54
Timestamp: 2024-09-30T12:11:35.148Z
Learning: In the identity credit withdrawal transition code, the field `platform_version.drive_abci.validation_and_processing.state_transitions.identity_credit_withdrawal_state_transition.transform_into_action` is not an `Option` type, so handling `None` cases is unnecessary.
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2024-10-03T11:51:06.980Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2201
File: packages/rs-platform-version/src/version/v2.rs:1186-1188
Timestamp: 2024-10-03T11:51:06.980Z
Learning: In the `IdentityTransitionVersions` structure within `packages/rs-platform-version/src/version/v2.rs`, the field `credit_withdrawal` does not need the `identity_` prefix since it is already encompassed within identity state transitions.
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rspackages/wasm-dpp2/src/lib.rs
📚 Learning: 2024-10-29T14:40:54.727Z
Learnt from: lklimek
Repo: dashpay/platform PR: 2277
File: packages/rs-sdk/src/core/transaction.rs:0-0
Timestamp: 2024-10-29T14:40:54.727Z
Learning: In `packages/rs-sdk/src/platform/document_query.rs` and `packages/rs-sdk/src/core/transaction.rs`, certain places don't implement `IntoInner`, so direct error mappings cannot be simplified using `IntoInner`. A TODO comment has been added to address this in a future PR.
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rs
📚 Learning: 2024-11-25T07:48:09.831Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2345
File: packages/wallet-utils-contract/src/lib.rs:14-17
Timestamp: 2024-11-25T07:48:09.831Z
Learning: In the `wallet-utils-contract` (file `packages/wallet-utils-contract/src/lib.rs`), the `OWNER_ID_BYTES` constant is intentionally initialized to all zeros.
Applied to files:
packages/wasm-dpp2/src/platform_address/input_output.rs
🧬 Code graph analysis (5)
packages/wasm-dpp2/src/private_key.rs (6)
packages/wasm-dpp2/src/identity/model.rs (2)
from(21-23)from(27-29)packages/wasm-dpp2/src/platform_address/fee_strategy.rs (2)
from(60-62)from(66-68)packages/wasm-dpp2/src/platform_address/address.rs (4)
from(27-29)from(33-35)from(39-41)inner(319-321)packages/wasm-dpp2/src/state_transitions/base/state_transition.rs (3)
from(51-53)from(57-59)from(63-65)packages/wasm-dpp2/src/identity/signer.rs (1)
inner(170-172)packages/wasm-dpp2/src/platform_address/signer.rs (1)
inner(139-141)
packages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs (4)
packages/wasm-dpp2/tests/unit/PlatformAddressInput.spec.mjs (3)
wasm(3-3)addr(74-74)bech32m(24-24)packages/wasm-dpp2/tests/unit/IdentitySigner.spec.mjs (15)
wasm(3-3)testPrivateKeyWif(11-11)testPrivateKeyHex(13-13)signer(17-17)signer(25-25)signer(33-33)signer(41-41)signer(50-50)signer(62-62)signer(76-76)signer(83-83)privateKey(26-26)privateKey(34-34)privateKey(43-43)privateKey(63-63)packages/wasm-dpp2/tests/unit/PlatformAddress.spec.mjs (21)
wasm(3-3)addr(13-13)addr(22-22)addr(90-90)addr(108-108)addr(128-128)addr(156-156)addr(166-166)addr(175-175)addr(185-185)addr(195-195)addr(205-205)addr(215-215)addr(223-223)addr(231-231)bech32m(55-55)bech32m(68-68)bech32m(164-164)bech32m(216-216)bech32m(224-224)bech32m(232-232)packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs (4)
signer(82-82)signer(117-117)privateKey(79-79)privateKey(114-114)
packages/wasm-dpp2/src/platform_address/signer.rs (3)
packages/wasm-dpp2/src/identity/signer.rs (7)
try_from(207-212)sign(92-126)can_sign_with(151-165)inner(170-172)try_from_options(179-181)try_from_options_with_field(187-201)value(208-209)packages/wasm-dpp2/src/platform_address/address.rs (11)
from(27-29)from(33-35)from(39-41)try_from(47-51)try_from(57-90)try_from(96-98)try_from(104-109)hash(250-252)inner(319-321)value(65-67)value(78-78)packages/wasm-dpp2/src/private_key.rs (3)
from(18-20)from(24-26)inner(31-33)
packages/wasm-dpp2/src/platform_address/input_output.rs (2)
packages/wasm-dpp2/src/platform_address/address.rs (11)
value(65-67)value(78-78)new(199-204)try_from(47-51)try_from(57-90)try_from(96-98)try_from(104-109)from(27-29)from(33-35)from(39-41)into_inner(324-326)packages/wasm-sdk/src/error.rs (1)
invalid_argument(75-77)
packages/js-evo-sdk/src/addresses/facade.ts (2)
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs (7)
options(89-93)options(124-128)options(149-153)options(175-181)options(203-207)options(226-231)options(253-258)packages/js-evo-sdk/src/sdk.ts (1)
wasm(71-74)
🪛 Gitleaks (8.30.0)
packages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs
[high] 11-11: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
[high] 13-13: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (20)
- GitHub Check: Rust packages (wasm-sdk) / Unused dependencies
- GitHub Check: Rust packages (wasm-sdk) / Tests
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (wasm-sdk) / Linting
- GitHub Check: Rust packages (wasm-dpp2) / Unused dependencies
- GitHub Check: Rust packages (wasm-dpp2) / Linting
- GitHub Check: Rust packages (wasm-dpp2) / Tests
- GitHub Check: Rust packages (wasm-dpp) / Tests
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (dpp) / Unused dependencies
- GitHub Check: Rust packages (rs-sdk-ffi) / Tests
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (dash-sdk) / Tests
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build Docker images (RS-DAPI, rs-dapi, rs-dapi) / Build RS-DAPI image
- GitHub Check: Build JS packages / Build JS
- GitHub Check: Rust crates security audit
🔇 Additional comments (17)
packages/js-evo-sdk/tests/.eslintrc.yml (1)
5-5: ESLint configuration modernized for ES2022.The update from ES2020 to ES2022 aligns well with the project's Node.js 20+ requirement and enables support for modern JavaScript features (top-level await, static class members, logical assignment operators, etc.) that may be used in the updated SDK codebase. The addition of explicit
sourceType: modulecorrectly declares ES module syntax.Also applies to: 9-10
packages/wasm-sdk/src/lib.rs (1)
10-10: LGTM! Clean module addition.The
settingsmodule declaration follows Rust naming conventions and is correctly positioned alphabetically. Consistent with other utility modules, it's not re-exported, which is appropriate for parsing utilities that are likely used internally by wasm_bindgen functions.packages/rs-dpp/src/address_funds/platform_address.rs (3)
14-14: LGTM!The addition of
PrivateKeyto the imports is necessary for the newFrom<&PrivateKey>implementation and follows the established import pattern.
66-76: LGTM! Well-documented and correct P2PKH derivation.The implementation correctly derives a P2PKH address from a private key using the standard Bitcoin derivation (Hash160 of the compressed public key). The documentation clearly explains the derivation method, and using the
Fromtrait (rather thanTryFrom) is appropriate since the conversion is infallible for valid private keys.
633-658: LGTM! Comprehensive test coverage.The test effectively verifies the correctness of the
From<&PrivateKey>implementation by comparing the derived address against a known-good manual derivation from the public key. The use of a deterministic seed ensures reproducibility, and the assertions clearly validate both the address content and type.packages/wasm-dpp2/src/platform_address/fee_strategy.rs (1)
1-152: Well-structured WASM bindings for fee strategy.The implementation follows established patterns in the codebase with proper:
#[wasm_bindgen]attribute configuration for JS interop- Bidirectional
Fromtrait implementations- Custom
Deserializeimplementation with proper field handling and error messages- Helper functions that provide sensible defaults
packages/wasm-dpp2/src/private_key.rs (1)
14-34: Consistent additions following established patterns.The
Clonederive,Fromtrait implementations, andinner()accessor follow the same patterns used in other WASM wrapper types in this codebase (e.g.,PlatformAddressWasm,IdentityWasm,FeeStrategyStepWasm). These additions enablePrivateKeyWasmto be stored in collections and accessed for internal operations.packages/wasm-dpp2/tests/unit/PlatformAddressSigner.spec.mjs (2)
11-13: Test private keys are acceptable - ignore static analysis warning.The Gitleaks warnings on lines 11 and 13 are false positives. These are testnet WIF keys used exclusively for unit testing, not production secrets. Based on learnings, placeholder/test private keys in test files are acceptable practice in this codebase.
1-133: Comprehensive test coverage for PlatformAddressSigner.The test suite thoroughly covers:
- Empty signer construction
- Key addition from WIF, hex, and raw bytes
- Multiple key handling and duplicate key detection
- Address lookup via
hasKeywith both object and bech32m string formats- Private key bytes extraction with correct structure validation
packages/js-evo-sdk/tests/unit/facades/addresses.spec.mjs (1)
71-99: Well-structured integration tests for new facade methods.The tests properly exercise the new
AddressesFacademethods by:
- Creating realistic
PlatformAddress,PrivateKey, and signer objects- Using typed
PlatformAddressInputandPlatformAddressOutputconstructors- Verifying wasm SDK method delegation and result structure
packages/wasm-dpp2/src/lib.rs (1)
33-53: Public API surface properly extended.The new exports are well-organized:
- Core utility types (
CoreScriptWasm,IdentitySignerWasm,PoolingWasm) for cross-cutting functionality- Platform address module expansion with input/output types, signer, fee strategy, and helper functions
packages/js-evo-sdk/src/addresses/facade.ts (1)
58-257: Good facade pattern implementation with comprehensive documentation.The six new methods follow a consistent pattern:
- Acquire connected WASM SDK instance
- Delegate to corresponding WASM SDK method
- Return the result directly
The JSDoc examples demonstrate proper usage with realistic code snippets covering signer setup, input/output construction, and result handling.
packages/wasm-dpp2/src/platform_address/signer.rs (3)
50-56: Address derivation from private key correctly implemented.The
add_keymethod now derives the platform address from the private key rather than accepting them separately, which eliminates the previously flagged validation concern. This ensures the key-address relationship is always correct.
100-135: Signer trait implementation is correct.The implementation:
- Properly looks up keys by converting
PlatformAddresstoPlatformAddressWasm- Signs data using the
dpp::dashcore::signer::signfunction- Creates appropriate
AddressWitness::P2pkhfor P2PKH addresses- Correctly rejects P2SH addresses with a clear error message
161-175: Helper methods follow established patterns.The
try_from_optionsandtry_from_options_with_fieldmethods mirror the implementation inIdentitySignerWasm, providing consistent API for extracting signers from JS options objects.packages/wasm-dpp2/src/platform_address/input_output.rs (2)
127-141: Panic documentation forinto_inneris clear.The comment on line 129 properly documents that
into_inner()will panic ifamountisNone, directing users to useinto_inner_optional()for optional amounts. This is a reasonable design choice with clear documentation.
143-161: Output conversion helpers are well-designed.Both helper functions correctly convert vectors to BTreeMaps:
outputs_to_btree_map: For operations requiring amounts (will panic on None)outputs_to_optional_btree_map: For asset lock funding where amounts are optionalThe documentation clearly explains when to use each function.
Issue being fixed or feature implemented
Platform Address state transitions for JS Evo SDK
What was done?
How Has This Been Tested?
Breaking Changes
None
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
New Features
Tests
✏️ Tip: You can customize this high-level summary in your review settings.