# Methods

The WalletConnect methods Joey mobile handles, their parameters, responses and errors.

Joey handles three methods on the `xrpl` namespace:

| Method | Purpose |
|---|---|
| [`xrpl_signTransaction`](/docs/integration/supported-networks/xrp-ledger/methods/xrpl_signtransaction) | Sign, and by default submit, one transaction |
| [`xrpl_signTransactionFor`](/docs/integration/supported-networks/xrp-ledger/methods/xrpl_signtransactionfor) | Add one multisignature to a transaction |
| [`xrpl_signTransactionBulk`](/docs/integration/supported-networks/xrp-ledger/methods/xrpl_signtransactionbulk) | Sign, and by default submit, several transactions with one approval |

Any other method is rejected with error `5101` (unsupported method). That includes `xrpl_signTransactionBatch` and `xrpl_signTransactionFee`.

## Common parameters

Every method accepts these optional booleans, either at the top level of `params` or nested under `params.options` (the form wc-client sends). If both are present, the top level wins.

| Parameter | Default | Behaviour |
|---|---|---|
| `submit` | `true` | Submit after signing. Only `false` makes a request sign-only. |
| `autofill` | See below | Fill in `Fee`, `Sequence` and `LastLedgerSequence`. |

- **When submitting**, Joey autofills unless you pass `autofill: false`. With `autofill: false`, the transaction must already have every required field.
- **When signing only** (`submit: false`), Joey signs exactly what you sent unless you pass `autofill: true`.
- **`xrpl_signTransactionFor`** never autofills and never submits.
- Both values must be real booleans. Anything else is rejected with `-32000`.

## Responses

Each signed transaction comes back as `{ tx_json }`, where `tx_json` is the decoded signed transaction including its `hash`, signing fields and any autofilled fields:

```json
{
  "tx_json": {
    "hash": "…",
    "TransactionType": "Payment",
    "Account": "r…",
    "Fee": "12",
    "Sequence": 123,
    "LastLedgerSequence": 456,
    "SigningPubKey": "…",
    "TxnSignature": "…"
  }
}
```

The response doesn't include ledger metadata. To confirm the outcome, look the transaction up on-ledger by `tx_json.hash`.

## Errors

| Code | When |
|---|---|
| `5000` | The user rejected the request. |
| `5100` | The request's chain isn't the network active in Joey. |
| `5101` | Unsupported method. |
| `5103` | The account active in Joey isn't the session's account. Joey asks the user to switch. |
| `-32000` | Invalid input. The message explains what's wrong. |
| `4100` | `tx_signer` isn't the account connected in this session. |
| `-32003` | The transaction was signed and submitted, but the ledger rejected it or the result couldn't be confirmed. `message` is the XRPL result code (for example `tecPATH_PARTIAL`); `data` is a JSON string `{"failedIndex": n, "signedTxs": [...]}`. |
| `8000` | The request had already expired when it arrived. |

## Using wc-client helpers

```ts
import core from '@joey-wallet/wc-client/core';

const response = await core.methods.signTransaction({
  provider,
  chainId: chain,
  request: {
    tx_json: { TransactionType: 'AccountSet', Account: address },
    options: { autofill: true, submit: true },
  },
});
```

`core.methods.signTransaction` and `core.methods.signTransactionFor` send the right methods.

> [!WARNING]
> Don't use `core.methods.signTransactionBatch` from wc-client 1.0.4. It sends `xrpl_signTransactionBatch`, which Joey doesn't support. For several transactions, call `xrpl_signTransactionBulk` directly; see [its page](/docs/integration/supported-networks/xrp-ledger/methods/xrpl_signtransactionbulk).

## Sign-in

To prove the user controls the connected address, include these keys in the `sessionProperties` of your connect proposal:

- `xrpl_signin_v1_challenge`: a non-empty challenge string
- `xrpl_signin_v1_destination`: a classic `r…` address

Joey then shows a single "Connect & Sign In" screen. It signs, locally, a 1-drop `Payment` that can never be submitted (`Fee: '10'`, `Sequence: 0`), with a memo containing the hex of `{"wallet":"joey","challenge":"<challenge>"}`. The approved session's `sessionProperties` then contain:

- `xrpl_signin_v1_challenge`
- `xrpl_signin_v1_signed_tx`: the signed transaction, as a JSON string
- `xrpl_signin_v1_account`

If signing fails, the session is still approved but without these keys; fall back to a normal sign request. This is the same format the [browser extension](/docs/browser-extension/sign-in) returns for Ledger accounts.