Cross-Chain Intents Explained: Solana to Ethereum Yield

Share
Cross-Chain Intents Explained: Solana to Ethereum Yield

A cross-chain intent is a signed statement of the outcome a user wants on another chain, such as "I give X on chain A and want at least Y on chain B by time T." Third-party solvers compete to deliver it. Cross-chain intents explained at the protocol level means asking what gets signed, who fronts the money, what verifies the fill, and where the risk ends up.

Take a Solana wallet that holds stablecoins while the yield product it wants lives in an Ethereum smart contract. The manual path means installing an EVM wallet, bridging, buying ETH for gas, approving, depositing, staking, and reversing it all to exit. With Aurora Intents and Elara, the same user signs twice from one Solana wallet. Whether the system is safe depends on how the protocol checks that the solver actually delivered.

Key Takeaways:A cross-chain intent is a signed, structured message that sets a desired outcome (source asset, destination asset, minimum output, deadline) and leaves the execution path to competing solvers.Intent systems have four core parts: an intent message format, a solver network, a settlement layer, and a price oracle, according to Eco's intent-engine documentation.ERC-7683, a standard developed by Across and Uniswap, defines a shared order format and settlement-contract interfaces so solvers can fill intents from different protocols on EVM chains.Aurora Intents lets Solana wallets deposit into Elara's Ethereum yield product with two signatures and no second wallet, per Aurora Labs' announcement.Intents do not remove bridge risk; they move it from the user's transfer to the settlement layer that repays solvers, which is the part users should audit first.

Table of Contents

What Are Cross-Chain Intents?

A cross-chain intent is an off-chain, cryptographically signed order that states the end state a user wants across two blockchains, and that a third party (a solver or filler) can execute for a fee. With a normal transaction, the user tells the chain what to do: call this contract, with this calldata, using this nonce. With an intent, the user only says what they want, and specialists compete over how to deliver it.

Eco's documentation describes the intent message as containing the source chain and asset, the destination chain and asset, the recipient, a deadline, a maximum fee or minimum output, and optional constraints such as slippage tolerance, allowed solvers, and callback hooks, per its 2026 intent-engine guide. (Eco runs a competing intent product, so read its rankings with that in mind.)

A traditional lock-and-mint bridge makes the user wait for the source chain to finalize, then for a message to be relayed, then for a mint. With an intent, a solver who already holds inventory on the destination chain pays the user right away, then claims repayment from the user's locked source funds later. The latency and the capital cost move from the user to the solver.

Eco places intent engines in a layered stack: they sit above message transport (Hyperlane, Circle's CCTP, LayerZero) and below the wallet or app. An intent protocol is an auction and settlement system. It is not a new way to move bytes between chains, and it still needs a messaging or verification layer underneath.

How Does Intent-Based Bridging Work, Step by Step?

Intent-based bridging works by separating the user's payment from the user's delivery: the solver delivers first on the destination chain, and the protocol repays the solver from escrowed source funds once it verifies the delivery. Here is the generic flow, matching the four subsystems Eco describes (intent parser, solver auction, settlement verifier, refund machinery):

Seven-step intent flow from quote and sign through escrow, auction, fill, verify, and repay or refund.
The user sees steps 1 and 2; verification is where protocols differ.
  1. Quote. The wallet or app asks solvers for a price. Solvers answer with the output they can guarantee after fees, gas, and their spread.
  2. Sign. The user signs a structured order. On EVM chains this is usually EIP-712 typed data. On Solana the wallet signs with Ed25519. The signature commits to the input amount, minimum output, destination recipient, and deadline.
  3. Open / escrow. The order is submitted to a settlement contract on the source chain, which pulls the user's tokens into escrow. ERC-7683 calls this step open (user-submitted) or openFor (a solver submits a gasless order on the user's behalf). The standard is specified in the EIP-7683 specification.
  4. Auction. Solvers compete. Depending on the protocol this can be a Dutch auction, an RFQ, or first-come-first-served among permissioned fillers.
  5. Fill. The winning solver sends its own funds to the user's recipient on the destination chain, usually through a destination settler contract that records the fill and links it to the order ID.
  6. Verify. A settlement mechanism proves to the source chain that the fill happened. Options include an optimistic oracle, a cross-chain message, an MPC or committee attestation, or a light-client proof.
  7. Repay or refund. If verification succeeds, the escrow pays the solver. If no valid fill arrives before the deadline, the refund path returns funds to the user.

