> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rhinestone.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Intents

> How intents connect funding, authorization, and onchain execution.

An intent is a signed authorization to achieve an outcome using specified assets and actions. Instead of manually sending each transaction needed to move funds, swap tokens, and interact with a contract, you authorize a coordinated operation.

For example, you want to deposit 100 USDC into a vault on Arbitrum, but your USDC is on Base. Your application selects Base USDC as the funding token and specifies the Arbitrum delivery and deposit calls. Rhinestone prepares a route, you authorize it, and relayers execute the required onchain transactions.

## What an intent contains

A Rhinestone intent connects funding with execution:

* **Source:** one selected funding chain and token, with an optional balance cap.
* **Destination:** the chain and, when needed, one delivery token and amount.
* **Calls:** the destination actions, such as approving and depositing into a vault.
* **Constraints:** conditions such as an expiry that limit when the operation can execute.

Your application chooses the source before quoting; Rhinestone does not search or aggregate balances across the portfolio. The prepared route determines the actual spend, delivery, and fees before you sign. A source balance cap is not a guarantee of exact-input spend.

A delivery always needs a source. No-delivery execution can omit it only when effective sponsorship covers applicable costs; sponsorship does not pay arbitrary call value.

Intents are not limited to crosschain transfers. The same model supports same-chain transfers, swaps, and contract calls.

## From request to execution

1. **Request an outcome.** Your application selects funding and specifies the destination, delivery token and amount, and calls.
2. **Prepare a route.** Rhinestone’s Orchestrator determines how to fund and execute the request, including swaps and crosschain settlement where needed.
3. **Authorize the route.** The account’s signer approves the selected route. The signature binds that authorization to its data; it is not permission for a relayer to perform arbitrary actions.
4. **Execute and settle.** Relayers submit the onchain transactions and front gas. For crosschain routes, settlement layers coordinate value movement between chains.

Fronting gas does not make execution free. Fees are paid through the supported user-paid flow or sponsored by your application.

A single intent can involve multiple transactions across several chains. It is not a single atomic transaction across those chains: funds can arrive before a later destination action fails. Your application tracks the intent’s execution status rather than treating submission as success.

## Intents and smart accounts

Smart accounts define **who can authorize actions and how the account executes them**. Intents define **the operation being authorized and how its execution is coordinated**.

For supported EVM smart accounts, Rhinestone’s Intent Executor module runs destination calls through the account. This lets the account interact directly with protocols, rather than having an intermediary act on its behalf.

Intents can also work with externally owned accounts, but token approvals and destination execution follow a different path.

## Next steps

* [Smart accounts](/home/concepts/smart-accounts): understand programmable accounts and their authorization rules.
* [End-to-end transaction flow](/transactions/multichain/end-to-end-transaction-flow): prepare, sign, submit, and track an intent.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.