Skip to main content
Walley submits transactions on the user’s behalf after they review and sign them inside the wallet popup. Your dApp describes what to do as a list of Daml commands; the user approves, and Walley prepares, signs, and submits.

​
Choosing a method

prepareExecute

Fire-and-forget. Resolves to null as soon as the transaction is submitted. Use when you don’t need the committed result inline.

prepareExecuteAndWait

Waits for the transaction to commit and returns the result. Use when your UI needs to react to the committed outcome.
Both take the same params — a commands array — and both open a popup for the user to review and sign.

​
Submitting commands

await provider.request({
  method: "prepareExecuteAndWait",
  params: {
    commands: [
      {
        type: "create",
        templateId: "<package-id>:<module>:<entity>",
        argument: {
          // template fields
        },
      },
    ],
  },
});
The commands array can contain more than one command; Walley submits them together in a single transaction, so they commit atomically — either all succeed or none do.
Always call prepareExecute / prepareExecuteAndWait from a user gesture. The submission opens a popup, and browsers block popups that aren’t triggered by user interaction.

​
Waiting for the result

prepareExecuteAndWait resolves once the transaction is committed, so you can update your UI directly off the returned result: 
try {
  const result = await provider.request({
    method: "prepareExecuteAndWait",
    params: { commands },
  });
  // transaction committed — update UI from `result`
} catch (err) {
  // user rejected, popup blocked, or submission failed
}
If the user closes the popup without signing, the request rejects with providerErrors.userRejectedRequest. Handle it as a normal cancellation rather than an error state.

​
Network fees

The Canton Network charges traffic for transactions. Walley handles this for you — your dApp never calculates, quotes, or pays a network fee. Walley charges the fee in the same movement as the transaction itself and assumes the user covers it. There is no separate fee step, no deferred settlement, and no follow-up prompt inside the wallet — the fee rides along with the commands you submit.
There is no fee handling on the dApp side. You don’t need to estimate costs, attach fee parameters, or surface fee UI — Walley owns that flow end to end.

​
When the user exits the popup

If prepareExecute / prepareExecuteAndWait rejects because the user closed or exited the popup, one possible cause is that they have skipped paying a previous fee. In that case Walley will refuse the new transaction until the outstanding fee is settled. Outstanding fees aren’t paid from your dApp. Direct the user to walley.cc to settle them, then have them retry the transaction.

​
Reading state instead of writing

If you only need to read ledger state — query active contracts, look up a contract by id — use the Ledger API proxy instead. It’s a read path that doesn’t open a popup or incur a fee.