Step 6 is where protocols differ most. The user sees steps 1 and 2, and everything else happens out of view.

Why solvers accept this deal

Solvers are market makers with inventory spread across chains. They take a spread plus a fee for fronting liquidity and carrying settlement risk until repayment. A solver that holds USDC on Ethereum and wants USDC on Solana can fill orders in the opposite direction and rebalance cheaply, which is why pricing tends to be better on busy corridors than on thin routes.

What Is Inside an Intent? The ERC-7683 Order Structure

ERC-7683 is an Ethereum standard, developed by Across and Uniswap, that defines a common cross-chain order format and settlement-contract interfaces so any solver can parse and fill intents from any compliant protocol. The EIP-7683 specification is the clearest public reference for what an intent contains at the contract level.

The standard defines two order types and one resolved view:

  • GaslessCrossChainOrder: signed off-chain by the user and submitted by a solver via openFor. Fields include originSettler, user, nonce, originChainId, openDeadline, fillDeadline, orderDataType, and arbitrary orderData.
  • OnchainCrossChainOrder: submitted directly by the user via open, carrying fillDeadline, orderDataType, and orderData.
  • ResolvedCrossChainOrder: a normalized view that any solver can read without knowing the protocol-specific orderData encoding. It lists maxSpent (what the solver must deliver), minReceived (what the solver gets back), and fillInstructions (which destination chain, which destination settler, and what payload).

ERC-7683 standardizes the order and the interfaces (IOriginSettler, IDestinationSettler.fill), but it does not standardize settlement verification. Each protocol brings its own way of proving fills, so a solver still has to model each protocol's repayment mechanism separately.

ERC-7683 is an EVM standard, and the sources we reviewed do not confirm any Solana implementation. Solana uses Ed25519 keys and a different account model, so a Solana-to-Ethereum intent needs some translation layer between the two. The public material does not say how Aurora Intents does this.

How Is a Fill Verified? The Settlement Trust Spectrum

Settlement verification is the mechanism that convinces the source chain a solver really delivered on the destination chain, and it decides the real security of any intent system. We rank each mechanism by who you trust to say "the fill happened."

Four fill-verification models and who attests each: oracle disputers, validators, MPC signers, or chain consensus via light client.
Light-client proofs rely on no committee; the source chain's consensus attests.
Verification model Who attests the fill Failure mode Typical latency to solver repayment
Optimistic oracle Anyone proposes; disputers can challenge within a window No honest disputer watching during the window Challenge window
Cross-chain messaging (e.g., Hyperlane, LayerZero) Configured validator set / oracle-relayer pair Validator set collusion or misconfiguration Depends on the messaging layer
MPC / threshold signer network A threshold of key-share holders Threshold compromise Depends on the signer network
Light-client / SPV proof The source chain's own consensus (verified on-chain) Consensus-level attack on the proven chain Depends on finality depth

The history explains why this table matters. Bridge hacks drained roughly $2 billion across 13 incidents in 2022, about 69% of all crypto stolen that year, according to Chainalysis. An intent protocol that settles through a weak verifier carries the same weakness. It just affects solvers first. For a closer look at one such failure, see our breakdown of the NEAR Intents hack.

The light-client row is the one most intent discussions skip. In an SPV (Simplified Payment Verification) model, a contract on the destination chain stores the source chain's block headers and accepts a Merkle inclusion proof that a given transaction is in a confirmed block. No committee signs off.

TeleSwap uses this model: TeleBTC is minted 1:1 only after an on-chain light client verifies the underlying Bitcoin transaction. Collateral-backed, slashable Lockers handle custody, and a Teleporter covers destination gas so the user pays fees in Bitcoin assets. According to TeleSwap network stats, the protocol has bridged $519.1M in total volume across 549,959 transactions on 13 supported networks, including $44.8M in the last 30 days. For broader context on validator risk, read Ethereum Validator Security & Bitcoin Bridge Risks. Intent UX and light-client verification work at different layers and can be combined.

