Replies: 6 comments 5 replies
-
|
So,
Right? In other words, the streaming logic would not be limited to SabVM, but would spawn several/multiple blockchains. Wouldn't it be better to just bridge the funds to SabVM in the background, before creating the stream, though? |
Beta Was this translation helpful? Give feedback.
-
Yes
Yes, but we need not handle this ourselves. There are plenty of bridging solutions that we could use for this, e.g. Socket's SuperBridge, StarGate, or Connext.
No, this would be overkill and potentially dangerous because the same address may not exist on the other chain. For instance, if the user is a Safe wallet, the same address might not belong to the same user on the other chain.
This is the ideal, yes. But it is not clear to me yet if this is feasible.
We can do that, too. We can implement a "bridge-and-create-stream" functionality. But that is not mutually exclusive with the cross-chain approach. There are all sorts of reasons why people may prefer to keep their tokens in one place: accounting, security (e.g., see L2Beat), convenience, ideology, tribal allegiance, etc. |
Beta Was this translation helpful? Give feedback.
-
|
@PaulRBerg, having dipped my toes into "cross-chain collaterization", I'd say that it sounds more like a general-purpose solution/tool, with bridging being just one of its possible applications (vs being synonymous/at the same level with bridging, as I've originally thought). I'll go even further - and say that the way "cross-chain collaterization" enables bridging (the lockup of funds on the user's chain of choice, followed by the verification of the former - and the release/minting of the "same" token on the target chain) is, pretty much, exactly how I'd describe the background functioning of a "classic"/standard cross-chain "bridge". What am I missing?
Makes total sense to me. Even with the trust requirement associated with this approach, I think that delegating the bridging logic to someone who specializes in it is a good idea - at least, for the SabVM MVP. Is this the most resource-efficient way for us to have SabVM "connected" - via bridges - to the other chains - or there are more ways to delegate the implementation of bridging?
Very good point! What about the sender, though? If they want to extract some of the deposited tokens from their Stream on V3 - or cancel it altogether, via what chain do we send them the tokens? 🤔 |
Beta Was this translation helpful? Give feedback.
-
Correct
It's not quite a standardized bridge. With Sablier V3, you could have bespoke cross-chain interaction models that are not bridging any valuable token. For instance, you could have a design with no lockups on the originator chain, but on Sablier, you mint virtual tokens, which we shall refer to as $NUTS (for entertainment purposes). $NUTS would require trust to be redeemed for actual monies. With this model, Sablier becomes a settlement layer of sorts.
It should be the most efficient way!
TBD, but I speculate that yes, because lots of startups in this space are hungry for success
Thanks!
It depends upon the implementation. I do wish to clarify that the purpose of this discussion was to start a mini research program - not to introduce a clear-cut specification/ |
Beta Was this translation helpful? Give feedback.
-
My understanding is that all cross-chain interactions fundamentally involve some form of bridging, whether the transfer is via native, non-native, or storage proofs I previously studied Succinct and understood that storage proofs differ from other bridging solutions primarily in how they validate transaction authenticity. Storage proofs use ZK proofs to confirm specific storage on one chain, which a relayer then verifies through a smart contract on another chain. Nevertheless, any bridge interaction essentially involves three steps:
My perspective on cross-chain collateralizationGiven the current state of technology, it would still need a bridging solution from Rollup to SabVM, which will ultimately bridge tokens to SabVM, either as minted tokens or native tokens. This introduces several trust factors:
If any of these components are exploited, the entire SabVM could be affected. Therefore, for SabVM's safety, we should be careful when considering third-party bridging solutions. We should, of course, let other bridges support SabVM because it will reduce the bridge transfer time for users but for the core components and use cases of the SabVM, we should rely majorly on our own canonical set of smart contracts for bridging. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with all points. |
Beta Was this translation helpful? Give feedback.
-
I don't understand how this could work w/o any sort of value lockup required at some point. Unless the value is locked up on the source chain, how can the value of the tokens minted on the target chain ($NUTS) be sustained?
Of course. What I was trying to highlight is that having the Stream-related logic spread across/involving multiple chains (e.g. letting the senders "seamlessly" create Streams on SabVM, or recipients - "seamlessly" withdraw, signing a tx on some other, connected chain) would lead to a very different complexity level - and that we should take this into consideration when deciding whether certain features (which would undoubtedly enhance the UX) are worth implementing.
I'd say that the more bridges (be it in-house or third-party) we get connected to SabVM, the better. If we mainly depend on the in-house bridges, we'll do our users a disservice, because, most likely, we won't have the bandwidth and expertise necessary to compete (at the UX level) with the companies that only do bridging, day in and day out. At the same time, if we mainly rely on a single/small number of bridges, we'll be running the risk of following in the footsteps of Fantom which heavily depended on Multichain (to the extent that the Multichain-backed $USDC token was the de-facto USDC on the chain) - and got wrecked together with its dependency. |
Beta Was this translation helpful? Give feedback.
-
It's called trust. See Aave's pioneering work on credit delegation.
Totally. But the point of this discussion was to brainstorm and see how far we can go with this concept. Note: not all discussions are meant to lead to an implementation spec. Some are meant just for idea-sharing purposes.
Yep.
Yep :D |
Beta Was this translation helpful? Give feedback.
-
That's a very well-thought (economically-speaking) development from AAVE 👏 Now, regarding how it relates to our discussion. Here's a quote from the Guide you've shared: "The enforcement of the loan and its terms are agreed upon between the depositor and borrowers, which can be either off-chain via legal agreements or on-chain via smart contracts." So, the viability of the system is ensured (to a certain degree) by the formal (or not) agreements between the depositor and borrowers on- or off-chain. Just like AAVE's Credit Delegation couldn't work without the depositor and borrowers being able to agree on the terms of their cooperation wrt borrowing the depositor's credit, minting tokens on a target chain from the tokens of a source chain (such that the formers are pegged in value to the latters) couldn't work without the source chain tokens being "locked" somewhere on the source chain (or even destroyed - and re-created later, the way ElkNet does it) for as long as their "equivalents" are navigating the target chain. A simple example demonstrating the above: you use your $USDC on Arbitrum to mint $NUTS on SabVM, but, then, go and transfer those $USDC to me. Why would anyone, after this, think that $NUTS derive any value from the no-longer-your $USDC?
Not sure what to reply to this 😅 I hope you didn't mean that we should go less technical/deep in future discussions. |
Beta Was this translation helpful? Give feedback.
-
Yep. That's exactly what I am saying, too.
Not true If you trust the sender to eventually pay, you're find with just minting on the Sablier chain.
Because of trust that you will eventually repay.
No. I didn't mean that. Just that sometimes we can gloss over the implementation details and focus on the high-level concepts. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like NodeKit's Javelin (a fellow CSX participant) might be the solution here: |
Beta Was this translation helpful? Give feedback.
-
One recurring theme in my recent conversations about Sablier Mainnet is the issue of the hurdle of bridging tokens over.
On the one hand, this is not such a big deal because stream senders will be "superspreaders", i.e., only they have to bridge tokens, and thus recipients will be implicitly onboarded. On the other hand, some users may prefer not to bother with yet-another-chain. There is such a thing as multichain fatigue.
These users would be able to use our EVM Flow product, but there may be another interesting way to appease them: cross-chain collateralization of streams!
The idea is to let users deposit funds on an existing rollup, e.g. Arbitrum or Optimism, and use that as funding for the streams started on the Sablier rollup. The contract would allow users to top up.
What makes this possible is storage proofs, a new technology that allows contracts deployed to one rollup to access data from another rollup.
References:
Beta Was this translation helpful? Give feedback.
All reactions