The problem XStream solves

Currently creating a stream to a recipient address on a different chain(you don't have liquidity on) is not possible in Superfluid.

With XStream, you can start a stream to any EVM chain from the chain you have your treasury on.

While the potential is much more, here's a few things XStream enables:
• allows anyone to send a stream to a recipient address on a chain they don't have liquidity on without the need to bridge tokens to that chain and having native tokens to pay gas for initiating the stream
• enables protocols and DAOs to compensate contributors on the contributor's chain of preference without building a separate treasury on each chain
• enables yield protocols can now distribute USDC rewards every second to users' chain of preference agnostic to the chain protocols hold their securities in
• enables creators and merchants in web 3, to create subscription strategies based on a unit of time and accept payment streams from any EVM chain user to their contract on their chain of preference.

Challenges we ran into

1. The major issue we faced was due to documentation for Connext which was not up to date which led to a lot of back and forth in executing calls from Superfluid V1. This delayed the deployment by 4-5 days.
2. Liquidity management across the two pools needs to be figured out with a current incentive system to be able to launch this on the mainnets by supporting USDC instead of TEST tokens.
3. We had to create a dedicated subgraph for fetching data points for our dashboard since Superfluid subgraph couldn't fetch all the data points required
4. Chainlink custom triggers were not working for external contract interactions. We triggering events on external transactions so that Chainlink custom logic triggers can pick these for the automation.