How Does a Solana Wallet Access Ethereum Yield? An Aurora Intents Walkthrough

A Solana wallet gets Ethereum yield through intents by signing from the Solana wallet while the intent layer handles the Ethereum side, so the user never manages a second wallet. The clearest example is Aurora Intents connecting Solana wallets to Elara, announced by Aurora Labs on October 15 (the source gives no year) and reported by crypto.news.

Aurora Intents flow: connect Solana wallet, sign deposit minting elUSD, sign stake into sELUSD, hold, withdraw.
Two signatures from one Solana wallet; settlement details are undisclosed.

What Elara is

Elara is a treasury management product in the Brila ecosystem. Stablecoin deposits mint elUSD, a dollar-referenced treasury asset on Ethereum. Staking elUSD produces sELUSD, which earns yield from stablecoin market-making activity. The announcement gives no APY, so we won't quote one.

The Aurora Intents tutorial: the two-signature flow

  1. Connect a Solana wallet on Elara's app, where the route is described as live.
  2. Signature 1: deposit. You sign a deposit from the Solana wallet. Funds reach Ethereum, where Elara mints elUSD.
  3. Signature 2: stake. You approve a second transaction from the same Solana wallet that stakes elUSD into sELUSD.
  4. Hold. Your position earns yield from stablecoin market making. Nothing is guaranteed.
  5. Withdraw. Unstaking and redemption happen on Ethereum, and stablecoins return to your Solana wallet.

Elara's head of strategy, Sebastien Davies, said: "Aurora Intents gives those holders a direct route into Elara without bridging or managing a second wallet."

What happens under the hood (and what is not disclosed)

Aurora Intents runs on NEAR Intents, which Aurora Labs says has processed more than $34 billion in volume, per the same announcement (a company figure with no stated date).

The public material does not disclose the Solana-side transaction format, the signing scheme, the solver set, the settlement contracts, or the Ethereum contract addresses. Those are the details that decide your risk, so treat the two-signature UX as an interface and check the settlement path yourself.

Solana is using this pattern elsewhere too. On January 15, 2026, Starknet's STRK became accessible on Solana through NEAR Intents without traditional bridging, with Jupiter and Meteora providing trading and liquidity, as Yellow.com reported.

Manual Bridging vs. Intents vs. Light-Client Bridges

Cross-chain DeFi yield without bridging manually means swapping operational work (wallets, gas, multi-step transactions) for protocol dependencies (solvers, settlement verifiers). Here is how the three common patterns compare for a user who wants a yield position on another chain:

Dimension Manual bridge + DeFi Intent-based route (e.g., Aurora Intents → Elara) Light-client bridge (e.g., SPV-verified)
User signatures Many, across two wallets 2 from one Solana wallet Fewer, from the source wallet
Destination gas token needed Yes No No if a relayer/teleporter covers it
Who bears latency User Solver User (waits for confirmations)
Trust anchor Bridge's verifier Settlement layer + solver set Source chain consensus
Composability with destination DeFi Full, but manual Only pre-built routes Full once asset arrives
Failure handling User must retry/claim Deadline + refund machinery Proof resubmission / collateral slashing

Scale differs across the ecosystem. Wormhole reports more than 45 connected chains and $68 billion in all-time transfer volume, according to Stablecoin Insider (self-reported figures). Eco Routes listed 15 supported chains as of March 2026, Solana among them, per Eco. A long chain list says nothing about how any single route is verified.

What Risks Do Intents Hide?

Intents hide risk; they do not remove it.

1. The "no bridge" claim is about UX, not trust

When a press release says "without bridging," it means the user doesn't run a bridge transaction. Value still crosses chains, and the protocol still needs some settlement path to repay solvers. If that path fails, solvers stop filling and refunds can stall. For how intent-based design can also defend against attacks, see how NEAR blocks hacker swaps.

2. Yield routes stack dependencies

The Solana-to-Elara path depends on the Solana wallet, the intent layer and its solvers, the Ethereum contracts, and a stablecoin market-making strategy. The sources describe Elara's strategy only at a high level, with no audits, reserve data, or redemption terms disclosed. Yield from market making is compensation for taking on risk, not a fixed coupon.

