Takeaway lets you create chain-specific ENS subnames (e.g. arbitrum.yourname.eth, base.yourname.eth). You send funds to the subname from any chain; a relayer detects the deposit, reads your destination chain and address from ENS text records, and bridges to your chosen chain and address via Li.Fi. No bridge UI, no extra signing after the one-time setup.
How it works:
- Setup (one-time)
You own an ENS name (e.g. alice.eth). In the app you pick a destination chain (e.g. Arbitrum) and your receiving address. The app:
- Deploys a TakeawayDeposit contract on the chain where Takeaway is deployed (via TakeawayFactory).
- Creates an ENS subname arbitrum.alice.eth on Ethereum mainnet and sets:
- Address record: the new deposit contract address (so “send to arbitrum.alice.eth” resolves to that receive contract).
- Text records: io.takeaway.destinationChainId and io.takeaway.destinationAddress so the relayer knows where to bridge.
-
Sending
Anyone sends ETH to arbitrum.alice.eth from any chain. The resolver returns the deposit contract address, so the payment goes to that receive contract.
-
Relayer
The relayer watches for Deposit events on known deposit contracts. For each deposit it:
- Asks the Registry for the subdomain namehash linked to that contract.
- Reads ENS text records (by namehash) to get destination chain and address.
- Calls withdrawTo(relayer) on the deposit contract, then bridges the funds to the destination via Li.Fi.
Technologies:
- Frontend: Next.js app to connect wallet, configure ENS subnames, and show deposit addresses.
- Contracts: TakeawayRegistry, TakeawayFactory, TakeawayDeposit (Solidity, Foundry) on a supported chain (e.g. Base).
- Relayer: Watches for deposits, looks up destination from ENS, withdraws and bridges via Li.Fi.
How we build it:
We use ENS as the source of truth: each subname’s address record points to a deposit contract, and its text records (io.takeaway.destinationChainId, io.takeaway.destinationAddress) store where to bridge the funds. That keeps the relayer stateless—it only reads from ENS. Bridging is done via Li.Fi (quote + transactionRequest), so we don’t maintain routes ourselves. In effect, we turned ENS subnames into a chain selector: users can bridge without any UI by simply sending to a name from any chain.
Feature work / roadmap:
- Source from all chains — Receive from every supported chain; multicoin ENS resolution so one subname works from any chain.
- Trustless relayer — Withdraw only to verified bridges or use slashing/commit-reveal so the relayer cannot take funds.
- ERC-20 support — Accept and bridge approved tokens to the same ENS subname (no separate UI).
- Non-EVM support — Support non-EVM destinations (e.g. Solana).