CantonStakeCantonStake brings multi-chain staking into one interface. You sign with your own wallet, assets stake on their native network, and supported routes use Canton to record the position’s lifecycle and reward accounting.
The network determines how staking and exits work. Canton adds records for integrated routes.
For Canton-tracked routes, connect Loop to identify your Canton party, then a compatible wallet for the network you want to stake on. Your network wallet signs the asset transactions.
Native routes let you choose a validator or staking pool where supported. Review the asset, amount, network, fees and exit conditions. The Hoodi Lido route pools ETH without asking you to choose a validator.
CantonStake prepares the request; your wallet asks you to approve it. Tokens enter the selected network’s staking contracts or accounts. Native assets are not bridged to Canton by this flow.
For integrated routes, backend watchers verify network confirmations and update Canton records. Follow positions, unbonding and release in the app. Independent pools show their own balances and withdrawal state.
Validator or pool rewards follow the source network’s rules. They may accrue in a staking balance, a receipt token, or a claimable amount. Commission, activation and unbonding vary by route.
Displayed yield and validator scores can include estimates. They describe available data, not guaranteed returns.
CC rewards depend on the deployment, supported route, verified identity and enabled reward services. Connecting a wallet or creating a staking position does not by itself establish a CC payment.
The 75/25 user/app split is represented in beneficiary accounting. A recorded split or allocation is not proof of a transfer. Round timers indicate accounting cadence, not a guaranteed payout deadline.
View your reward recordsThe native chain is the source of truth for asset settlement. Canton records the corresponding application state for integrated routes.
Next.js, React and TypeScript provide the interface. Chain-specific wallet adapters connect accounts, select networks and request signatures.
Each adapter speaks the network’s transaction format. Delegation, receipt tokens, unbonding and withdrawal settle on that network under its own rules.
A Fastify/TypeScript service reads RPC data and checks settled events against the relevant request. PostgreSQL stores application records; Redis supports caches and background jobs.
Daml contracts represent the integrated staking lifecycle and beneficiary records. Reward observation, eligibility, allocation and payment are separate steps.
CantonStake’s backend acts as an observer and submits the chain evidence to Canton. Daml does not independently query or cryptographically verify the source network. Correct tracking therefore depends on the watcher, its RPC inputs and the app provider’s authorization.
These are implemented routes. Deployment configuration and current readiness determine which can accept a new stake. Check the homepage’s availability badges before opening a route.
ValidatorShare delegation, settled on Ethereum mainnet.
Cosmos delegation and undelegation through compatible wallets, with network-specific unbonding periods.
Native staking with a StakedSui receipt; unstaking is tied to that position’s receipt.
Delegation-pool add stake, unlock and withdraw operations.
Native staking precompile transactions and confirmation tracking.
StakeHub delegation, unbonding and claim operations.
Wallet-controlled stake accounts: create, delegate, deactivate and withdraw.
Nomination-pool join, unbond and withdrawal on Asset Hub.
Expand a topic for a closer look at identity, data, contracts and operations.
Loop supplies the Canton party identity for integrated workflows. EVM wallets connect through wagmi and viem; Cosmos-family chains use compatible Cosmos wallets; Sui, Aptos, Solana and Polkadot use their respective wallet adapters.
Your network wallet signs asset transactions. A Canton identity, a native wallet address and a reward beneficiary are different concepts. Their association and eligibility are checked for the selected workflow; the app does not ask for your seed phrase.
Native operations are chain-specific. Integrated Canton records model a staking request and the position’s Bonded, Unbonding and Released states. Watchers reconcile confirmed chain activity with the associated request before recording transitions.
PostgreSQL mirrors application metadata and event history. Transaction references and network explorers let you inspect the source-chain activity. Receipt-token holdings for independent pools follow their own lifecycle.
Readiness checks distinguish a reachable backend, a reachable Canton participant, a fresh chain watcher and an enabled staking workflow. Pool routes additionally check their own contract state. Failed or stale reads must not be presented as fresh availability.
Validator data is normalized and cached across networks. Some metrics are measured; others remain estimates where the source chain does not expose them. An availability badge confirms the checks behind that route, not completion of every possible funded-wallet scenario.
Native rewards and CC are accounted for separately. The reward view distinguishes recorded allocations, observed reward evidence and settlement where available. Historical records can remain readable when a live ledger read fails.
Background jobs support scanning, accounting and monitoring. A saved auto-compound preference or permit does not mean execution is active; automation depends on the deployment’s authorization and route gates. The staking flow does not promise automatic compounding.
Mainnet and testnet run as separate deployments with separate configuration and data. Chain IDs, enabled routes and wallet scope must match the selected deployment. Test assets do not carry a mainnet value.
The Canton environment is configured separately from each native chain. “Testnet” in the interface does not mean every integration uses the same test network: Ethereum’s Lido pool uses Hoodi, the Polygon liquid route uses Amoy, and advanced Polygon validator staking uses Sepolia.
This page describes the mainnet deployment. The Hoodi and Amoy pool interfaces are available on the separate testnet site.
The browser interface uses Next.js, React, TypeScript and TanStack Query. The backend uses Fastify and TypeScript, Prisma with PostgreSQL, Redis caches and BullMQ jobs. Canton application contracts are written in Daml; EVM integrations use Solidity contracts and native staking interfaces.
Docker Compose runs the application services. Health and readiness endpoints serve different purposes: process liveness alone cannot confirm that staking, indexing or reward payments are ready. Account pages scope reads to the connected wallets and the active deployment.