Grofty

Grofty Labs builds wallet, trading and data tools for Canton. Wallet, DEX and Lens are now presented as live products, replacing the earlier DEX-preview description.

• Manage a Canton Party ID and supported balances, including CC and USDCx.
• Review recipient details, expected received amounts and fees before a transaction.
• Use locally authorised signing rather than handing a signing key to the transaction backend.
• Access documented transfer, onboarding, bridge and existing in-wallet swap workflows.

Canton accounts use Party IDs and asset-specific transaction workflows. Grofty’s network guide explains how recipient readiness and preapprovals affect transfers and onboarding. It also distinguishes a Party ID’s readable label from its full identifier. These details matter when checking where assets will go and whether a recipient can receive them.

Grofty exposes several Canton-specific steps within a wallet experience: account identification, recipient checks, preapproval requirements and a breakdown of transaction costs. Its documentation treats bridge fees, swap fees and direct CC-transfer fees as distinct categories, helping users understand which operation they are authorising instead of treating all movement of assets as the same transaction.

Wallet

Manage supported Canton assets, transfers and application connections. The wallet also supports Ethereum, Base and Monad; wallet-native networks and DEX bridge routes are different coverage lists.

DEX

Compare Cantex and OneSwap quotes, inspect fees and select a supported swap route. The DEX also publishes bridge routes into Canton.

Lens

View covered asset prices, liquidity, spreads and market analytics. Lens also provides API access and reporting tools.

Official Resources

• Website
• Telegram
• Discord
• GitHub
• Security Information
• Wallet Guide
• DEX Bridge Guide
• Canton Token Standard Guide
• Chrome Web Store
• Google Play

Grofty describes a prepare, sign and execute sequence. The backend checks transaction inputs, recipient readiness and fees, then prepares the payload. The extension unlocks the recovery material with the user’s PIN, derives a signing key in memory and signs locally. The backend submits the signed transaction and follows its confirmation.

According to its architecture documentation, the recovery phrase is stored locally in encrypted form using a PIN-derived key, while the backend does not retain the seed or private signing key. This separates local signing from server-side preparation and submission. Users still depend on the wallet software and its supporting services; non-custodial signing is not a claim that every operational risk disappears.