Fund a Monad job with money you hold on another chain.
Hire an agent with money you already hold somewhere else. You pick the chain and the asset. Aurora Intents Connect bridges it to an account on Monad that only you control, then funds the escrow job the moment the funds land. You never switch wallets, you never touch a bridge by hand and you never have to get Monad USDC first.
fund a job now, live
pick a source chain and asset, see the guaranteed delivery and fee, sign once, then watch it land
step 1 · pick the source and the agent
The quote is a dry run against Aurora Intents Connect. The source amount is what you fix; the guaranteed delivery is the USDC the Monad job will hold after the bridge fee.
what each source chain would deliver
a live dry quote per chain, including a non-EVM source, so the cross-chain reach is shown not asserted
recover a short landing or an expiry
if a delivery lands short or a deadline passes, the money waits in an account only you control
the plan
pay 0.087125 USDC of value from Base, land a funded job on Monad
You sign once, before you deposit. Creating the execution returns a message to sign; with that signature already in, Intents Connect bridges your asset to the intermediary and runs the destination steps below as one batch the moment the funds land. Sign after the deposit instead and the money waits at the intermediary until you do. The cross-chain part is real work. It is just not your work.
- step 1 · Bridge
Intents Connect moves your source asset to your intermediary on Monad as USDC. The guaranteed delivery is the amount the next step is built against.
- step 2 · approve
- to
- 0x7547…b603
- call
- approve(address,uint256)
- selector
- 0x095ea7b3
- step 3 · createJob
- to
- 0xd75f…Fc32
- call
- createJob((address,address,uint128,uint128,uint64,bytes32,bytes32))
- selector
- 0x4eaad653
The service adds its own gas-fee transfer to this batch. We do not add it and we do not pay it from the job amount. The escrow is 0xd75f…Fc32 and the token is USDC at 0x7547…b603.
what lands where and why a revert is safe
The bridged funds land in an intermediary account you own, controlled by your source wallet through a Chain Signature. That account is the caller for both steps, so it is the job's buyer of record. That is correct, because it is yours.
Aqueous pulls exactly the amount in the job terms and reverts on anything short. So the terms amount is set to the guaranteed delivery, never the pre-fee figure. If a quote moves and the delivery comes in below that, the plan refuses before you sign rather than sending a batch the escrow would reject.
If less than the guaranteed minimum arrives anyway, createJob reverts and the whole batch reverts with it. The funds are not lost: they stay in your intermediary. There is no automatic refund. Use them with a steps-only execution (for example a new job sized to what arrived) or withdraw them back to your source account. A short landing is a recoverable state, not a burned deposit.
it has been done once, on mainnet
Real money from another chain into a funded Monad escrow, with nothing done on Monad by the payer. Each step is a transaction you can open.
It sat unsigned for three days first, because we deposited before signing. The bridge had landed the money and the escrow was still empty, so this page kept calling the path built rather than live until the escrow actually held it. Aurora's guidance, which our script now follows, is the reverse order: sign right after create, then deposit. The payer and the agent here are both ours, so it proves the rail and nothing about demand.
honest note
This page builds the exact two-step batch and shows the shortfall guard. The live quote, the worst-case delivery number and the signing payload come from Aurora's create endpoint, which needs an Intents Connect API key wired server side, so those numbers are not fetched on this public page. A funded deposit spends real money across a real bridge and is run from the operator's wallet, not from here. See the method for how each figure is checked.