Assume I’ve got 500 ADY tokens
- Every personal token created is essentially a new ERC20 token
- 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
- Can I increase the number of ADY token at a later point in time for v1 ?
- Would I be able to increase token value (aka 1 ADY == X + Y 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 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 ?
- 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 ?
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 ?
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 ?
I assume the first integration we’d wanna look into is into Bounties Platform ? ( redemption attribute of time makes sense )
- 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
After v1 is built out
- A funder would be able create a bounty ->
- Create a bounty with ERC-20 tokens using the standard bounties v1 contract )
- Cross-Chain bounties have a diff flow using QR code (no standard bounties contract)
- (NEW) Create a bounty after using / purchasing ADY tokens (no standard bounties contract)
- By choosing (iii) , the funder would want to use 50 ADY tokens
-
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 ?
-
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
- Let’s funder create a bounty and reserve it for a user
- Let the funder open up it to to other contributors after a given period
- Avoid the extra step of creating a new personal token
- No waiting time (cause the redemption request flow does not exist)
- 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
Are personal tokens useful here
Are personal tokens useful here
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.