Skip to main content
Walley connects to decentralized applications (dApps) built on the Canton Network through a popup-based approval flow. The dApp never runs inside your wallet and never touches your keys: whenever it needs something only you can authorize — connecting, signing a message, or submitting a transaction — a Walley popup opens, and you approve or dismiss it there.
dApps you connect to are external, third-party applications that are not developed, audited, or controlled by Walley. You are solely responsible for the dApps you choose to connect to and the requests you choose to approve. Always verify the source and intent of any request before signing.

​
How Connections Work

1

Initiate the connection from the dApp

Open the dApp and select its Connect Wallet option. The dApp opens a Walley popup window pointed at walley.cc.
2

Authenticate in the popup

Sign in with your passkey (or recovery phrase) inside the popup if you aren’t already signed in. This happens in a window the dApp does not control — your credentials are never visible to the dApp.
3

Approve the connection

Review the connecting site’s origin and approve. The popup closes and the dApp receives your wallet details. Some dApps also ask you to sign a sign-in message as part of the same approval.
If a connection popup appears that you did not initiate yourself, close it. Unexpected requests may indicate an attempt to link your wallet to an unauthorized application.
Looking for something to connect to? The Apps page in Walley lists featured Walley-compatible dApps you can open with one click.

​
What Data Is Shared

Approving a connection shares the following with the dApp:
  • Your Party ID and Party Hint — your public on-ledger identity.
  • Your public key and its fingerprint — so the dApp can verify your signatures. Your private key is never shared.
  • The active network id — which Canton network your wallet is on.
  • A short-lived access token — lets the dApp make read-only ledger queries scoped to what your party can see, through the wallet’s authenticated proxy.
  • Your private keys, passkey, or recovery phrase — signing happens only inside Walley.
  • The ability to move funds or submit transactions on its own: every transaction requires you to review and sign it in a Walley popup.
  • Your other dApp connections.

​
Approving Requests

After connecting, the dApp can ask your wallet to do things — each request opens a Walley popup for your explicit approval:
  • Sign a message — the popup shows the exact message text; approve to return a signature.
  • Submit a transaction — the popup shows the Daml commands the dApp wants to submit; approve to sign and submit them to the ledger.
Read every request carefully before approving. An approved transaction is submitted on-ledger and is irreversible. If a request’s intent or parameters are unclear, close the popup and contact the dApp provider before proceeding.
The Canton Network charges traffic fees for transactions. After a chargeable transaction commits, Walley prompts you in the popup to settle the fee. If you skip it, the fee stays owed and your next transaction is refused until it’s paid.
Legitimate dApps describe their requests in plain language. Be cautious of any request that uses opaque identifiers, asks for unusual permissions, or does not match the action you expected to take in the dApp.

​
Ending a Connection

A connection session is stored in your browser, scoped to that dApp’s site, and restored automatically when you revisit it — until it ends:
  • Sign out in the dApp. dApps offer their own sign-out/disconnect control, which clears the session.
  • Clear the dApp’s site data in your browser to remove a session manually.
Ending a session does not reverse any actions that were already approved and submitted on-ledger. And because every signature and transaction requires a fresh Walley popup approval, a lingering session cannot move your funds silently.

​
API and SDK Integration

If you build against Walley programmatically (see Build with Walley), you are responsible for securing your integration environment:
  • Treat access tokens as secrets — never commit them to source control or expose them beyond your app.
  • Sessions and tokens carry your users’ read access; invalidate them when no longer needed.
A compromised integration environment can issue requests against connected wallets. Treat integration credentials with the same care as wallet signing credentials.