RFC: DIP for Simplifying Testnet Token Distribution for Workshops at DEVCon(nect)?

Devcon Improvement Proposals (DIPs)
1

RFC: DIP for Simplifying Testnet Token Distribution for Workshops at DEVCon(nect)?

Before finalizing this as a DIP, we seek feedback from the community. We’re open to suggestions, modifications, and any potential logistical concerns that might need addressing. Since DevCon is approaching fast, we ask the community to consider this as soon as possible.

Authors: kkonrad.eth; hugo0.eth. We would like to thank Ligi for the initial inspiration at EthBerlin3 and idea of potentially implementing this as a DIP.

Abstract

This DIP would propose a method to simplify the process of distributing testnet tokens at DEVCon(nect). Specifically, a token claim link should be send with each registration welcome email. This an incremental improvement over the clever distribution method development for EthBerlin3.

Motivation

At Ethereum workshops, participants often need testnet Ether for their experiments and prototypes. Currently, obtaining these tokens can be an inconvenient process, detracting from the main objectives of the event. At EthBerlin3, an innovative method was used where scratch cards were handed out to distribute Goerli testnet tokens. However, each gift card corresponded to a new externally owned account (EOA), and users had to manually enter a seed phrase to gain access. We aim to further streamline this process.

We want to streamline the process of receiving testnet tokens by sending a claim link to every participant of the workshops in their welcome email.

Specification

Proposal: Distribute testnet tokens by including a link in each registration confirmation email.

Mechanism:

  1. Participants register for DEVCon(nect).
  2. Upon successful registration, they receive a confirmation email. This email will contain a unique link or set of unique links.
  3. By clicking on the link, participants are taken to a webpage where they can directly claim their testnet tokens to their preferred wallet address. Each link is claimable only once (it is not a faucet).

Implementation Details:

We intend to build this functionality as a plugin on the Pretix platform. Pretix already supports merge mailing via Python scripts for attestations (see GitHub - efdevcon/pretix-attestation-placeholder-plugin: Pretix plugin to support placeholders for attestations), a similar mechanism can be used to dispatch unique links to participants. This system will allow us to send thousands of emails with individualized token claiming links efficiently.

Each link is a Peanut link. When a link is created, funds that are being sent are deposited into a Peanut smart contract. This contract holds the funds until they are unlocked using the link in the future. Each time tokens are deposited into a contract a seed is created to protect the funds. This is used to deterministically generate an asymmetric key pair, the public key of which is stored along with the funds in the Peanut smart contract. Each link follows the same basic structure: https://peanut.to/claim?c=CHAIN&i=INDEX&v=VERSION&p=KEY. See some example links below. You can try generating some yourself here. The tokens being sent along with the public key are stored by calling makeDeposit in the Peanut smart contract. The on chain function emits a DepositEvent which contains an index parameter, this is the slot within the Peanut contract where the funds will be stored until claimed.

The Peanut SDK and the Peanut App can be used to mass generate such links for the mailing list.

Rationale

The proposed method removes the need for physical distribution, reduces manual input errors, and ensures that participants have access to testnet tokens as soon as they’re registered. This will lead to smoother onboarding and a better overall experience at the workshops. Given that Devconnect is soon, we believe this proposal, if accepted, can be swiftly implemented and tested.

Implementation

The implementation will require:

  1. Forking the GitHub - efdevcon/pretix-attestation-placeholder-plugin: Pretix plugin to support placeholders for attestations and integrating the token distribution system using GitHub - peanutprotocol/peanut-sdk: NPM package for the Peanut Protocol SDK (see more here).
  2. Setting up a system to generate unique links for token claims.
  3. Implementing the merge mailing script to dispatch these links in registration confirmation emails.

Test Cases

Before final implementation, a smaller test run can be conducted:

  1. A mock event can be set up on Devconnect’s Pretix.
  2. The pretix merge mailing system can be utilized to send out testnet token links.
  3. The links can be tested and other potential issues uncovered.

References

Example Links

4 Likes
2

Hi @kkonrad, Hugo, this sounds great!

I would love to get @Ivan_Chub and 0xParc’s input here as it sounds like a perfect use-case for PCDs.See DIP regarding PCD-based Ticketing for Devconnect

PCDs allow you to proof you’re a ticket holder without revealing or leaking additional info (e.g. matching emails/wallets). I think it could be interesting to explore how we can integrate using that instead of a Pretix plugin.

3 Likes
3

