Gitcoin-$LEET

leet.md

Assume I’ve got 500 ADY tokens

1. Every personal token created is essentially a new ERC20 token
2. Ability to allow users to do a one click create (via your web3 wallet). I’d be able to set
   • Token name = ADY
   • Total Supply (500 in this case )
   • Exchange Rate (aka 1 ADY == X DAI)
   • Redemption Value : An attribute called redemption which would be a unit of time
3. Can I increase the number of ADY token at a later point in time for v1 ?
4. Would I be able to increase token value (aka 1 ADY == X + Y DAI )
5. Does the value of token vary as the number of ADY tokens I hold reduce / is it always constant ? (Is the former what we refer to as the bonding curve)
6. The need to build a personal token explorer is simply to list how much each personal token is valued at + the transaction history / was it much more ?
7. Can the token only be exchanged between the creator and a redeemer ? Example: If Frank bought 10 tokens from me -> Could he send my tokens to Kevin ?

Questions about proposal

Why do we feel building this in-house into the Gitcoin platform would be better that integrating with a service like Uniswap. Not very clear on the legal issues. Wouldn’t we be re-inventing the wheel ? Is it solely for adding the redemption value attribute ?

Fitting into the Gitcoin lifecycle

General Flow

Anyone could purchase my ADY tokens from me by visiting my profile When you purchase 50 ADY tokens (50DAI) you’d spend 50 DAI (which goes into an escrow) I’d receive a redemption request If I approve -> I get 50 DAI and you get those 50 ADY tokens which you can use at a later point in time ? If I reject -> you get back your 50 DAI When do the 50 ADY tokens get burned ?

Bounties

I assume the first integration we’d wanna look into is into Bounties Platform ? ( redemption attribute of time makes sense )

Assumptions

• As a token creator I've got 500 ADY tokens (assume conversion rate is 1 ADY == 1DAI )
• A bounty of 50 DAI needs to be created and the funder want’s me to work this

Flow

After v1 is built out

1. A funder would be able create a bounty ->
   1. Create a bounty with ERC-20 tokens using the standard bounties v1 contract )
   2. Cross-Chain bounties have a diff flow using QR code (no standard bounties contract)
   3. (NEW) Create a bounty after using / purchasing ADY tokens (no standard bounties contract)
2. By choosing (iii) , the funder would want to use 50 ADY tokens

   1. If funder purchases ADY coins -> I’d be sent a redemption request. (Would the bounty be created only after it’s accepted ? )

      -   Upon accepting -> I get 50 DAI and funder get's 50 ADY tokens ?
      -   Upon rejecting -> the funder get's back 50 DAI ?
      

   2. If funder uses existing ADY coins -> the bounty would be created & reserved for me (what if I don’t have the bandwidth ? Wouldn’t that frustrate the funder as bounties usually have a timeline by which they need to be built out ?

In other words, would I be right in saying that funding a bounty via personal tokens -> means funder pays the contributor money upfront before completion of work ?

How would this differ from the reserve for user feature already available on platform which

1. Let’s funder create a bounty and reserve it for a user
2. Let the funder open up it to to other contributors after a given period
3. Avoid the extra step of creating a new personal token
4. No waiting time (cause the redemption request flow does not exist)

Townsquare

• When creators can offer 1:1 time ? Essentially booking your calendar ? What would happen if the creator isn't able to commit despite accepting the redemption request. Does they pay back the reciever an equivalent amount in an ERC-20 token (AKA send DAI to reciever address)
• Does tipping via a personal token make sense cause it would be easier for me tip anyone in ETH / ERC-20 token

Grants

Are personal tokens useful here

Kudos

Are personal tokens useful here

Answers to Adityas questions:

Can I increase the number of ADY token at a later point in time for v1?

Yes, the creator should be given the ability to issuing more tokens using the same contract that was used at creation. We could potentially set a "max supply" as a failsafe but don't this being necessary for v1.

Would I be able to increase token value (aka 1 ADY == X + Y DAI )

Yes, a creator should be able to adjust the cost per token. For V1, let's assume that all personal tokens are being priced only in DAI.

Does the value of token vary as the number of ADY tokens I hold reduce / is it always constant ? (Is the former what we refer to as the bonding curve)

The value of ADY tokens is fixed. If 1 ADY = 100 DAI then 10 ADY = 1000 DAI. We can experiment with wholesale prices later, but for V1 prices should be fixed - no bonding curves to start.

The need to build a personal token explorer is simply to list how much each personal token is valued at + the transaction history / was it much more ?

Correct. What the dashboard displays needs to be finalized but from a high level, simply a place to see ALL personal tokens, their cost, # of holders and volume. The goal (from my perspective) is to create a "leaderboard" showing those users whos personal tokens are most highly in demand. Here is a good reference although our parameters will be different: https://www.tokensets.com/explore

Can the token only be exchanged between the creator and a redeemer ? Example: If Frank bought 10 tokens from me -> Could he send my tokens to Kevin ?

This is where things get tricky. I am inclined to say that all tokens are transferable but this inherently opens up secondary market trading as anyone could then spin up a Uniswap pool. Curious to hear other's feedback on this.

Why do we feel building this in-house into the Gitcoin platform would be better that integrating with a service like Uniswap. Not very clear on the legal issues. Wouldn’t we be re-inventing the wheel ? Is it solely for adding the redemption value attribute?

Using Unsiwap would require creators to deposit capital to create a liquidity pool. Using tokensale contracts allows the creator to issue the contract solely for gas. The redemption aspect is a big factor here and from a legal perspective, trying to limit speculation in favor of tangible usage is crucial. We are happy to accommodate whatever Gitcoin sees fit regarding third-party integrations/composability.

General Flow

Dai is immediately transferred to the Creator upon purchase. No escrow.

For redemptions, personal tokens are placed in escrow. If accepted, the personal token is burned. If denied, the personal token is sent back to the Funder. For the sake of V1, we'll assume the Creator actually does the accepted work, although its likely we will need to consider arbitration in the event that a Creator accepts without actually doing it.

Flow

"In other words, would I be right in saying that funding a bounty via personal tokens -> means funder pays the contributor money upfront before completion of work ?"

Correct. Dai is paid to the Creator at purchase. R/e bandwidth, we were exploring a way for Funders to clearly see the Creators likelihood of accepting requests to better inform purchases before they happen.

"How would this differ?"

My intuition is that purchasing personal token makes the Creator more obligated to fulfill the work request. I am more likely to complete work requested by others if I willingly sold my time upfront as opposed to choosing to take on a reserved bounty when I see fit.

Townsquare, Grants, Kudo

Let's table these questions until after we've got the process itself ironed out :)

