Turning Cross-Chain Intent Infrastructure into a Token Streaming Product
A protocol can expose powerful primitives and still leave users with a difficult product.
Intento was designed around programmable on-chain flows: actions could be scheduled, composed and executed across chains. The architectural challenge was to prove that those primitives could support a simple end-user application.
That application became tokenstream.fun.
The shipped product focused on a concrete use case: streaming tokens across chains, including recurring strategies such as DCA. It used Skip:Go for cross-chain routing and IBC hooks as part of the execution path. Intento publicly described it as an experimental DeFi product and later as a live mainnet product capable of streaming tokens from any chain to any token on any chain.
The interesting architecture was the separation between the product users interacted with and the underlying intent-execution infrastructure.
From a protocol primitive to a product
A user does not think in terms of:
IBC packet → execution message → routing → scheduled transaction
They think:
Stream this token into that token over time.
The product therefore reduced the underlying system to a much smaller abstraction:
User
│
│ stream configuration
▼
tokenstream.fun
│
▼
Intento flow
│
├── schedule
├── token transfer
├── swap / route
└── cross-chain execution
│
▼
Skip:Go / IBC
│
▼
Destination chainThe frontend became a composition layer.
The protocol handled the execution machinery underneath it.
What actually shipped
The important distinction is between the product that was implemented and capabilities that were part of the broader roadmap.
The concrete product direction that shipped was:
token streaming
cross-chain token movement
token-to-token strategies
recurring execution / DCA use cases
Skip:Go integration
IBC hooks-based cross-chain flows
The product was used as an example of how Intento could turn a higher-level strategy into executable interchain flows. Public Intento material specifically describes tokenstream.fun as a project using Skip:Go and IBC hooks to demonstrate decentralized DCA strategies across multiple chains.
Later product material describes tokenstream.fun as live on mainnet and as a way to stream tokens from any chain to any token on any chain.
That is a sufficiently concrete product claim without implying that every broader Intento capability was exposed through tokenstream.fun.
The important architectural decision: reuse the protocol
The product did not implement its own cross-chain automation engine.
That was the key architectural decision.
Instead:
Product
│
▼
Stream definition
│
▼
Intento flows
│
┌────────────┼────────────┐
▼ ▼ ▼
Timing Routing Execution
│
▼
Cross-chain
stackThe application created a user-friendly representation of a recurring strategy.
Intento provided the programmable execution layer underneath it.
This kept product logic separate from protocol logic.
DCA is a useful proof of the abstraction
DCA is a good example because the user wants to define a strategy once and execute it repeatedly.
Conceptually:
Create stream
│
▼
Wait for interval
│
▼
Execute swap
│
▼
Move / settle assets
│
▼
Wait for next interval
│
└───────────► repeatWhat matters architecturally is that the protocol does not need a completely separate DCA engine.
DCA can be represented as a recurring flow built from existing execution primitives.
That is a strong test of composability.
Cross-chain complexity stays below the product layer
The user-facing product should not require users to construct IBC messages or understand the routing topology.
The underlying system can determine how the strategy is executed while the product exposes the desired outcome.
User view
OSMO → USDC
every week
for 10 weeks
Protocol view
stream
↓
route
↓
IBC
↓
destination executionSkip:Go was useful here because it provided the routing capability beneath the higher-level strategy rather than requiring tokenstream.fun to implement routing independently.
The product became an architecture test
This is where building a product on top of protocol infrastructure becomes valuable.
A protocol can claim to support composable cross-chain automation.
A real application forces that abstraction to answer practical questions:
Can users express the strategy simply?
Can the protocol represent recurring execution?
Can cross-chain routing be composed?
Can the user understand what will happen?
Can the infrastructure execute it without product-specific blockchain logic taking over the protocol?
That makes the product a kind of architectural integration test.
Protocol capability
↓
Real product requirement
↓
Integration
↓
Observed limitations
↓
Protocol refinementKeeping the boundary clean
The product and the protocol therefore had deliberately different responsibilities.
tokenstream.fun
owns the user experience and the concept of a token stream.
Intento
owns intent state and execution orchestration.
Skip:Go
provides routing capabilities.
IBC
provides interchain communication.
Destination chains
execute the resulting transactions and maintain their own state.
That decomposition keeps the product replaceable without making the protocol product-specific.
It also means the protocol can support other applications that use the same execution primitives.
The broader architecture lesson
The value of tokenstream.fun was not simply that it could stream tokens.
It demonstrated that relatively complicated cross-chain execution primitives could be turned into a much smaller user abstraction.
The user sees:
asset → destination → amount → schedule
while the underlying infrastructure handles:
intent state → flow execution → routing → cross-chain communication → settlement
That is the architectural boundary that matters.
Key insight: A good infrastructure product does not expose the infrastructure. tokenstream.fun turned programmable cross-chain flow primitives into a concrete DeFi product, while keeping routing and execution complexity underneath the user-facing abstraction.