paritytech / polkadot-testnet-faucet

https://faucet.polkadot.io/
MIT License
36 stars 34 forks source link

Generic Faucet for parachain tokens #455

Open franciscoaguirre opened 1 month ago

franciscoaguirre commented 1 month ago

Hello! First of all, I love using the faucet for getting testnet tokens, the process is very simple and helps with development. When trying to test out interactions between the system parachains and other parachains in the ecosystem though, I found that most of them either keep their own faucet or don't have a faucet of their own. We should be able to make this faucet generic for providing other parachain tokens as well by getting those tokens via teleports (for assets registered on asset hub) to an asset hub account for the faucet and then distributing them via teleports to the corresponding accounts on those parachains. I think it would ease testnet development in the ecosystem. What do you think?

mordamax commented 1 month ago

Hello @franciscoaguirre. Thanks for the feedback

So far we saw that people would just fork this project and update it with their own configs, rpcs, parachain ids and even branded look

This should support teleports as well (example)

There are 2 ways to set this up - web and/or matrix, both support transfer or teleport

The primary reason we recommend to fork & deploy on their own - we don't want to manage too many addresses and top them up to keep a steady token balance. + with PAPI it's better they keep it up to date on their own

I agree that it's not the easiest way, but there are some other potential ways to ease the testnet development.

lovelaced commented 1 month ago

There's also https://substratefaucet.xyz/ which was treasury funded (iirc) but whenever I've tried it, the faucet is always out of tokens.

mutantcornholio commented 1 month ago

Hi @franciscoaguirre!

I've actually suggested this idea some time ago, but it didn't get much traction back then. Mostly because it would be a considerable rewrite, as currently faucet only supports one network / token per server instance. Using PAPI for generic solutions is also not that straightforward, but probably doable, one way or another.

And, there's the question of maintaining the balance. The way I see it, we'll need to shift the responsibility to the networks, and provide then with some kind of feedback, to tell if the balance becomes too low (matrix bot? prometheus endpoint?).