banklessdao / bountybot Goto Github PK

Conversation started here:
Behold3th/discord-bots#4

Behold3th/discord-bots#3 (for keeping track of the conversation)

Is your feature request related to a problem? Please describe.
Currently the list of allowed currencies is hardcoded, and only accepts BANK. This implementation is a hold over previous work on DEGEN outside of the BB core team.

	async validateReward(guildMember: GuildMember, reward: BountyReward): Promise<void> {
		const ALLOWED_CURRENCIES = ['BANK'];
		const allowedRegex = new RegExp(ALLOWED_CURRENCIES.join('|'), 'i');
		const MAXIMUM_REWARD = 100000000.00;

		if (isNaN(reward.amount) || reward.amount <= 0 || reward.amount > MAXIMUM_REWARD
			|| !allowedRegex.test(reward.currencySymbol)) {
			await guildMember.send({
				content: `<@${guildMember.user.id}>\n` +
					'Please enter a valid reward value: \n ' +
					'- 100 million maximum currency\n ' +
					'- accepted currencies: ETH, BANK',
			});
			throw new ValidationError('Please try another reward.');
		}
	},
	

Describe the solution you'd like
As we continue our multitenancy store and grow Bounty Board use cases, we'll need to expand beyond just accepting BANK. While payments are handled on the social layer, we should protect users from things like spelling errors (I.e. USDC vs USBC), while still accepting tokens necessary to encourage usage.

Once we move from off-chain payments to on-chain payments, we can use wallet functionality to validate tokens for our users and accept payments on L1 and L2.

We also need to be able to allowlist token types for a specific customer: i.e. BanklessDAO wants to allow BANK rewards, while CityDAO wants to allow TempCity

Describe alternatives you've considered
There are are a few solutions:

Expand the list of hardcoded ALLOWED_CURRENCIES to include common tokens (Above Average Joe attempted to implement a USDC bounty a while back and was blocked) as well as the tokens of our first few customers. This is the most simple solution, but given we expect thousands of customers, (and thus will expect thousands of governance tokens), this will not scale, nor will it satisfy the complexity of allowlisting rewards for a given customer.

In the customers collection, add a list of customerRewards to the customizations top level object. customerRewards will explicitly list all allowlisted reward types

In the customers collection, add a list of customerRewards as a top level field. customerRewards will explicitly list all allowlisted reward types

Additional context
I think the decision here is between option 2 and 3. I'd recommend option 3. Semantically, an allowlist of reward types is a customer customization, and semantically does not belong in a top level field. However, when we eventually build an admin panel/console, the user experience of adding an allowlisted token should be simple. The customizations will be semantically related to the UI (we may even display a preview pane for the new colors)

The only difficulty here is that our mongo db connection is not currently implemented globally. The most latent operation for mongo is opening up a connection to a given database. It's recommended you re-use the mongo connection, and thus open the connection once and preserve it in a global static variable.

Given our dependency on DEGEN's code review process, I will implement option 1 for now, with this change a high priority after the fork