Hi all! Super cool. Thanks for posting. Few thoughts/questions:

  1. I think Peanut is super cool. Awesome in fact. I’ve personally looked for easier ways to send crypto to friends / newbies / etc and this seems like a useful project.
  2. Is it open source?
  3. What is the risk analysis here? What are the trust assumptions? Front-end could rug?
  4. What are the protocols / projects that are most similar to peanut.to ?
  5. It is not uncommon that we get requests from third-party teams/projects/protocols/etc to give things or grant things to attendees. They either ask us to: share emails (we don’t), send info in emails on behalf of them (we also generally do not), share list of attendees (we don’t).
  6. Some of these requests are more bona fide than others. This one is more bona fide since it’s distributing testnet ETH for a new Ethereum testnet, although it would also be a big signal and advertising push for Peanut.to .
  7. Ultimately, we are trying to make it easier for anyone to permissionlessly prove that they had a valid Devconnect ticket, with the goal that third-party teams/projects/protocols no longer have to rely on our team to be able to identify Devconnect team members. This was the goal with attestation-based ticketing we experimented with at Devcon 6 and Devconnect AMS, and the PCD-based ticketing we are planning to experiment with for Devconnect AMS. With this, teams / contracts / applications can give special discounts, whitelisted access, free things, etc to Devconnect attendees without needing anything from our team.
  8. Part of me thinks that’s the route that should be taken here, similar to what Wesley suggested above: a Holesky testnet eth faucet is created, and for sybil resistance, we verify that the user can make a PCD proof that they have a unique Devconnect ticket.
    6b. Part of me also wonders: what if another team that does something very similar to peanut.to approaches us to ask why we chose peanut instead of their project? Why should we choose one over the other?
    6c. Also: what if after we do this, Scroll or Arbitrum or [insert your favorite L2 here] approaches us to offer to send free testnet eth to all Devconnect attendees. It’s free after all, encourages more adoption of rollups which is important, but where do we draw the line?
  9. The other part of me thinks we should analyze this more simply:
    7a. Getting access to testnet eth on a new network for more developers is net good for ethereum.
    7b. Perhaps there is no other tool that does this like peanut.to. Perhaps we should use what’s available now, and not wait for a faucet that integrates PCDs to be available.
    7c. There is also clearly a difference between distributing testnet eth to an ethereum testnet vs a rollup testnet. I think we can very neutrally do the former, and refuse to do the later due to our desire to be neutral.
    7d. Even if there was a faucet, that’s much more “pull” rather than “push”. It would depend on users actually going to xyzfaucet .com, proving their PCD, and claiming the eth. Very likely many fewer users would actually go claim that eth, than if we used a Peanut.to link like proposed here. There is a real advantage here being able to market that 1) you can claim holesky testnet ether here, and 2) implicitly sharing/reminding that Holesky is a new testnet and it’s live.

Those are my personal running thoughts. Still thinking through more, curious for your responses to some of those questions above.

4 Likes
4

Hey Skylar!

Thanks! That’s great to hear :slight_smile: I’ll answer your questions in a way that easy to follow

1 & 3 . Peanut Protocol is open source. There are two main trust assumptions.
i) for Pretix specifically, the emailing server. The emailing server will have access to the contents of the mail merge and could in theory steal the funds.
ii) The frontend, as long as it runs, the Peanut code (all repos are open source) cannot rug the funds either. The funds are never held in custody and the keypairs are generated on the local devices of the users.

  1. There are similar projects, the list includes TipLink and Pip. Both, as far as I understand them, are more centralised and are not protocols. TipLink is a noob-friendly Solana wallet. This also answers your question of why not another project: Peanut is the only one that is somewhat decentralised and fully non-custodially.

5 & 6. Peanut would not be collecting emails or anything as this would be a Pretix plugin run by Devcon. We don’t expect anything in return. Our main reason is to see how useful link-based token distributions actually can be. No better way to test than on testnet tokens.
In terms of what to do when Arbitrum, Scroll etc approaches Devconnect to also distribute tokens, it’s worth noting that Peanut Links will allow for multi-token claiming soon. So one could get a whole bunch of testnet tokens. At the same time, there is not that much reason for this because L2s have testnet bridges that are decent and bridging not as big of a pain as using faucets in the first place.

7 & 8: Sure thing! Both approaches have advantages and disadvantages. PCDs seem more ambitious and it would be amazing to see some real-world use of zk. Links are just a simple plugin that can be used with the existing setup. It doesn’t require too much infrastructure beyond the Pretix plugin which can be based on a fork of the Pretix Attestation Placeholder Plugin by ligi, nurts, a5net & kvbik. Maybe in the future, once PCDs are implemented, these could go hand-in-hand? For now, links seem like an easy and fast solution.
In terms of creating more awareness around holesky, this can be done very well with links, because users can be redirected to a custom docs or welcome page. On top of this, the frontend takes care of adding the network etc. It’s definitely a different feel than just being told that you’ve received something or having to go to a faucet.

3 Likes