From any chain into any position.

One signature, and your USDC arrives as a position, not a balance. One more brings it back out, to any chain you name.

Read the docsWatch a deposit
Wallet

Log in to choose a wallet

Live against the hosted relayer. Testnet USDC from Circle's faucet.

How it works

Six steps, one signature.

The user signs once. Everything after that is a contract call anyone can make, or a Circle attestation. The relayer makes it fast, not possible.

  1. 01

    Register

    Hub on Arc

    The hub derives a deposit address on Arc from every parameter of the deposit.

  2. 02

    Fund

    User wallet

    The user funds it in one action, through Gateway with no gas or through CCTP.

  3. 03

    Sweep

    Relayer

    Anyone can sweep it. The USDC burns toward the destination, intent attached.

  4. 04

    Attest

    Circle

    Circle attests the burn and the relayer submits the mint on the far chain.

  5. 05

    Execute

    Receiver

    The receiver checks Circle minted it, then the adapter deposits in the user's name.

  6. 06

    Settle

    Escrow

    If anything fails the USDC waits to be claimed, or refunds after the deadline.

Why a rail

The deposit should be the only thing the user does.

Without Inlet

  1. 01Bridge the USDC to the chain the protocol lives on
  2. 02Swap or unwrap whatever arrived
  3. 03Switch the wallet to that network
  4. 04Sign the deposit

Four steps, two or three signatures, gas on two chains, and a wrapped asset somewhere in the middle.

With Inlet

  1. 01Sign once, on the chain where the USDC already is

One transfer to an address that can only end in the position the user chose. Native USDC the whole way, no network switch, no gas on the far side.

Why nothing gets stuck

Three invariants, enforced by the contracts.

  1. 01

    The address is the commitment

    USDC only reaches the deposit address because the user named that address in the transfer they signed. Inlet never needs a signature of its own.

  2. 02

    The path is fixed

    The hub can move USDC along the path the intent names, or back to the refund address after the deadline. There is no third option.

  3. 03

    The relayer is optional

    Sweep, refund, receive and claim are permissionless. A relayer can delay a deposit. It cannot redirect one, and it is not needed to finish one.

The address is the commitment. USDC can only move along the path the intent names, or back to the sender after the deadline.

Integrate

Three steps for a protocol. One tool call for an agent.

An ERC 4626 vault over USDC needs no contract work at all. Anything else is one adapter with one function, and the widget mounts inside the wagmi provider a protocol already has.

Mount the widgetWrite an adapter
import { DepositWidget, erc4626Destination } from "@inletkit/widget";
import "@inletkit/widget/styles.css";

const vault = erc4626Destination({
  id: "my-vault",
  name: "My USDC Vault",
  destinationDomain: 0,
  receiver: "0x55da7c3B5e99816A7a9cD9dc47e24bfd7B19D6ED",
  vault: "0xYourVaultOnEthereumSepolia",
});

<DepositWidget destinations={[vault]} relayerUrl={RELAYER_URL} />

The chain your user holds USDC on never appears here. You name where the position lives, and the rail brings the USDC from wherever they hold it.

For agents

The same rail over MCP.

A stdio server over the SDK and the relayer API the widget uses. An agent lists destinations, quotes, signs with its own wallet, and follows the deposit to the position. The way out is the same size: one permit, one call.

  • list_destinationsevery live destination and the adapter behind it
  • quote_depositroute, timing and the position the user ends up with
  • depositrun the whole flow with a funded key
  • withdrawposition back to USDC on the chains you name, with a funded key

Ten more cover the exact payloads to sign, the source chains, the Gateway route, status in both directions and live pool prices. Set it up or read the skill file a coding agent can follow.