Superfluid’s GDA feature enables token distributors to transfer tokens to recipients via GDA pools. Currently, the recipient must establish an explicit pool connection to utilize the received balances in real-time, with a limited number of slots available for each address (256, to be precise). Notably, the more pools an account has connected for a token, the higher the gas cost for calculating its balance for that token.
GDA Auto-Connect Feature
A proposed new feature, “GDA auto-connect,” enables smart contracts to connect pools on behalf of the recipient.
The trade-off of allowing smart contracts to connect pools on behalf of the recipient, and not to have all available slots spammed by malicious actors, has been discussed numerous times. We bring forward a version of such trade-offs in this merged PR, and request for more comments from the community members before we release and roll-out to the networks. While you should find all the details from the PR link, the TL;DR of the design decisions was:
This feature will be available for all tokens.
Anyone can tryConnectPoolFor for others.
There is a hard-coded limit of 4 auto-connect slots for tryConnectPoolFor, for each token, to prevent spamming.
Existing account opt-in by default. However, accounts can opt out of this feature using GDA.setConnectPermission(false)
This will be a significant UX improvement for onboarding new users and helping ensure they feel the difference between Superfluid’s gasless settlement and other “streaming” protocols’ deposit-withdraw models imo. Having a user’s first experience with GDAs be “connect to pool” clouded that picture. We’ll still need to manage connections with the slot limit, but hopefully that’s after the user has had a chance to learn more about Superfluid by using it.
We’re excited to use this in a couple of our projects. Will it be retroactively available to already deployed GDAs?
If the 4 auto-connect slots start to be reliably saturated, you could consider a sort of (per-token?) fee market for GDA deployers to access those slots. It’s a UX improvement serious developers would gladly pay for, while gas griefers wouldn’t.
There’d be lots to consider and get right, but it fits with the design principle: tax the congestible (ie a finite number of slots) & subsidize the public goods (ie the rest of the protocol).
@graven thanks for that positive feedback and for confirming that this would be a valuable UX improvement.
The current choice of 4 auto-connect slots is on the conservative side.
If it turns out that this is still a considerable limitation / UX impairment, we could indeed iterate on the design. A related fee market is an interesting idea which didn’t come up yet, a good addition to the set of options for dealing with the challenge.
We’ll definitely use it with Season 3 Ideas - Farcaster Streaming Tips. Our launch target is by the end of this month, but this wouldn’t be a blocker. Just a nice onboarding UX improvement.
We’re using Base Sepolia for testing. If you’re able to roll it out there so we can prep, that’d be helpful.
One more idea/piece of feedback based on our specific use case:
For streaming tips, each tipper will have their own GDA.
In practice, we’ll blow by the four slots.
But we’re going to be using our token, which is launched expressly for tipping through our app.
Because of that, autoconnect slots for our token feel less like a commons that needs to be protected from our app’s overuse and more like something that we, as the creators, should exercise judgment on as part of the product.
So, another angle for slot provisioning to consider is allowing token creators to set a much higher autoconnect threshold for themselves/an allowlist of 3rd party connectors.
This would still prevent random gas griefers in our tipping token and our more extensive use of slots wouldn’t affect gas for other apps/tokens.
Yeah, and we’ve done some gas profiling to see how things scale up to that hard limit. We’ll have to manage connections accordingly. We can follow up more in DMs.