> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://ensforge.com/api/mcp` to find what you need.

# Cross-chain funding

Cross-chain funding is independent of execution. Use `execution.crossChain` to fund the HCA,
confirm arrival, then run ordinary registration with either provider. Registering a name never
silently bridges tokens from another chain.

Funding uses a plain EOA source account and ERC-20 Permit2 authorization. This guide uses Base
Sepolia as the source chain and Sepolia as the destination. Supply a reviewed route manifest for
your chain pair and tokens; routes are not enabled automatically.

## Prepare the source wallet

Follow [Rhinestone setup](/hca/rhinestone/getting-started) and set `ENSFORGE_BASE_SEPOLIA_RPC_URL`.
The source EOA needs the source token budget and Base Sepolia ETH for token approvals. The destination
HCA receives Sepolia tokens. The session key does not need funds for sponsored destination calls.

:::code-group
```ts [funding-client.ts]
// [!include ~/snippets/hca/guides/funding-client.ts]
```

```ts [rhinestone.ts]
// [!include ~/snippets/hca/guides/rhinestone.ts]
```

```ts [client.ts]
// [!include ~/snippets/hca/guides/client.ts]
```
:::

## Review a route manifest

`RhinestoneFundingRoute` identifies the chain pair, tokens, settlement layer, arbiter, destination
settlement contract and qualifier. It also records independently checked contract code hashes.
Do not populate trusted addresses from the quote that you are about to sign.

For proxies, pin the implementation storage slot and value using `storageSlots`, and pin the
implementation's bytecode in the same contract list. Proxy bytecode alone does not detect upgrades.
A changed contract pin requires review of the deployment, not automatic acceptance of a new hash.

## Quote, approve and fund

Call the function below with your reviewed route and a stable application funding ID. This example
requests one USDC and caps source spending at two USDC. Both tokens must use the expected six-decimal
units. Approvals and source spending are bounded by the reviewed quote.

:::code-group
```ts [funding.ts]
// [!include ~/snippets/hca/guides/funding.ts]
```

```ts [funding-client.ts]
// [!include ~/snippets/hca/guides/funding-client.ts]
```

```ts [account.ts]
// [!include ~/snippets/hca/guides/account.ts]
```
:::

In a wallet UI, present `quote.sourceSpend`, expiry and approval calls before advancing. The example
executes those approvals sequentially; do not combine or reorder token-required zero resets.
`fund` saves its submission claim before requesting funding authorization.

## Confirm arrival

Inspect the returned status. `funded` includes destination confirmation; unknown or partial outcomes
need reconciliation. Provider status, source claims, destination receipts and current balance answer
different questions, so retain the funding record as well as the provider reference.

After funding, start or resume [registration](/hca/guides/registration). Funding does not deploy an
HCA, enable an ENS session or grant resolver permissions on your behalf.

## Resume and clean up

Use `getFundingStatus(config, { id })` or `waitForFunding(config, { id })` after a restart with the
same compatible adapter and storage. Do not call `fund` again to recover a timeout.

`recoverFunding(config, { id, intentId })` attaches a recovered provider identifier without submitting
another transfer. `cancelFunding` only cancels eligible local work before submission.
`getFundingCleanup` returns allowance-reset and Permit2 nonce-invalidation calls to review and send
on the source chain. Cleanup cannot undo a completed transfer or guarantee cancellation of an intent
already being settled.

Changing destination registration terms is separate from funding recovery. Keep the funding ID and
registration ID distinct, and reconcile expired or partially settled funding before starting a new transfer.