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

I'll just post here too since it'll be nice to keep it all in one document.

from the personal token readings:

I can see that personal tokens are sort of like a "promise" marketplace, buying pieces of other people's resources and in turn, funding the creator. It adds a redemption-like quality and allows for a "built-in" price setting on the token creator's part.

Thinking from a Gitcoin perspective, our business model currently sources larger deals from sponsors who would benefit from developer traction and Gitcoin developer talent from a Gitcoin hackathon. This is a foot in the door to eventually finding their Gitcoin Tribe - strong relationships that they can lean on for the forseeable future.

I still am not 100% convinced that a redeemable asset as an extra step between a funder and a developer gives either party any more incentive to engage. If anything, I see personal tokens as a possible method of combining reputation and also a different type of "contract" for doing work, but really it feels like the ability to "borrow into the future".

I've thought through an example:

• a personal token is a promise (borrowing in the future)
• let's say we have contributor bob
• bob mints a BOB token with a token address
• each BOB token is worth some monetary value and can be used to purchase services from bob

scenarios:

A. funder purchases BOB tokens, bob gets $$$, funder gets BOB tokens = hours of work from bob
B. funder comes back with work and BOB tokens, bob does satisfactory work, tokens get burned
C. bob has been doing amazing, bob's time is more valuable, token value changes with volume
D. funder comes back with work and BOB tokens, bob does shit work, tokens remain, rep value?
E. funder comes back with work and BOB tokens, bob doesn't do work, tokens remain, rep value?

1. In the first scenario what is the unit of denomination? Hours of work? Chunk of project completed? Could be anything?

2. How do we ensure that 1 hour of time is actually spent wisely? How do we determine "billable" hours?

3. How does the reputational aspect factor into examples B, C, D, and E? To me it's the delta in value of a particular as it gets burned or minted (possibly), but maybe it's something I don't understand yet here. In cases C and D, the tokens may or may not get returned, but how is reputation affected?

4. A product question to ask here is does the implementation of a personal token give a more streamlined case for a funder achieving their ideal end result, and a contributor achieving their end result? The main pro I see is that a contributor almost gets a "grant" ahead of time, and the funder gets to purchase future "resources" (hence my earlier comment about borrowing into the future). From an economic standpoint that's how most societies progress. (Edit - Aditya made a good point here, does that mean a contributor is at the beck and call of a funder once they have purchased tokens? What dictates when that resource is used?)

5. Looking at some of the mocks, this information will be tough to explain. There will be questions like "why not just a simple contract that funder and contributor enter into?" After all, personal tokens require a lot of trust (that work will be completed with pre-payment). Without a threat of damaging your personal reputation, it's not far off from a standard contract. It gets even harder to explain if alice comes along and wants to exchange some owocki token for bob token (potentially later iterations).

6. How will we handle escrow when we move off of the bounties contract?

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.