3. Exit liquidity is asymmetric

Entering is easy when solvers compete for deposit flow. Exiting during stress may be harder, with wider spreads or delays when many users redeem at once. Before depositing a meaningful amount, test a small withdrawal.

4. Solver concentration

Intent auctions are only competitive with enough solvers. Our sources don't disclose how many solvers serve these routes. Few solvers means pricing risk and, in permissioned designs, censorship risk.

5. Signature-scope risk

Gasless orders (openFor-style) let a third party submit your signed order. If a wallet shows an opaque blob instead of a decoded order, you can't check minReceived, the recipient, or the deadline.

Practical Checklist for Developers and Advanced Users

Before you use or integrate any cross-chain intent route, answer these seven questions.

  1. What verifies the fill? Optimistic oracle, messaging validators, MPC signers, or a light client? If you can't find it in the docs, treat that as a red flag.
  2. What is the refund path and deadline? Know the fillDeadline equivalent and who can trigger a refund.
  3. What does the signature commit to? Decode the order. Confirm minimum output, recipient address, and expiry.
  4. Who are the solvers? Permissionless auctions and whitelisted fillers have different liveness and censorship properties.
  5. What is the destination protocol's risk? For yield products: audits, strategy disclosure, redemption mechanics, and depeg exposure.
  6. Can you exit through a different path? If the intent route goes down, can you redeem directly on Ethereum?
  7. Test a round trip with a small amount. Measure actual output against the quote in both directions.

For developers, the fastest way to learn is to publish a test intent. Eco's Routes CLI documents a flow of cloning the repo, running pnpm install && pnpm build && pnpm link, and then pnpm dev publish --source optimism --destination base, per Eco's guide. Watch the escrow, fill, and settlement transactions on both block explorers.

Frequently Asked Questions

What is a cross-chain intent in simple terms?

A cross-chain intent is a signed order that says what you want to receive on another chain, leaving it to solvers to work out how to deliver it. You set the input, the minimum output, the recipient, and a deadline. A solver fronts the destination funds and is repaid from your escrowed source funds after the protocol verifies the fill.

How is intent-based bridging different from a traditional bridge?

In intent-based bridging, a solver pays you first and settles with the protocol later, while a traditional bridge makes you wait for the message or mint before you receive anything. Value still crosses chains in both cases. The difference is who carries the latency and capital cost, and intents shift that to solvers.

Can a Solana wallet really earn Ethereum yield without an Ethereum wallet?

Yes, through routes like Aurora Intents, which let a Solana wallet deposit into Elara on Ethereum with two signatures. The first signature deposits stablecoins that mint elUSD, and the second stakes elUSD into sELUSD. Withdrawals return stablecoins to the Solana wallet. No yield rate is guaranteed, and the yield comes from stablecoin market making.

What is ERC-7683?

ERC-7683 is an Ethereum standard from Across and Uniswap that defines a common cross-chain order format and settler interfaces so solvers can fill intents across protocols. It specifies gasless and on-chain order types and a resolved order view. Each protocol still chooses its own settlement verification method.

Are cross-chain intents safer than bridges?

Not automatically. Intents are only as secure as the settlement layer that verifies fills and repays solvers. Intents do cut the user's exposure during the transfer itself, because a solver delivers funds directly. But the verification layer underneath still carries the same kinds of risk that cost bridges about $2 billion in 2022, according to Chainalysis.

What happens if no solver fills my intent?

If no valid fill arrives before the deadline, the protocol's refund mechanism should return your escrowed funds. How fast that happens and who can trigger it differs between protocols, so check the refund path and deadline before you sign.

Conclusion

The main points: first, cross-chain intents separate what a user wants from how it gets done, so a Solana wallet can reach an Ethereum yield position with two signatures. Second, the real security question is not "is there a bridge?" but "what verifies the fill?" Third, yield routes add destination-protocol risk on top of settlement risk, so check exit liquidity before you size a position.

If you hold Bitcoin and care about the verification layer more than the interface, see what a light-client-verified route looks like. TeleSwap's routes, such as BTC to USDC on Ethereum, are live at teleswap.xyz. The protocol design is documented at teleswap.xyz/docs.