feat: Massa network#739
Conversation
WalkthroughAdds first-class Massa blockchain support: new provider, networks, API wrapper, middlewares, UI flows (send/verify), activity handling, token addition, keyring signer, and routing. Extends core types/enums and initialization to recognize Massa accounts and tokens. Introduces a dedicated signer package and required dependencies. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant UI as Massa Send UI
participant Provider as MassaProvider
participant Network as MassaNetwork
participant API as MassaAPI (massa-web3)
participant Node as Massa Node
UI->>Provider: RPC massa_getNetwork
Provider->>Network: getCurrentNetwork()
Provider-->>UI: Network name
UI->>Provider: RPC massa_getBalance(address)
Provider->>Network: api()
Network->>API: getBalance(address)
API->>Node: balanceOf(address)
API-->>Provider: balance string
Provider-->>UI: balance
UI->>UI: Build payload (MAS or MRC20)
UI->>UI: MassaTransactionSigner(sign)
UI->>Provider: RPC send operation (serialized, signature)
Provider->>Network: api()
Network->>API: submit operation
API->>Node: submit ops
API-->>Provider: opId/status
Provider-->>UI: opId/status
sequenceDiagram
autonumber
participant DApp as UI
participant Provider as MassaProvider
participant Network as MassaNetwork
DApp->>Provider: RPC massa_setNetwork(name)
Provider->>Provider: validate name
Provider->>Network: setRequestProvider(newNetwork)
Provider-->>DApp: { success, network }
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45–60 minutes Possibly related PRs
Suggested reviewers
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 21
🔭 Outside diff range comments (3)
packages/extension/src/libs/tokens-state/index.ts (1)
35-42: Handle Massa token addresses withouttoLowerCase()The loop in
addErc20Token(and similarly inremoveErc20Token) normalizes both sides with.toLowerCase(). That’s fine for 0x-prefixed ERC20 tokens (hex addresses are case-insensitive), but Massa addresses (AS…) use Base58 and are case-sensitive. Lowercasing them will break both storage and comparison.To fix:
- Add a distinct
TokenType.MASSAenum value and ensureCustomMassaToken.typeis set to it.- In your comparison loops, branch on
t.type:
• ForERC20, keep the.toLowerCase()check.
• ForMASSA, compare the raw strings (or normalize viaAddress.fromString(addr).toString()) without altering case.Example diff in
packages/extension/src/libs/tokens-state/index.ts:for (const t of tokens!) { - if ( - t.type === TokenType.ERC20 && - (t as CustomErc20Token).address.toLowerCase() === - token.address.toLowerCase() - ) { - return false; - } + if (t.type === TokenType.ERC20) { + if ( + (t as CustomErc20Token).address.toLowerCase() === + token.address.toLowerCase() + ) { + return false; + } + } else if (t.type === TokenType.MASSA) { + // AS-prefixed Base58 addresses are case-sensitive + if ((t as CustomMassaToken).address === token.address) { + return false; + } + }Repeat the same branching in
removeErc20Token.packages/extension/src/ui/action/views/verify-transaction/index.vue (1)
28-33: Update Verify Transaction to use route.params.id, not route.query.idThe router defines
verify-transactionwithpath: '/verify-transaction/:id?', soidlives onroute.params, notroute.query. The code inpackages/extension/src/ui/action/views/verify-transaction/index.vueshould mirror the Send Transaction view by reading fromroute.params.id.Please update lines 28–33 accordingly:
- const networkName: string = route.query.id as string; + const networkName: string = route.params.id as string; getNetworkByName(networkName).then(network => { if (network) { layout.value = sendLayouts[network.provider]; } });packages/extension/src/ui/action/views/send-transaction/index.vue (1)
47-55: Unify network ID retrieval across send & verify flowsThe send-transaction view reads the network ID from
route.params.id(send-transaction/index.vue:47), whereas the verify-transaction view usesroute.query.id(verify-transaction/index.vue:28). This mismatch can cause silent layout resolution failures. Please choose one approach and update the other accordingly:• packages/extension/src/ui/action/views/send-transaction/index.vue:47
– Currently:const networkName = route.params.id as string
– Consider switching toroute.query.idor updating your router to include:idin the verify path.
• packages/extension/src/ui/action/views/verify-transaction/index.vue:28
– Currently:const networkName = route.query.id as string
– Consider switching toroute.params.idor modifying the send flow to passidas a route param.
🧹 Nitpick comments (18)
packages/signers/massa/tsconfig.json (1)
10-11: Consider using ES modules for consistency.The configuration uses CommonJS (
"module": "commonjs") while most modern TypeScript projects use ES modules. Consider if this aligns with the project's module strategy.If ES modules are preferred, apply this diff:
- "module": "commonjs", + "module": "esnext",packages/extension/src/ui/action/views/verify-transaction/index.vue (1)
15-15: Tighten typing for layout mapping and ref (Component | null).Improves type-safety and DX by using Vue’s Component type and initializing the ref to null.
Apply this diff:
-import { shallowRef } from 'vue'; +import { shallowRef, type Component } from 'vue'; @@ -const sendLayouts: Record<ProviderName, any> = { +const sendLayouts: Record<ProviderName, Component | null> = { @@ -const layout = shallowRef(); +const layout = shallowRef<Component | null>(null);Also applies to: 17-25, 26-26
packages/keyring/src/utils.ts (1)
14-20: Optional: centralize ed25519 hardened path building.You now have two near-identical cases (ed25519sol and ed25519mas) that only differ by whether “/0” is hardened. Extracting a tiny helper reduces drift and clarifies intent.
For example:
// Outside the function const ed25519HardenedPath = (basePath: string, index: number, changeHardened = false) => `${basePath}/${index}'/${changeHardened ? "0'" : '0'}`;Then:
if (type === SignerType.ed25519sol) return ed25519HardenedPath(basePath, index, false); if (type === SignerType.ed25519mas) return ed25519HardenedPath(basePath, index, true);packages/extension/src/ui/action/views/send-transaction/index.vue (1)
19-19: Strengthen typing for layout mapping and ref (Component | null).Mirrors the suggestion in verify-transaction to improve clarity and type-safety.
Apply this diff:
-import { shallowRef, ref, PropType } from 'vue'; +import { shallowRef, ref, PropType, type Component } from 'vue'; @@ -const sendLayouts: Record<ProviderName, any> = { +const sendLayouts: Record<ProviderName, Component | null> = { @@ -const layout = shallowRef(); +const layout = shallowRef<Component | null>(null);Also applies to: 23-23, 33-33
packages/extension/src/providers/massa/libs/activity-handlers/index.ts (1)
1-4: Barrel export is fine; consider a terser re-export.Compact export keeps the file minimal and avoids an intermediate import binding.
Apply this diff:
-import MassaActivity from './massa'; - -export { MassaActivity }; +export { default as MassaActivity } from './massa';packages/extension/src/providers/massa/ui/index.ts (1)
4-7: Optional: use “satisfies” for safer typing without widening.This keeps literal types intact while ensuring the shape matches UIExportOptions.
Apply this diff (requires TS >= 4.9):
-const uiExport: UIExportOptions = { - providerName: ProviderName.massa, - routes: getRoutes(ProviderName.massa), -}; +const uiExport = { + providerName: ProviderName.massa, + routes: getRoutes(ProviderName.massa), +} satisfies UIExportOptions;packages/extension/src/providers/massa/methods/index.ts (1)
14-17: Remove redundant inline middleware or add meaningful functionality.The inline middleware currently just calls
next()without adding any functionality. Either remove it or implement the promised "additional Massa-specific middleware logic".export default ( provider: BackgroundProviderInterface, ): MiddlewareFunction[] => { return [ massa_getBalance, massa_getNetwork, massa_setNetwork, - async (request, response, next) => { - // Add any additional Massa-specific middleware logic here - return next(); - }, ]; };packages/extension/src/providers/massa/libs/activity-handlers/massa.ts (1)
18-19: Consider adding a TODO comment for API integration.The comment mentions future API integration but lacks specificity about implementation timeline or requirements. Consider adding a more detailed TODO comment.
- // For now, return local activities - // In the future, this can be extended to fetch from Massa explorer API + // TODO: Implement Massa explorer API integration for fetching activities + // Current implementation relies on local storage onlypackages/signers/massa/src/libs/ed25519.ts (1)
41-48: Consider validating the privateKey parameter.While the implementation correctly derives the public key, it would be safer to validate that the privateKey buffer is exactly 32 bytes before passing it to tweetnacl.
const getPublicKey = (privateKey: Buffer, withZeroByte = true): Buffer => { + if (privateKey.length !== 32) { + throw new Error('Private key must be exactly 32 bytes'); + } const keyPair = sign.keyPair.fromSeed(privateKey); const signPk = keyPair.secretKey.subarray(32); const zero = Buffer.alloc(1, 0); return withZeroByte ? Buffer.concat([zero, Buffer.from(signPk)]) : Buffer.from(signPk); };packages/signers/massa/src/index.ts (1)
45-58: Consider more specific error handling in verify method.While catching and logging errors is good, returning false for all errors might hide important issues. Consider distinguishing between invalid signatures and other errors.
async verify( msgHash: string, sig: string, publicKey: string, ): Promise<boolean> { try { const massaPublicKey = PublicKey.fromString(publicKey); const signature = Signature.fromBytes(hexToBuffer(sig)); return massaPublicKey.verify(hexToBuffer(msgHash), signature); } catch (error) { - console.error("Massa signature verification failed:", error); + if (error instanceof Error) { + // Log the specific error for debugging + console.error("Massa signature verification failed:", error.message); + // Could potentially throw for unexpected errors vs invalid signatures + if (!error.message.includes('signature') && !error.message.includes('verify')) { + throw error; + } + } return false; } }packages/extension/src/providers/massa/ui/send-transaction/verify-transaction/index.vue (2)
237-276: Consider transaction confirmation before storing activity.Currently, the activity is stored immediately after sending, but the transaction might fail on-chain. Consider marking it as pending and updating status after confirmation.
The current implementation correctly marks transactions as pending, which is appropriate. However, consider implementing a follow-up mechanism to update the status once the transaction is confirmed or rejected on-chain.
278-292: Extract timeout durations to constants.Magic numbers for timeouts should be extracted to named constants for better maintainability.
+const OPERATION_ID_DISPLAY_DURATION = 4000; // ms +const WINDOW_CLOSE_DELAY = 3000; // ms + if (getCurrentContext() === 'popup') { setTimeout(() => { showOperationId.value = false; isProcessing.value = false; callToggleRate(); router.push({ name: 'activity', params: { id: network.value.name } }); - }, 4000); + }, OPERATION_ID_DISPLAY_DURATION); } else { setTimeout(() => { showOperationId.value = false; isProcessing.value = false; callToggleRate(); window.close(); - }, 3000); + }, WINDOW_CLOSE_DELAY); }packages/extension/src/ui/action/views/network-assets/components/custom-massa-token.vue (2)
136-146: Add null check for contractAddress in validationThe
isValidAddresscomputed property should handle empty/undefined input more defensively before attempting validation.const isValidAddress = computed(() => { - if (contractAddress.value) { + if (contractAddress.value && contractAddress.value.trim()) { try { - Address.fromString(contractAddress.value); + Address.fromString(contractAddress.value.trim()); return true; } catch (error) { return false; } } return false; });
255-257: Consider debouncing the token info fetchThe watcher triggers immediately on every keystroke which could lead to excessive API calls. Consider debouncing the fetch operation.
Add debouncing to reduce API calls:
+import { debounce } from 'lodash-es'; + +const debouncedFetchTokenInfo = debounce(fetchTokenInfo, 500); + watch(contractAddress, () => { - fetchTokenInfo(); + debouncedFetchTokenInfo(); });packages/extension/src/providers/massa/ui/send-transaction/components/send-address-input.vue (1)
145-145: Remove duplicate box-sizing declarationLine 145 has a duplicate
box-sizing: border-box;declaration that was already set on line 144.box-sizing: border-box; border: 1px solid @gray02; - box-sizing: border-box; border-radius: 10px;packages/extension/src/providers/massa/networks/massa-base.ts (2)
243-249: isValidAddress should be a regular method, not an arrow functionClass methods should use regular method syntax for consistency and potential inheritance.
- isValidAddress = (address: string): boolean => { + isValidAddress(address: string): boolean { try { Address.fromString(address); } catch (error) { return false; } return true; - }; + }
151-156: Consider batch fetching token balancesMaking individual API calls for each token balance could be inefficient. Consider implementing a batch fetch method if the API supports it.
Consider implementing a batch balance fetch method in the MassaAPI class if the Massa network supports it, which would reduce the number of API calls and improve performance when dealing with multiple tokens.
packages/extension/src/providers/massa/index.ts (1)
25-25: Type namespace preciselyNamespace is an enum; type it as ProviderName for stronger type-safety.
- namespace: string; + namespace: ProviderName;
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (51)
packages/extension/package.json(1 hunks)packages/extension/src/libs/background/index.ts(1 hunks)packages/extension/src/libs/background/types.ts(3 hunks)packages/extension/src/libs/tokens-state/index.ts(2 hunks)packages/extension/src/libs/tokens-state/types.ts(1 hunks)packages/extension/src/libs/utils/initialize-wallet.ts(3 hunks)packages/extension/src/libs/utils/networks.ts(4 hunks)packages/extension/src/providers/index.ts(2 hunks)packages/extension/src/providers/massa/index.ts(1 hunks)packages/extension/src/providers/massa/libs/activity-handlers/index.ts(1 hunks)packages/extension/src/providers/massa/libs/activity-handlers/massa.ts(1 hunks)packages/extension/src/providers/massa/libs/api.ts(1 hunks)packages/extension/src/providers/massa/methods/index.ts(1 hunks)packages/extension/src/providers/massa/methods/massa_getBalance.ts(1 hunks)packages/extension/src/providers/massa/methods/massa_getNetwork.ts(1 hunks)packages/extension/src/providers/massa/methods/massa_setNetwork.ts(1 hunks)packages/extension/src/providers/massa/networks/buildnet.ts(1 hunks)packages/extension/src/providers/massa/networks/index.ts(1 hunks)packages/extension/src/providers/massa/networks/mainnet.ts(1 hunks)packages/extension/src/providers/massa/networks/massa-base.ts(1 hunks)packages/extension/src/providers/massa/types/index.ts(1 hunks)packages/extension/src/providers/massa/ui/index.ts(1 hunks)packages/extension/src/providers/massa/ui/libs/signer.ts(1 hunks)packages/extension/src/providers/massa/ui/routes/index.ts(1 hunks)packages/extension/src/providers/massa/ui/routes/names.ts(1 hunks)packages/extension/src/providers/massa/ui/send-transaction/components/send-address-input.vue(1 hunks)packages/extension/src/providers/massa/ui/send-transaction/components/send-token-select.vue(1 hunks)packages/extension/src/providers/massa/ui/send-transaction/index.vue(1 hunks)packages/extension/src/providers/massa/ui/send-transaction/verify-transaction/index.vue(1 hunks)packages/extension/src/types/activity.ts(4 hunks)packages/extension/src/types/base-network.ts(3 hunks)packages/extension/src/types/provider.ts(4 hunks)packages/extension/src/ui/action/App.vue(2 hunks)packages/extension/src/ui/action/views/network-activity/index.vue(3 hunks)packages/extension/src/ui/action/views/network-assets/components/custom-massa-token.vue(1 hunks)packages/extension/src/ui/action/views/network-assets/index.vue(3 hunks)packages/extension/src/ui/action/views/send-transaction/index.vue(2 hunks)packages/extension/src/ui/action/views/verify-transaction/index.vue(2 hunks)packages/extension/src/ui/provider-pages/routes.ts(2 hunks)packages/keyring/package.json(1 hunks)packages/keyring/src/index.ts(2 hunks)packages/keyring/src/utils.ts(1 hunks)packages/signers/massa/package.json(1 hunks)packages/signers/massa/src/index.ts(1 hunks)packages/signers/massa/src/libs/ed25519.ts(1 hunks)packages/signers/massa/tests/sign.test.ts(1 hunks)packages/signers/massa/tsconfig.json(1 hunks)packages/signers/massa/tsconfig.paths.json(1 hunks)packages/types/package.json(1 hunks)packages/types/src/index.ts(1 hunks)packages/types/src/networks.ts(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (24)
packages/signers/massa/tests/sign.test.ts (1)
packages/signers/massa/src/index.ts (1)
MassaSigner(17-65)
packages/extension/src/providers/massa/methods/massa_getNetwork.ts (3)
packages/types/src/index.ts (1)
MiddlewareFunction(194-194)packages/extension/src/providers/massa/index.ts (1)
MassaProvider(18-92)packages/extension/src/types/provider.ts (1)
ProviderRPCRequest(185-187)
packages/extension/src/providers/massa/networks/buildnet.ts (1)
packages/extension/src/providers/massa/networks/massa-base.ts (2)
createMassaNetworkOptions(253-289)MassaNetwork(26-250)
packages/extension/src/providers/index.ts (1)
packages/extension/src/providers/massa/index.ts (1)
MassaProvider(18-92)
packages/extension/src/libs/background/types.ts (2)
packages/extension/src/providers/massa/index.ts (1)
MassaProvider(18-92)packages/extension/src/types/provider.ts (1)
SolanaProvider(169-169)
packages/extension/src/providers/massa/methods/index.ts (2)
packages/types/src/index.ts (1)
MiddlewareFunction(194-194)packages/extension/src/providers/massa/index.ts (1)
request(70-83)
packages/signers/massa/src/index.ts (3)
packages/types/src/index.ts (3)
SignerInterface(187-187)MnemonicWithExtraWord(205-205)KeyPair(191-191)packages/utils/src/index.ts (2)
bufferToHex(38-38)hexToBuffer(39-39)packages/signers/massa/src/libs/ed25519.ts (1)
derivePath(81-81)
packages/extension/src/providers/massa/libs/activity-handlers/massa.ts (1)
packages/utils/src/debug-logger.ts (1)
error(388-392)
packages/extension/src/providers/massa/types/index.ts (2)
packages/extension/src/types/base-network.ts (1)
BaseNetworkOptions(17-45)packages/extension/src/types/activity.ts (1)
Activity(141-141)
packages/keyring/src/utils.ts (3)
packages/types/src/index.ts (1)
SignerType(188-188)packages/signers/polkadot/src/index.ts (1)
SignerType(30-30)packages/keyring/src/index.ts (1)
basePath(106-111)
packages/extension/src/providers/massa/methods/massa_setNetwork.ts (3)
packages/types/src/index.ts (1)
MiddlewareFunction(194-194)packages/extension/src/types/provider.ts (1)
ProviderRPCRequest(185-187)packages/extension/src/libs/error/index.ts (1)
getCustomError(27-33)
packages/keyring/src/index.ts (2)
packages/types/src/index.ts (1)
SignerType(188-188)packages/signers/massa/src/index.ts (1)
MassaSigner(17-65)
packages/extension/src/providers/massa/methods/massa_getBalance.ts (6)
packages/types/src/index.ts (1)
MiddlewareFunction(194-194)packages/extension/src/providers/massa/index.ts (1)
MassaProvider(18-92)packages/extension/src/types/provider.ts (1)
ProviderRPCRequest(185-187)packages/extension/src/providers/massa/networks/massa-base.ts (1)
MassaNetwork(26-250)packages/extension/src/libs/error/index.ts (1)
getCustomError(27-33)packages/extension/src/providers/massa/libs/api.ts (1)
api(21-23)
packages/extension/src/types/provider.ts (1)
packages/extension/src/types/activity.ts (1)
MassaRawInfo(150-150)
packages/extension/src/providers/massa/ui/index.ts (1)
packages/extension/src/types/provider.ts (1)
UIExportOptions(189-192)
packages/extension/src/types/base-network.ts (1)
packages/extension/src/providers/massa/libs/api.ts (1)
MassaAPI(9-60)
packages/extension/src/libs/utils/initialize-wallet.ts (2)
packages/extension/src/libs/utils/accounts.ts (1)
getAccountsByNetworkName(14-44)packages/extension/src/providers/massa/types/index.ts (1)
MassaNetworks(7-7)
packages/signers/massa/src/libs/ed25519.ts (3)
packages/signers/kadena/src/libs/ed25519.ts (1)
getMasterKeyFromSeed(78-78)packages/signers/massa/src/index.ts (1)
sign(60-64)packages/keyring/src/index.ts (1)
sign(201-227)
packages/extension/src/providers/massa/networks/mainnet.ts (1)
packages/extension/src/providers/massa/networks/massa-base.ts (2)
createMassaNetworkOptions(253-289)MassaNetwork(26-250)
packages/extension/src/providers/massa/ui/libs/signer.ts (5)
packages/types/src/index.ts (1)
EnkryptAccount(202-202)packages/utils/src/index.ts (2)
hexToBuffer(39-39)bufferToHex(38-38)packages/extension/src/providers/massa/types/index.ts (1)
MassaNetworkOptions(9-15)packages/extension/src/providers/solana/libs/wallet-standard/account.ts (1)
publicKey(30-32)packages/extension/src/libs/backup-state/index.ts (1)
msgHash(36-51)
packages/extension/src/providers/massa/networks/massa-base.ts (6)
packages/extension/src/types/activity.ts (1)
Activity(141-141)packages/extension/src/providers/massa/types/index.ts (1)
MassaNetworkOptions(9-15)packages/extension/src/providers/massa/libs/activity-handlers/index.ts (1)
MassaActivity(3-3)packages/extension/src/types/provider.ts (1)
AssetsType(215-230)packages/extension/src/providers/massa/libs/api.ts (2)
api(21-23)MassaAPI(9-60)packages/types/src/index.ts (1)
SignerType(188-188)
packages/extension/src/libs/tokens-state/index.ts (1)
packages/extension/src/libs/tokens-state/types.ts (2)
CustomErc20Token(20-22)CustomMassaToken(24-26)
packages/extension/src/providers/massa/index.ts (1)
packages/extension/src/types/provider.ts (1)
ProviderRPCRequest(185-187)
packages/extension/src/libs/utils/networks.ts (3)
packages/extension/src/providers/bitcoin/types/index.ts (1)
BitcoinNetworks(5-9)packages/extension/src/providers/kadena/types/index.ts (1)
KadenaNetworks(4-7)packages/extension/src/providers/massa/types/index.ts (1)
MassaNetworks(7-7)
🔇 Additional comments (99)
packages/types/src/index.ts (1)
53-53: LGTM! Consistent with established pattern.The addition of
ed25519mas = "ed25519-mas"follows the existing naming convention for ed25519 signers and aligns with the broader Massa integration effort.packages/signers/massa/tsconfig.paths.json (1)
1-8: LGTM! Standard TypeScript path mapping configuration.The configuration correctly sets up path aliases for internal imports within the massa signer package, following TypeScript best practices.
packages/extension/src/libs/tokens-state/types.ts (1)
24-26: LGTM! Proper address format validation for Massa tokens.The
CustomMassaTokeninterface correctly uses theAS${string}type to enforce Massa-specific address format, distinguishing it from Ethereum's0x${string}format.packages/types/src/networks.ts (2)
115-116: LGTM! Consistent network naming convention.The additions follow the established pattern and properly distinguish between mainnet and buildnet (testnet) environments.
186-186: LGTM! Proper CoingeckoPlatform integration.The addition of
Massa = "massa"aligns with Coingecko's platform identifier and enables price data integration for Massa tokens.packages/extension/src/providers/massa/networks/index.ts (1)
1-8: LGTM! Clean network mapping structure.The mapping correctly associates the new NetworkNames enum values with their respective network implementations, following the established pattern used by other blockchain providers.
packages/extension/src/providers/massa/networks/mainnet.ts (2)
5-14: LGTM! Comprehensive mainnet configuration.The mainnet options are properly configured with:
- Correct Massa explorer URLs with placeholder patterns
- Proper mainnet node endpoint from massa-web3
- Correct mainnet chain ID
- Valid CoingeckoID for price integration
16-18: LGTM! Proper network instantiation.The MassaNetwork instance is correctly created using the factory pattern from the base class, maintaining consistency with the extension's architecture.
packages/extension/src/providers/massa/methods/massa_getNetwork.ts (3)
1-4: LGTM! Imports are properly structured.The imports follow the expected pattern and properly reference the required types and provider class.
6-20: LGTM! Solid middleware implementation with proper error handling.The middleware correctly checks the method name, returns the network name from the provider context, and includes fallback error handling with a sensible default.
22-22: LGTM! Clean default export.The export follows the established pattern for middleware functions.
packages/extension/src/providers/massa/networks/buildnet.ts (3)
1-4: LGTM! Imports are correctly structured.All necessary imports are present and follow the established patterns from other network configurations.
5-15: LGTM! Network configuration is properly structured.The buildnet configuration correctly uses the
createMassaNetworkOptionshelper with appropriate parameters for a testnet environment:
- Uses
NetworkNames.MassaBuildnetfor consistent naming- Properly marks as testnet with
isTestNetwork: true- Uses buildnet-specific explorer URLs and API endpoint
- Correctly references the buildnet chain ID and coingecko ID
17-19: LGTM! Network instantiation and export are correct.The network is properly instantiated with the configured options and exported as the default export.
packages/extension/src/libs/tokens-state/index.ts (2)
9-9: LGTM! Import addition aligns with the extended functionality.The
CustomMassaTokenimport is necessary for the updated method signature.
26-29: LGTM! Method signature extension is well-designed.The union type
CustomErc20Token | CustomMassaTokenallows the method to handle both token types while maintaining backward compatibility.packages/extension/src/providers/massa/ui/routes/names.ts (3)
1-2: LGTM! Import is correctly structured.The Vue Router import is appropriate for defining route records.
3-14: LGTM! Route definitions are properly structured.The routes follow the established patterns with:
- Consistent path naming
- Provider-specific route names (
massa-send,massa-verify)- Lazy-loaded components using dynamic imports
16-16: LGTM! Clean default export.The export follows the established pattern for route configurations.
packages/extension/src/types/activity.ts (4)
9-9: LGTM! Import is correctly added.The
OperationStatusimport from Massa Web3 library is appropriate for defining Massa-specific activity information.
95-95: LGTM! Type alias is well-defined.The
MassaRawInfotype alias properly maps toOperationStatusfrom the Massa Web3 library, following the pattern of other blockchain-specific raw info types.
134-135: LGTM! Union type extension is correct.The addition of
MassaRawInfoto therawInfounion type properly extends activity support for Massa blockchain transactions.
150-150: LGTM! Export addition is consistent.The
MassaRawInfoexport follows the established pattern for other raw info types.packages/signers/massa/package.json (5)
1-15: LGTM! Package metadata is properly structured.The package configuration follows standard practices with appropriate name, version, description, and publish configuration.
16-23: LGTM! Build scripts are well-configured.The scripts use appropriate tools:
tsupfor building with ESM/CJS output and type declarationsprettierfor code formattingvitestfor testing- Node engine requirement is reasonable
24-31: LGTM! Dependencies are appropriate for a Massa signer.The dependencies include:
- Internal workspace packages for types and utilities
- Massa Web3 library for blockchain interactions
bip39for mnemonic handlingtweetnaclfor cryptographic operationsvarintfor variable-length integer encoding
32-52: LGTM! Development dependencies are comprehensive.The dev dependencies include all necessary tools for TypeScript development, linting, testing, and building.
53-60: LGTM! Repository metadata is complete.The repository, author, and license information are properly configured.
packages/keyring/package.json (1)
28-28: LGTM! Massa signer dependency properly added.The addition of
@enkryptcom/signer-massaas a workspace dependency is correctly configured and enables Massa blockchain support in the keyring package.packages/extension/src/ui/action/views/verify-transaction/index.vue (1)
11-11: Massa verify layout is correctly wired into the mapping.Import path and mapping entry look correct and consistent with other providers.
packages/keyring/src/utils.ts (1)
17-19: Massa derivation path is correct and fully hardened
- The
basePathfor Massa comes frompackages/extension/src/providers/massa/networks/massa-base.tsand is defined as
"m/44'/632'"(BIP-44 coin type 632).pathParserreturns
${basePath}/${index}'/0'
which for index 0 yields"m/44'/632'/0'/0'", matching the paths used insign.test.ts.- Existing tests in
packages/signers/massa/tests/sign.test.tsconfirm the change segment must be hardened.No code changes required.
packages/extension/src/providers/index.ts (1)
6-6: Provider registration for Massa looks correct.Import and mapping entry align with existing provider patterns. This should allow BackgroundHandler to instantiate Massa providers via Providers[_provider].
Also applies to: 15-16
packages/extension/src/libs/background/index.ts (1)
51-52: Per-tab provider map updated for Massa — good.Adding [ProviderName.massa]: {} ensures tab-scoped provider instances can be stored and retrieved like other providers.
packages/extension/src/ui/provider-pages/routes.ts (1)
9-9: Massa UI routes are properly registered.Import and inclusion in uiProviders will fold Massa routes into the main router as expected.
Also applies to: 18-19
packages/extension/src/ui/action/views/send-transaction/index.vue (1)
15-16: Massa send-transaction layout is correctly wired.Import path and mapping entry look consistent with existing providers.
Also applies to: 29-30
packages/extension/src/providers/massa/ui/index.ts (1)
1-10: UI export for Massa is correct.providerName and routes are set as expected; this integrates Massa routes via provider-pages/routes.ts.
packages/extension/src/libs/background/types.ts (3)
6-6: LGTM! Massa provider import added correctly.The import follows the same pattern as other provider imports and is properly typed.
16-16: LGTM! TabProviderType union extended correctly.MassaProvider is correctly added to the union type for tab providers, maintaining consistency with the existing pattern.
26-26: LGTM! ProviderType union extended correctly.The typeof MassaProvider is correctly added to the ProviderType union, consistent with the existing typing pattern.
packages/keyring/src/index.ts (2)
22-22: LGTM! MassaSigner import follows established pattern.The import is consistent with other signer imports and uses the correct workspace package reference.
55-55: LGTM! Massa signer correctly registered in keyring.The MassaSigner is properly registered under SignerType.ed25519mas, following the same pattern as other signers. This enables the keyring to handle Massa key operations through the dedicated signer implementation.
packages/extension/src/types/provider.ts (3)
36-36: LGTM! Massa provider name added correctly.The ProviderName enum is properly extended with the massa entry, maintaining consistency with existing providers.
73-73: LGTM! Massa provider type added correctly.The ProviderType enum is properly extended with the massa entry, following the established pattern.
150-150: LGTM! MassaRawInfo correctly added to transaction status union.The getTransactionStatus return type is properly extended to include MassaRawInfo, enabling Massa transaction status handling throughout the provider interface.
packages/extension/src/ui/action/App.vue (2)
214-215: LGTM! Massa buy link correctly configured.The Massa network case is properly handled with a specific buy URL, maintaining consistency with other network-specific buy links.
325-331: LGTM! Selected address persistence logic improved.The logic to fetch and restore the previously selected address when switching networks enhances user experience by maintaining address selection state. The implementation correctly handles the case where no previous selection exists.
packages/extension/src/libs/utils/initialize-wallet.ts (3)
7-7: LGTM! MassaNetworks import added correctly.The import follows the established pattern for other network imports and is properly positioned.
27-29: LGTM! Massa account filtering logic added correctly.The logic to fetch and filter Massa accounts follows the same pattern as other network types, maintaining consistency across the initialization flow.
65-71: LGTM! Default Massa account creation implemented correctly.The default Massa account creation follows the established pattern used for other networks, using the appropriate network configuration (mainnet basePath and signer) and meaningful account name.
packages/extension/src/ui/action/views/network-activity/index.vue (2)
71-71: LGTM! MassaRawInfo import added correctly.The import is properly positioned with other activity-related imports and follows the established pattern.
83-83: LGTM! OperationStatus import added correctly.The import from @massalabs/massa-web3 is properly positioned and necessary for Massa transaction status handling.
packages/extension/src/providers/massa/libs/activity-handlers/massa.ts (1)
1-27: LGTM! Clean activity handler implementation with proper error handling.The implementation follows the established pattern for activity handlers in the extension, properly implements the ActivityHandlerType interface, and includes appropriate error handling with logging.
packages/extension/src/libs/utils/networks.ts (6)
16-17: LGTM! Massa network imports added correctly.The imports follow the established pattern for other blockchain providers in the codebase.
25-25: LGTM! Massa provider correctly added to network registry.The Massa provider is properly integrated into the providerNetworks mapping, maintaining consistency with other providers.
40-41: LGTM! Massa networks properly added to aggregated list.The concatenation follows the established pattern and maintains the correct order in the network list.
75-82: LGTM! Default network constants follow established patterns.The DEFAULT_MASSA_NETWORK_NAME and DEFAULT_MASSA_NETWORK constants are consistent with other blockchain providers in the codebase.
88-88: LGTM! Massa added to popular networks list.The addition of NetworkNames.Massa to the POPULAR_NAMES array is appropriate for showcasing the new blockchain support.
111-112: LGTM! Massa exports properly added.The DEFAULT_MASSA_NETWORK and DEFAULT_MASSA_NETWORK_NAME exports maintain consistency with the established export pattern.
packages/extension/src/providers/massa/methods/massa_getBalance.ts (5)
1-6: LGTM! Proper imports for middleware implementation.All necessary dependencies are imported correctly, including the Massa-specific types and utilities.
8-14: LGTM! Middleware signature and routing correctly implemented.The middleware properly implements the MiddlewareFunction interface and correctly delegates to the next middleware when the method doesn't match.
17-22: LGTM! Proper address validation with clear error messages.The implementation correctly validates both the presence of the address parameter and its validity using the network's validation method, providing clear error messages.
24-27: LGTM! Balance retrieval follows established patterns.The API call and response handling are implemented correctly, following the standard middleware response pattern.
28-30: LGTM! Appropriate error handling with generic error message.The catch block properly handles errors and returns a user-friendly error message without exposing internal details.
packages/extension/src/providers/massa/ui/send-transaction/components/send-token-select.vue (5)
1-18: LGTM! Well-structured template with proper event handling.The template correctly implements the token selection UI with appropriate click handling and proper Vue 3 syntax.
20-37: LGTM! Proper Vue 3 composition API usage.The script setup correctly defines props, emits, and follows Vue 3 composition API best practices.
39-43: LGTM! Proper balance computation with fallback.The computed property correctly handles balance conversion using fromBase with appropriate fallback for missing decimals.
46-118: LGTM! Clean and consistent LESS styling.The styles are well-structured, use consistent naming conventions, and properly utilize the theme variables.
24-24: Ignore the import path warning —AssetsTypeis correctly defined and exported frompackages/extension/src/types/provider.tsand imported consistently via@/types/providerthroughout the codebase.Likely an incorrect or invalid review comment.
packages/signers/massa/tests/sign.test.ts (5)
1-5: LGTM! Proper test imports and setup.All necessary testing utilities and dependencies are correctly imported.
6-15: LGTM! Well-defined test constants.The test uses a deterministic mnemonic and proper message hashing for consistent test results.
16-26: LGTM! Comprehensive keypair generation test.The test properly validates all aspects of keypair generation including address format validation specific to Massa (AU prefix).
28-38: LGTM! Proper sign and verify test workflow.The test correctly implements the signing and verification workflow with appropriate assertions.
40-51: LGTM! Important negative test case for signature validation.The test correctly validates that invalid signatures are rejected, which is crucial for security.
packages/extension/src/types/base-network.ts (3)
11-11: LGTM! Massa API import added correctly.The import follows the established pattern for other provider APIs.
37-43: LGTM! Massa API properly integrated into type union.The MassaAPI is correctly added to both the interface and abstract class return type unions, maintaining type consistency.
80-86: LGTM! Consistent API type integration.The abstract class property maintains the same type union as the interface, ensuring proper inheritance behavior.
packages/extension/src/providers/massa/methods/massa_setNetwork.ts (6)
1-6: LGTM! Proper imports for network switching middleware.All necessary dependencies are correctly imported for the network switching functionality.
7-13: LGTM! Correct middleware function signature and routing.The middleware properly implements the MiddlewareFunction interface and correctly handles method routing.
16-21: LGTM! Proper parameter validation.The networkName parameter validation is correctly implemented with appropriate error handling.
23-33: LGTM! Network validation with helpful error messages.The network validation logic provides clear feedback about available networks when an invalid network is requested.
35-44: LGTM! Proper network switching implementation.The network switching logic correctly uses the provider's setRequestProvider method with appropriate fallback handling.
45-51: LGTM! Comprehensive error handling.The catch block properly handles unexpected errors with informative error messages.
packages/extension/src/ui/action/views/network-assets/index.vue (3)
62-68: LGTM! Network-specific token components properly implemented.The conditional rendering correctly separates EVM and Massa token handling with appropriate type casting for the EVM network.
90-92: LGTM! Proper imports for Massa token support.The imports for CustomMassaToken component and ProviderName are correctly added to support the new functionality.
155-161: LGTM! Clean network type detection logic.The computed properties for network type detection are well-implemented and follow Vue 3 best practices.
packages/signers/massa/src/libs/ed25519.ts (3)
15-24: LGTM! Clean implementation of master key derivation.The function correctly implements Ed25519 master key derivation using HMAC-SHA512 with the standard "ed25519 seed" key.
26-39: LGTM! Standard CKDPriv implementation for hardened derivation.The child key derivation follows the standard Ed25519 pattern with proper hardened index support.
63-79: LGTM! Well-structured derivation path implementation.The function properly validates the path, derives the master key, and applies child derivations with the hardened offset. The use of reduce for iterative derivation is clean and functional.
packages/extension/src/providers/massa/ui/send-transaction/index.vue (2)
479-510: Good implementation of maximum value calculation.The function correctly handles both MAS tokens (deducting fees) and other tokens, with proper BigInt arithmetic to avoid precision issues.
255-268: LGTM! Robust balance validation logic.The computed property correctly handles both MAS and other tokens, properly checking fee requirements for non-MAS transfers.
packages/signers/massa/src/index.ts (2)
18-43: LGTM! Well-structured key generation with proper Massa formatting.The generate method correctly derives Ed25519 keys and properly formats them for Massa with version bytes.
60-64: LGTM! Clean implementation of signing.The sign method correctly uses the Massa PrivateKey class to sign the message hash.
packages/extension/src/providers/massa/types/index.ts (1)
1-31: LGTM! Well-structured type definitions for Massa integration.The type definitions properly extend base types and provide clear interfaces for transaction parameters and fees.
packages/extension/src/providers/massa/ui/send-transaction/verify-transaction/index.vue (1)
183-216: LGTM! Proper handling of native vs token transfers.The code correctly differentiates between MAS transfers and MRC20 token transfers, with appropriate payload construction for each type.
packages/extension/src/ui/action/views/network-assets/components/custom-massa-token.vue (1)
1-258: Component implementation looks good overallThe Vue component properly implements a modal for adding Massa MRC20 tokens with appropriate validation, error handling, and user feedback. The integration with the Massa network API and token state management is well-structured.
packages/extension/src/providers/massa/ui/send-transaction/components/send-address-input.vue (1)
1-134: Component structure is well-designedThe send-address-input component properly handles Massa address validation, identicon generation, and user interaction with appropriate error handling and visual feedback.
packages/extension/src/providers/massa/libs/api.ts (1)
1-60: API implementation is solidThe MassaAPI class provides a clean wrapper around the Massa Web3 provider with appropriate error handling and default values.
packages/extension/src/providers/massa/ui/libs/signer.ts (1)
1-132: Signer implementation follows good patternsThe transaction and message signer implementations properly handle different operation types, validate inputs, and use appropriate error handling.
packages/extension/src/providers/massa/networks/massa-base.ts (1)
26-289: Network implementation is comprehensive and well-structuredThe MassaNetwork class provides complete token management, activity tracking, and market data integration with proper error handling throughout.
| "@kadena/client": "^1.18.0", | ||
| "@kadena/pactjs-cli": "^1.18.0", | ||
| "@ledgerhq/hw-transport-webusb": "^6.29.8", | ||
| "@massalabs/massa-web3": "5.2.1-dev.20250730141858", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify Massa Web3 dev version consistency and stability.
The extension uses the same dev version 5.2.1-dev.20250730141858 as the signer package. This development version should be verified for stability and consistency across the codebase.
🏁 Script executed:
#!/bin/bash
# Description: Check if the Massa Web3 version is used consistently across packages
# Search for all references to massa-web3 dependency
rg -A 2 -B 2 "@massalabs/massa-web3" --type json
# Check if there are any version mismatches
fd "package.json" --exec grep -l "massa-web3" {} \; | xargs grep "massa-web3"Length of output: 1416
Standardize @massalabs/massa-web3 dev version across all packages
The extension is pinned to 5.2.1-dev.20250730141858, while both the types and signer packages use ^5.2.1-dev. This mismatch can lead to drift or unexpected behavior when newer dev builds are released.
Action items:
- Decide on your desired workflow for dev builds:
• If you want automatic updates to the latest dev build, use^5.2.1-deveverywhere.
• If you require a reproducible timestamped build, pin all three packages to5.2.1-dev.20250730141858. - Verify that the chosen dev release is sufficiently stable for your release cadence.
Affected files:
- packages/extension/package.json
- packages/types/package.json
- packages/signers/massa/package.json
🤖 Prompt for AI Agents
In packages/extension/package.json around line 42, the @massalabs/massa-web3 dev
version is pinned to 5.2.1-dev.20250730141858 while other packages use
^5.2.1-dev; standardize them by choosing one workflow and applying it to all
three files (packages/extension/package.json, packages/types/package.json,
packages/signers/massa/package.json): either replace the pinned timestamp with
^5.2.1-dev in extension to allow automatic dev updates, or update the versions
in types and signers to the exact timestamp 5.2.1-dev.20250730141858 to lock a
reproducible build; after changing, run your package manager to update the
lockfile (npm/yarn/pnpm install) and run the test/build suite to verify
stability.
| this.requestProvider = getRequestProvider('', this.middlewares); | ||
| this.requestProvider.on('notification', (notif: any) => { | ||
| this.sendNotification(JSON.stringify(notif)); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Bug: requestProvider is initialized with an empty URL, breaking first requests
Initializing with '' means early calls to request() will target an invalid endpoint until setRequestProvider() is invoked elsewhere. Also, notification wiring is duplicated here and will be lost on provider replacement.
Apply this diff to initialize with the actual network URL and centralize wiring via a helper (see next comment for the helper):
- this.requestProvider = getRequestProvider('', this.middlewares);
- this.requestProvider.on('notification', (notif: any) => {
- this.sendNotification(JSON.stringify(notif));
- });
+ this.initRequestProvider(this.network.node);Committable suggestion skipped: line range outside the PR's diff.
|
|
||
| private setMiddleWares(): void { |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add a helper to consistently initialize and wire the request provider (incl. notifications)
This keeps constructor and network changes DRY and prevents missing event subscriptions when replacing the provider.
+ private initRequestProvider(node: string): void {
+ this.requestProvider = getRequestProvider(node, this.middlewares);
+ this.requestProvider.on('notification', (notif: unknown) => {
+ void this.sendNotification(JSON.stringify(notif));
+ });
+ }Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/extension/src/providers/massa/index.ts around lines 47-48, add a
private helper (e.g. initializeRequestProvider(provider: RequestProvider)) that
centralizes assigning this.requestProvider, wiring its notification/event
handlers, and attaching any network-change listeners; ensure the helper first
unsubscribes or cleans up the previous provider's listeners if present, then
sets this.requestProvider = provider, registers all required
onNotification/onEvent callbacks and ties provider lifecycle to the
provider/network change logic, and replace direct wiring in the constructor and
any provider-replacement code to call this helper so event subscriptions are
never missed when swapping providers.
| setRequestProvider(network: BaseNetwork): void { | ||
| const prevURL = new URL(this.network.node); | ||
| const newURL = new URL(network.node); | ||
| this.network = network; | ||
| if (prevURL.protocol === newURL.protocol) | ||
| this.requestProvider.changeNetwork(network.node); | ||
| else | ||
| this.requestProvider = getRequestProvider(network.node, this.middlewares); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Notifications lost after protocol change; reinitialize provider to re-subscribe listeners
In the else branch you replace the provider instance but don’t re-attach the 'notification' handler, so notifications will stop after switching protocol (e.g., http → https).
setRequestProvider(network: BaseNetwork): void {
- const prevURL = new URL(this.network.node);
- const newURL = new URL(network.node);
+ const prevURL = new URL(this.network.node);
+ const newURL = new URL(network.node);
this.network = network;
if (prevURL.protocol === newURL.protocol)
this.requestProvider.changeNetwork(network.node);
else
- this.requestProvider = getRequestProvider(network.node, this.middlewares);
+ this.initRequestProvider(network.node);
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| setRequestProvider(network: BaseNetwork): void { | |
| const prevURL = new URL(this.network.node); | |
| const newURL = new URL(network.node); | |
| this.network = network; | |
| if (prevURL.protocol === newURL.protocol) | |
| this.requestProvider.changeNetwork(network.node); | |
| else | |
| this.requestProvider = getRequestProvider(network.node, this.middlewares); | |
| } | |
| setRequestProvider(network: BaseNetwork): void { | |
| const prevURL = new URL(this.network.node); | |
| const newURL = new URL(network.node); | |
| this.network = network; | |
| if (prevURL.protocol === newURL.protocol) | |
| this.requestProvider.changeNetwork(network.node); | |
| else | |
| this.initRequestProvider(network.node); | |
| } |
🤖 Prompt for AI Agents
packages/extension/src/providers/massa/index.ts around lines 52 to 60: when
switching protocol you replace this.requestProvider but don’t re-attach the
provider’s 'notification' handler so notifications stop after protocol change;
after creating the new provider call the same subscription setup used for the
old provider to re-register the 'notification' listener (and any other listeners
you rely on) — i.e., capture or reuse the existing handler reference(s) and
attach them to the new provider instance immediately after
getRequestProvider(...) so notifications continue after protocol changes.
| setRequestProvider(network: BaseNetwork): void { | ||
| const prevURL = new URL(this.network.node); | ||
| const newURL = new URL(network.node); | ||
| this.network = network; |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Harden URL parsing; new URL() will throw if network.node lacks a protocol
If any Massa network config provides a node without an explicit protocol, this will throw and leave the provider in a bad state. Guard it and fall back to re-init.
Proposed hardening:
- const prevURL = new URL(this.network.node);
- const newURL = new URL(network.node);
+ let prevURL: URL;
+ let newURL: URL;
+ try {
+ prevURL = new URL(this.network.node);
+ newURL = new URL(network.node);
+ } catch {
+ this.network = network;
+ this.initRequestProvider(network.node);
+ return;
+ }To verify configs contain absolute URLs with protocols, run:
🏁 Script executed:
#!/bin/bash
# Inspect Massa network configs to ensure node URLs include protocol (http/https/ws/wss)
set -euo pipefail
echo "Searching Massa networks definitions..."
fd -a --extension ts networks packages/extension/src/providers/massa | while read -r f; do
echo "=== File: $f ==="
rg -n "node\s*:" -A1 -B1 "$f"
done
echo
echo "Heuristic check for protocols:"
rg -n "node\s*:\s*['\"](http|https|ws|wss)://" packages/extension/src/providers/massa || {
echo "WARNING: No nodes with explicit protocols found by heuristic. Please confirm definitions."
}Length of output: 549
Harden URL parsing in setRequestProvider
Our Massa network definitions currently don’t include explicit protocols (scan found no http://, https://, ws:// or wss://), so calling new URL(network.node) will throw and leave the provider uninitialized. Wrap these calls in a try/catch and fall back to re-initializing the request provider:
• File: packages/extension/src/providers/massa/index.ts, method setRequestProvider
setRequestProvider(network: BaseNetwork): void {
- const prevURL = new URL(this.network.node);
- const newURL = new URL(network.node);
+ let prevURL: URL;
+ let newURL: URL;
+ try {
+ prevURL = new URL(this.network.node);
+ newURL = new URL(network.node);
+ } catch {
+ this.network = network;
+ this.initRequestProvider(network.node);
+ return;
+ }
this.network = network;This ensures that if a node URL is missing its protocol, we safely re-init rather than crash the provider.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| setRequestProvider(network: BaseNetwork): void { | |
| const prevURL = new URL(this.network.node); | |
| const newURL = new URL(network.node); | |
| this.network = network; | |
| setRequestProvider(network: BaseNetwork): void { | |
| let prevURL: URL; | |
| let newURL: URL; | |
| try { | |
| prevURL = new URL(this.network.node); | |
| newURL = new URL(network.node); | |
| } catch { | |
| this.network = network; | |
| this.initRequestProvider(network.node); | |
| return; | |
| } | |
| this.network = network; |
🤖 Prompt for AI Agents
In packages/extension/src/providers/massa/index.ts around lines 52 to 55, the
code calls new URL(...) on network.node which can throw if the string lacks a
protocol; wrap the URL parsing in a try/catch and on any error fallback to
re-initializing the request provider (e.g., leave this.network set to the
incoming network and call the existing provider init routine) so the provider
does not remain uninitialized—catch the exception, log or ignore the parse
error, and perform the safe re-init path instead of allowing the throw to
propagate.
| address: contractAddress.value as `AS${string}`, | ||
| }; |
There was a problem hiding this comment.
Type mismatch: ensure contractAddress is correctly typed as AS-prefixed string
The address field is typed as AS${string} but contractAddress.value is a plain string. Validate that the address actually starts with "AS" before casting.
- address: contractAddress.value as `AS${string}`,
+ address: contractAddress.value.startsWith('AS')
+ ? contractAddress.value as `AS${string}`
+ : `AS${contractAddress.value}` as `AS${string}`,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| address: contractAddress.value as `AS${string}`, | |
| }; | |
| address: contractAddress.value.startsWith('AS') | |
| ? contractAddress.value as `AS${string}` | |
| : `AS${contractAddress.value}` as `AS${string}`, | |
| }; |
🤖 Prompt for AI Agents
In
packages/extension/src/ui/action/views/network-assets/components/custom-massa-token.vue
around lines 179-180, the address property is being cast to the template literal
type `AS${string}` while contractAddress.value is an unvalidated string; add a
runtime check that contractAddress.value startsWith('AS') before casting and
only assign it when the check passes (otherwise surface a validation error/throw
or set the field to undefined/null), or normalize the value by prepending 'AS'
if that is intended; ensure you narrow the type after the check so the code no
longer relies on an unsafe cast.
| "dependencies": { | ||
| "@enkryptcom/types": "workspace:^", | ||
| "@enkryptcom/utils": "workspace:^", | ||
| "@massalabs/massa-web3": "^5.2.1-dev", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify Massa Web3 dev version stability.
The package uses a development version 5.2.1-dev which may not be stable for production use.
🌐 Web query:
What is the latest stable version of @massalabs/massa-web3 package?
💡 Result:
As of August 12, 2025 the latest stable release is version 5.2.0. (npmjs.com, github.com)
If you want, I can show the npm install command or check again for any newer release.
Citations:
Use the stable @massalabs/massa-web3 release
The project currently depends on the dev release ^5.2.1-dev, but the latest stable version is 5.2.0. Pulling in a -dev tag can introduce breaking changes or instability in production.
Please update the dependency:
• File: packages/signers/massa/package.json
• Line: 27
- "@massalabs/massa-web3": "^5.2.1-dev",
+ "@massalabs/massa-web3": "^5.2.0",If you need fixes only available in the dev build, add thorough testing or request an official release.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "@massalabs/massa-web3": "^5.2.1-dev", | |
| "@massalabs/massa-web3": "^5.2.0", |
🤖 Prompt for AI Agents
In packages/signers/massa/package.json around line 27, the dependency uses the
dev tag "@massalabs/massa-web3": "^5.2.1-dev" which can introduce instability;
change it to the latest stable version "5.2.0" by updating the version string
accordingly in that file, then run npm/yarn install and the test suite to ensure
nothing broke (if you truly need dev fixes, document and add tests or request an
official release).
| const isValidPath = (path: string): boolean => { | ||
| if (!/^m(\/[0-9]+('?))*$/.test(path)) { | ||
| return false; | ||
| } | ||
| return !path | ||
| .split("/") | ||
| .slice(1) | ||
| .map(replaceDerive) | ||
| .some(isNaN as any); | ||
| }; |
There was a problem hiding this comment.
Fix unsafe type assertion in path validation.
The use of isNaN as any bypasses TypeScript's type checking and could lead to runtime errors. The function should properly handle string-to-number conversion.
const isValidPath = (path: string): boolean => {
if (!/^m(\/[0-9]+('?))*$/.test(path)) {
return false;
}
return !path
.split("/")
.slice(1)
.map(replaceDerive)
- .some(isNaN as any);
+ .some((val) => {
+ const num = parseInt(val, 10);
+ return isNaN(num) || num < 0 || num > 2147483647;
+ });
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const isValidPath = (path: string): boolean => { | |
| if (!/^m(\/[0-9]+('?))*$/.test(path)) { | |
| return false; | |
| } | |
| return !path | |
| .split("/") | |
| .slice(1) | |
| .map(replaceDerive) | |
| .some(isNaN as any); | |
| }; | |
| const isValidPath = (path: string): boolean => { | |
| if (!/^m(\/[0-9]+('?))*$/.test(path)) { | |
| return false; | |
| } | |
| return !path | |
| .split("/") | |
| .slice(1) | |
| .map(replaceDerive) | |
| .some((val) => { | |
| const num = parseInt(val, 10); | |
| return isNaN(num) || num < 0 || num > 2147483647; | |
| }); | |
| }; |
🤖 Prompt for AI Agents
In packages/signers/massa/src/libs/ed25519.ts around lines 52 to 61, the path
validation uses an unsafe type assertion by calling .some(isNaN as any); replace
that with an explicit string-to-number conversion and a proper NaN check. Update
the predicate to convert each segment to a number (e.g., Number(segment) or
parseInt(segment, 10)) and use Number.isNaN(...) to detect invalid numeric
segments so TypeScript type-checking is preserved and runtime behavior is
correct.
| ".vscode/**/*", | ||
| "tests/**/*" |
There was a problem hiding this comment.
Fix contradictory include/exclude configuration.
The configuration includes tests/**/*.ts on line 18 but excludes tests/**/* on line 23, which creates a contradiction.
Apply this diff to resolve the contradiction:
"include": ["src/**/*.ts", "tests/**/*.ts"],
"exclude": [
"node_modules/**/*",
"_warmup/**/*",
- ".vscode/**/*",
- "tests/**/*"
+ ".vscode/**/*"
],📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ".vscode/**/*", | |
| "tests/**/*" | |
| { | |
| "include": ["src/**/*.ts", "tests/**/*.ts"], | |
| "exclude": [ | |
| "node_modules/**/*", | |
| "_warmup/**/*", | |
| ".vscode/**/*" | |
| ] | |
| // …other options… | |
| } |
🤖 Prompt for AI Agents
In packages/signers/massa/tsconfig.json around lines 22-23, there's a
contradiction where tests/**/*.ts is included but tests/**/* is excluded; remove
the exclusion of tests (delete the "tests/**/*" entry from the "exclude" array)
so the included test files are not ignored, or alternatively adjust the include
to omit tests if you intend to exclude them—make the include/exclude patterns
consistent.
| "node": ">=14.15.0" | ||
| }, | ||
| "devDependencies": { | ||
| "@massalabs/massa-web3": "^5.2.1-dev", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the pre-release version stability for production usage.
The dependency uses a pre-release version "^5.2.1-dev" which may contain unstable features or breaking changes. Consider if this is appropriate for production use.
🏁 Script executed:
#!/bin/bash
# Check if there's a stable release available for massa-web3
echo "Checking available versions of @massalabs/massa-web3:"
npm view @massalabs/massa-web3 versions --json | jq -r '.[-10:][]' | tail -10
echo -e "\nChecking latest stable version:"
npm view @massalabs/massa-web3 version
echo -e "\nChecking if the dev version exists:"
npm view @massalabs/massa-web3@5.2.1-dev version 2>/dev/null || echo "Version 5.2.1-dev not found"Length of output: 775
Review the use of a pre-release dependency
The project is currently pinned to a pre-release tag:
"@massalabs/massa-web3": "^5.2.1-dev",Our check shows:
- Latest stable release is 5.2.0.
- Available pre-release tags are
5.2.1-dev.<timestamp>(e.g.5.2.1-dev.20250806123047), not a bare5.2.1-dev.
Pre-release versions may include unstable or breaking changes. Please:
- Confirm that you intend to track the dev channel in production.
- If not, update to the latest stable release:
- "@massalabs/massa-web3": "^5.2.1-dev", + "@massalabs/massa-web3": "^5.2.0",
🤖 Prompt for AI Agents
In packages/types/package.json at line 27, the dependency is pinned to the bare
pre-release tag "@massalabs/massa-web3": "^5.2.1-dev", which is not a valid
timestamped pre-release and may unintentionally track unstable code; either (A)
if you do not intend to follow the dev channel, change the dependency to the
latest stable release "@massalabs/massa-web3": "^5.2.0", or (B) if you
intentionally want a dev pre-release, replace the version with the exact
timestamped pre-release (e.g. "5.2.1-dev.20250806123047") and confirm that
tracking dev builds in production is intended.
| "@kadena/client": "^1.18.0", | ||
| "@kadena/pactjs-cli": "^1.18.0", | ||
| "@ledgerhq/hw-transport-webusb": "^6.29.8", | ||
| "@massalabs/massa-web3": "5.2.1-dev.20250730141858", |
There was a problem hiding this comment.
can we set this to a prod version?
Summary by CodeRabbit
New Features
Tests
Chores