All personal tokens are ERC20's so no reason they couldn't be used in a similar fashion to other aspects of that platform.

Answers to @frankchen07 questions:

"Borrowing in the future" is key. Reputation plays a huge role here so very much interested in how we can tie together Gitcoin's existing reputation system (or build new aspects in tandem).

In response to the "redemption" aspect, it's less about the incentive to engage, more about the flow of those who do engage. Existing personal token platforms largely lack this and as a result, many personal tokens are not being used as much as they could be.

To paint a clear example, in order for me to redeem $MAGIC or $PEW, I need to go to Telegram, find Ameen's Telegram, get his attention, ETH address and verbal commitment and then send tokens OTC and hope he does the work/request. With this redemption system in place, Funders can be confident that they can use their tokens without having to hunt down contact info, addresses, etc. Lastly, this system should make it more obvious what given tokens can be redeemed for. (Something that other platforms currently lack).

What is the unit of denomination?

This is Kevin's breadth verse depth question. Across the board, the creator should choose what the use cases are. However, I do believe having a uniform system (i.e. if I choose "time", 1 token = 1 hour of time) would be beneficial. We do not want to limit creativity, although new Creators are likely to benefit from suggestions as to what the use-case coudl be (and token equivalent is).

How do we determine "billable" hours?

The creator sets their own "billable" hour. 1 token = X Dai.

Reputation

This requires a larger discussion. My intuition is to suggest an eBay or Amazon-like feedback system in which Funders have the ability to leave feedback and rate (5 star scale?) relative to how the process went. This feedback would likely be displayed both on the Creator's profile and on the Token Explorer to make it easier for Funders to see a Creator's previous performance.

What dictates when that resource is used?

Great points and definitely a big pain point. Yes, there is a big degree of trust here. While the reputation just described will play a role, it's possible that Gitcoin can slash and or freeze a Creator's tokens in the event that they have been proven to be unresponsive or malicious. This point also make a strong case for making tokens transferable so that they can be liquidated on a secondary market, although this is probably a possibility we should re-enforce upon purchasing in the first place. (i.e. the risk that a Creator may not respond/accept your request). Open to any and all thoughts on how to better enforce Creator usage.

Trust

This is actually where we may see some success. By leading with the narrative that this is experimental and trust is largely required, we can tailor this experience toward active users who value strong reputations. This is a case for "Why Tribes?" as it's likely that people within a given Tribe are more likely to trust one another (and use their tokens). To summarize, personal tokens can be viewed as a way to increase your reputation beyond what is currently offered. Happy to be challenged on this!

Yes, let's focus on token <> token transfers later ;)

Escrow

We are open to whatever system Gitcoin sees fit. The core principle is being able to place personal tokens in escrow when being redeemed and having them either a) burned when accepted or b) returned to the creator if denied.

The core value of this is that both sides can be confident the token will be transferred in the appropriate manner regardless of whether a redemption is accepted/denied.