1. Project Name
Rhoe
2. Project Description
Rhoe explores whether cross-chain capital can be deployed with better control through Superfluid streams rather than one-time lump-sum execution.
The pilot targets a capped Base Mainnet → Arbitrum Mainnet USDC flow via Circle CCTP. After settlement is confirmed, the funds are upgraded into USDCx and streamed into a receiver contract. The receiver acts as a capital buffer, while a keeper-compatible public function periodically evaluates deployment conditions and, when satisfied, unwraps only the required USDCx into USDC and executes a bounded Uniswap v4 liquidity action.
This is an R&D validation campaign, not a production financial product. The prototype will be mainnet-capable but initially tested with capped notional amounts and clearly marked experimental contracts.
The goal is to measure whether streamed deployment improves risk-adjusted execution quality, operational control, and observability compared to traditional Bridge → Swap → Deposit flows.
3. Website
SettleKit base repository.
Rhoe implementation branch/docs will be published as part of Milestone 1.
4. How does the project use Superfluid?
Superfluid is the core capital deployment primitive.
After USDC arrives on Arbitrum through Circle CCTP, it is upgraded into USDCx and streamed into a receiver contract. The receiver continuously accumulates capital while keeping funding separate from execution.
Pilot Strategy: Streamed Liquidity Accumulation
Flow:
- User bridges USDC from Base Mainnet to Arbitrum Mainnet through Circle CCTP.
- Settlement and destination mint are confirmed.
- USDC is upgraded into USDCx.
- USDCx is streamed into a receiver contract.
- The receiver accumulates streamed capital.
- A keeper-compatible public execution function evaluates deployment conditions.
- If conditions pass, the receiver unwraps the required USDCx into USDC and executes a bounded Uniswap v4 liquidity action.
Initial Pilot Position
- Asset pair: USDC/WETH
- Network: Arbitrum One
- Liquidity strategy: single-sided USDC deployment into a predefined Uniswap v4 position
- Capital source: USDC streamed from Base to Arbitrum via CCTP and upgraded to USDCx for continuous streaming
- Tranche handling: the receiver unwraps only the required USDCx into USDC when deployment conditions are satisfied
- Execution model: a keeper-compatible public function evaluates deployment conditions and executes bounded liquidity actions according to predefined parameters
- Pool interaction: the pilot uses standard Uniswap v4 PositionManager interactions and does not require custom hooks
- Risk controls: maximum deployment size per execution, receiver balance caps, cadence limits, oracle/TWAP checks, and liquidity checks are enforced before any deployment occurs
Risk-Aware Deployment Controls
Deployment may be paused or blocked when:
- pool liquidity falls below threshold
- oracle/TWAP deviation exceeds threshold
- slippage exceeds threshold
- keeper execution is delayed beyond a maximum interval
- deployment exceeds interval limits
- receiver balance exceeds pilot limits
The stream continues funding the buffer while deployment remains paused, but if the receiver balance reaches the pilot cap, flow rate is reduced to zero or the stream is deleted until conditions recover. Funds already accumulated remain withdrawable by the beneficiary.
Stream Controls
The campaign will demonstrate:
- stream creation
- flow-rate updates
- stream pause/delete
- stream resumption
- emergency shutdown procedures
Stream controls operate at the sender/controller level, with a multisig emergency override for pilot safety. The multisig can pause deployment and return funds to the beneficiary, but cannot redirect funds to arbitrary addresses.
5. Why build this?
Most cross-chain DeFi workflows remain fundamentally lump-sum:
Bridge → Swap → Deposit
That leaves users exposed to timing risk while giving them limited control over allocation speed once capital arrives on the destination chain.
SuperBoring has demonstrated the value of streaming for asset accumulation and DCA. Rhoe explores whether the same streaming primitives can be applied to treasury deployment and liquidity provisioning.
The central research question is:
Can Superfluid streams serve as a programmable capital-deployment rail for cross-chain treasury and liquidity workflows?
6. Relationship to SuperBoring
Rhoe is complementary to SuperBoring.
SuperBoring focuses on streaming-based asset accumulation. Rhoe focuses on streaming-based capital deployment after cross-chain settlement.
In practice:
- SuperBoring helps users acquire assets over time.
- Rhoe helps users deploy capital over time.
The project extends the Superfluid model into treasury allocation, liquidity provisioning, and programmable capital deployment workflows.
7. Team Members
DAOplomats
8. Social Links
SettleKit base repository.
Rhoe implementation branch/docs will be published as part of Milestone 1.
9. Networks
- Base Mainnet
- Arbitrum Mainnet
10. Requested Support
We are seeking support for a small validation campaign covering:
- receiver contract implementation
- deployment automation
- stream-control tooling
- a simple demonstration interface
- technical documentation
- a final findings report
The campaign will evaluate whether Superfluid streams can function as a programmable capital-deployment primitive for cross-chain treasury and liquidity workflows.
11. Success Metrics
Success for the campaign would include:
- a working mainnet-capable prototype
- successful CCTP → USDCx → stream → receiver → Uniswap v4 flow
- stream creation, update, pause/delete, and resume demonstrations
- at least three successful deployment intervals from accumulated streamed funds
- at least one risk-triggered blocked or paused deployment scenario
- public transaction links, repository, and technical documentation
- a short demonstration video
The final report will compare streamed deployment against lump-sum deployment using the same notional amount and time window across:
- average execution price
- realized slippage
- gas overhead
- idle capital time in USDCx
- successful deployment intervals
- blocked deployment attempts
- operational complexity
- overall execution quality