Cancel on Partial withdraw

[sneg55]

We need a doc page on a workaround with Cron for canceling after partial withdrawal from the stream. A few users recently asked me about this case.

[PaulRBerg]

A guide would be helpful, but better than that would be a modification in Lockup/ Airstreams that allows for dynamic claim amounts based on how early (or late) the recipients claim. I will open a separate discussion about this.

[smol-ninja]

Just to confirm, we need a bash script for this, right?

[PaulRBerg]

@smol-ninja the script can be written in any language, I guess. The catch is to make it easy to automate — maybe via GitHub Actions?

[smol-ninja]

Since it would require to be pinged upon withdrawal, it won't be possible to do it via GitHub action (or did you mean GitHub actions to deploy the script?).

• First, campaign creators would need access to all the stream IDs generated as a result of claims. That means tracking Claim event to identify and store streamId on a local db.
• Then tracking withdraw events emitted by those stream Ids.

Building this would require connecting to subgraph endpoints. Through guide, we can provide information on what all they will need to build this. But if we want to provide a full code, this looks like a separate repo work.

[PaulRBerg]

Couldn't it be done by a GitHub Actions workflow by using a Cron job that uses cancelMultiple and listens to emitted events, looking for all the streams that have been canceled since the last time the script was run?

Though I think that may lead to a very long run time, and so GitHub may halt the execution.

So a separate repo with custom scripts makes more sense. Feel free to do that.

[smol-ninja]

This has a big caveat. Because the withdraw function is public, a malicious actor could use it to trigger withdrawals across all streams, causing them to be canceled by the cron job. For this reason, I believe it’s not a good idea to document this. If the goal is to prevent users from withdrawing from their streams, senders should consider implementing a timelock stream instead.

What do you guys think?

[PaulRBerg]

You are absolutely correct @smol-ninja.

I see no way out of this other than implementing the airdrop contract with variable claim amounts.