Velora
Velora is an intent-based swap protocol across EVM chains
Velora is a DeFi swap service where users state the trade they want and competing executors complete it across supported blockchains. Its Delta protocol turns that requested outcome into a signed order, then uses the Portikus coordination network to select an agent that sources liquidity, chooses a bridge route, and settles through smart contracts. Velora also retains a Market aggregation path for conventional same-chain routing across decentralized exchanges.
One signature for a cross-chain token outcome
Delta is the intent-based swap system within Velora that turns a cross-chain target into one signed order for settlement.
A trader selects a source asset and chain, a destination asset and chain, and an amount. The quote then expresses the outcome that an agent must deliver. A route from USDC on Base to USDC on Optimism, for instance, places the bridge and destination transfer behind the order rather than in separate wallet actions. Agents source liquidity from venues such as Uniswap and Curve, while the multibridge layer evaluates Across Protocol and Relay routes that fit the requested assets and available token liquidity.
Base uses chain ID 8453, Optimism uses 10, and Ethereum uses 1, so the signed chain context keeps networks distinct. Destination-chain gas is unnecessary for a completed Delta route; source-chain approval gas appears when the token has no usable permit or standing allowance.
Costs shaped by execution, bridges, and partner settings
Swap cost on Velora is an execution total formed by quoted output, partner settings, bridge routing, and any source-chain approval.
Delta order construction defaults to 100 basis points of slippage, equal to 1%, while a partner fee defaults to 0 and cannot exceed 200 basis points, or 2%. One basis point equals 0.01%, which keeps the signed tolerance and fee arithmetic unambiguous.
The quote incorporates the selected liquidity path, price impact, bridge or relayer charge, and gas that the settlement agent absorbs. A direct ERC-20 approval remains a separate source-chain transaction when a permit is unavailable. The received amount therefore provides the clearest comparison between routes, because it already reflects the components assembled for that order.
Worked example: every changing input is hypothetical - a quote of 1,000 USDC, a 50-basis-point tolerance of 0.5%, and a zero partner fee. The signed minimum becomes 1,000 × (1 − 0.005), which equals 995 USDC. If no agent satisfies that minimum before the deadline, the order expires without settlement. A fresh quote produces a new result as pool depth, bridge routing, and network conditions change.
The wallet path from quote to completed order
The order path on Velora is a non-custodial wallet workflow that starts with a quote and ends at a terminal status.
- Connect a self-custody wallet, then select the source and destination chains.
- Choose the token contracts and enter the source or desired destination amount.
- Approve the Delta contract or provide a permit that the token supports.
- Sign the EIP-712 typed order and submit it to the agent auction.
- Track the order until COMPLETED, FAILED, CANCELLED, EXPIRED, or REFUNDED.
Token precision matters before signing because the API uses raw integer units. USDC uses 6 decimals, so 1 USDC is encoded as 1,000,000 units. DAI and WETH use 18 decimals, making 1 token equal to 1,000,000,000,000,000,000 units. An incorrect decimal field shifts the amount by powers of ten, even when the wallet shows a familiar ticker. Contract addresses and chain IDs identify the asset and network together.
Delta accepts ERC-2612 permit payloads of 224 bytes; its Permit2 TransferFrom and Allowance formats use 96 and 192 bytes, while DAI-style permits use 256 bytes. An on-chain approval remains the fallback when the selected token or wallet does not support one of those permit formats.
Trade-offs at approval, quote, and settlement boundaries
Trade risk in Velora is concentrated in token approval, quoted bounds, bridge settlement, and the difference between signatures and transactions.
An EIP-712 order signature commits to structured fields such as owner, beneficiary, token addresses, amounts, chain context, nonce, and deadline. Delta order construction uses a default deadline of 1 hour from creation. Expiry stops that order from being filled, yet an ERC-20 allowance is separate on-chain state and remains until the owner changes it. Exact allowances keep that scope tied closely to the intended amount, while a new approval or revocation requires source-chain gas.
Slippage also has a hard representation. The Market API accepts values from 0 through 10,000 basis points, where 10,000 equals 100%; applications may expose a narrower control. A loose bound permits a wider execution range, while a tight bound increases the chance that changing liquidity prevents settlement. Cross-chain execution adds bridge finality and relayer availability to those conditions, so the relevant boundary changes with the selected token pair, route, and execution mode.
Where Uniswap, 1inch Fusion, CoW Swap, and Socket differ
Relevant Velora alternatives are swap and bridge systems that differ chiefly in who selects liquidity, pays gas, and guarantees the output.
Uniswap gives a trader direct access to automated market maker pools and a router transaction on one chain. CoW Swap collects signed orders and lets solvers compete through batch auctions. 1inch Fusion also uses intent-style orders and resolver competition, while Fusion+ extends that model across chains. Socket specializes in cross-chain routing across bridges and decentralized exchanges. Across Protocol is narrower: it is an intent-based interoperability system that also appears inside Velora's multibridge execution. Each model assigns route choice and transaction submission differently.
The decision follows the desired control surface. A direct Uniswap swap exposes the pool route and wallet transaction. CoW Swap emphasizes solver competition and coincidence of wants, while Socket exposes bridge aggregation as the central workflow. Delta packages the requested output, auction, and bridge selection into one signed order. The strongest fit changes with chain coverage, token support, route transparency, and whether the trader wants to submit an on-chain swap personally, as set out in detail.
How does Velora choose and settle an agent?
Agent settlement in Velora is a competitive execution process in which Portikus coordinates bids before the Delta contract enforces the signed order.
Delta moves an order through 3 coordination stages: relay to Portikus, agent selection in an auction, and execution through the Delta contract.
The signed EIP-712 data supplies the owner, beneficiary, amounts, deadline, and nonce that define the acceptable outcome. The nonce occupies a 256-bit uint256 field, and externally owned account signatures use the 64-byte ERC-2098 compact representation when submitted. For a cross-chain order, the priced route also carries the destination chain ID and bridge-specific data. An agent wins the opportunity to settle, but the contract still checks the signed bounds before transferring value.
Portikus coordinates execution rather than holding the trader's balance. The source tokens stay under wallet control until the permit or allowance enables settlement. Completion then includes the destination bridge leg, while settlement time follows source finality, bridge design, destination finality, and the selected agent's route.
Market mode and Delta in one integration surface
The integration surface for Velora is a two-mode trading stack that exposes Delta execution and Market aggregation through applications and APIs.
Velora evolved from ParaSwap and retains Augustus Swapper for Market execution. Market mode compares liquidity from protocols such as Uniswap, Curve, Balancer, and Aave-related routes, then builds calldata for a same-chain transaction. An explicitly requested Market route contains at most 4 token addresses. The unified quote interface exposes 3 mode choices: ALL, DELTA, and MARKET. ALL prefers a Delta quote and uses Market as a fallback for eligible same-chain swaps; MARKET does not serve cross-chain orders.
Traders interact through a connected wallet, while developers use the API, TypeScript SDK, or widget to place the same mechanisms inside another application. Delta suits outcome-based and cross-chain execution, whereas Market offers direct transaction construction and multipath aggregation. The right mode changes with destination chain, token support, permit capability, and whether a competitive agent route is available at quote time.
Quick answers about Velora
Does Velora require a minimum deposit?
Velora does not require a protocol-level minimum deposit because it is a non-custodial swap protocol, not a broker account. A wallet supplies the source token for each order. The smallest workable trade is constrained by token precision, available liquidity, bridge minimums, execution costs inside the quote, and any interface rule applied by the application that submits the order.
When should a trader choose SELL instead of BUY?
A SELL order fixes the source amount, while a BUY order fixes the desired destination amount. Choose SELL when the budget is the hard constraint and review the minimum received. Choose BUY when the output quantity matters and review the maximum spend. The quote also accounts for route liquidity and settlement costs, so the same pair can return different bounds across chains, token contracts, trade sizes, and execution modes.
What role does the VLR token play in Velora?
VLR is the governance token of Velora DAO and is separate from the token-swapping requirement. Holders use VLR for direct voting or delegation, while staked seVLR participates in the staking system. A trader does not need VLR to request an ordinary swap. PSP was the earlier governance token, and governance activity moved to VLR after the migration.
Can a Delta order send tokens to a different address?
A Delta order can name a beneficiary different from the owner, so the destination token can settle to another address. If the beneficiary field uses the zero address, order construction treats the owner as the default. The signer should read that field as carefully as the amounts and chains because settlement follows the signed value. The receiving address does not need to sign, although route and token support still determine whether the order can be built.
Are partially fillable Delta orders available?
Partially fillable Delta orders are supported through the order-building interface, although the default value is false. When enabled, execution may cover only part of the signed amount under the order's bounds. A trader expecting one complete cross-chain outcome should read the executed amounts and status before planning the remaining balance. This preserves planning for the same route afterward.
Does Velora support limit orders?
Velora offers limit orders through its trading stack, but a limit order uses a target condition rather than an immediate market quote. Availability and settlement mode follow the selected interface and network. A trader should distinguish a LIMIT label from Delta's default MARKET filtering value: the label classifies the order, while signed amounts, deadline, and fill settings control its execution and determine what the settlement contract will accept under the signed terms.
Can developers restrict the agents that receive a Delta order?
Developers submitting a Delta order may pass lists that include or exclude agents. With neither list provided, submission includes available agents and excludes none. Restricting the set changes the competitive field and may alter whether an order receives acceptable execution. This control belongs to API integrations; a wallet user follows the choices exposed by the application that creates the submission.
When can Velora combine a swap with an Aave deposit?
Market routing can combine a token swap with a subsequent protocol action when the integration and route support that composition. One established pattern swaps ETH to DAI and deposits the DAI into Aave for aDAI within one transaction. This is a same-chain multipath action, not evidence that every token or lending action is available. Contract compatibility, allowance requirements, route construction, and returned calldata define the executable combination for the selected chain at quote time.