How should new Ethereum L2s avoid becoming liquidity islands at launch?

One thing I have been thinking about with newer Ethereum L2 ecosystems is the gap between “apps can deploy” and “users can actually bring useful liquidity in.”

GIWA/GASOK is a good recent example. Teams are building toward mainnet, but the infrastructure question comes pretty early:

If a wallet, DEX, lending app, or consumer app launches on a new L2, should each team be responsible for integrating bridges, routing, liquidity sources, and asset variants on its own?

That feels like a lot of duplicated work for early app teams.

One possible model is shared cross-network execution infrastructure: apps integrate a single SDK, and routing/liquidity access is handled outside the app. SODAX is preparing this kind of setup for GIWA builders, but the broader question applies to any new Ethereum L2.

The tradeoffs seem non-trivial:

• app teams get faster access to multi-network liquidity
• users avoid manually bridging through several tools
• the L2 ecosystem may feel less empty at launch
• but routing, solver behavior, asset representation, and failure modes need to be easy to reason about

For people who have built on or around Ethereum L2s: where do you think this responsibility should sit?

Should liquidity/access infrastructure be handled by the L2 ecosystem, each individual app, or external execution layers?