You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The purpose of this smart contract is to allow talent to convert their cash (intended for base payroll) into uCR and/or UBQ.
Benefits
We can incentivize talent to leave cash equivalents (e.g. USDC/DAI) with us to reduce our burn rate.
We can skip negotiating the uCR/UBQ compensation with talent during the hiring process and have them handle it permissionlessly via this contract.
Specification
The contract should...
be pausable.
be manually topped up with UBQ and uCR for security reasons.
have a token acceptance whitelist (we can start with USDC, DAI, LUSD)
have a risk premium getter/setter for UBQ
this should be defined as a separate smart contract to allow for algorithmic risk premium
have a risk premium getter/setter for uCR
this should be defined as a separate smart contract to allow for algorithmic risk premium
automatically transfers to the Ubiquity Treasury
Draft Contact Methods
setTreasuryAddress(addresstreasuryCalculator) onlyTreasury // treasuryCalculator should query the [manager contract](https://etherscan.io/address/0x4DA97a8b831C345dBe6d16FF7432DF2b7b776d98) for the address of the treasurygetTreasuryAddress() returns (address)
setGovernanceTokenAddress(addresstokenAddress) onlyTreasury
setGovernanceTokenRiskPremium(addressriskPremiumCalculator) onlyTreasury
getGovernanceTokenRiskPremium() returns (uint256)
setCreditTokenAddress(addresstokenAddress) onlyTreasury
setCreditTokenRiskPremium(addressriskPremiumCalculator) onlyTreasury
getCreditTokenRiskPremium() returns (uint256)
depositForGovernanceTokens(uint256amount) pauseable // transfers UBQ to caller; transfers deposit to treasury.depositForCreditTokens(uint256amount) pauseable // transfers uCR to caller; transfers deposit to treasury.freeze() onlyTreasury // pauses all
Context
I was thinking we could assign an economy wide "risk premium" for uCR. This can represent the rate we pay it out. e.g.
"2" means 2 uCR = 1 USDC
"1.5" means 1.5 uCR = 1 USDC
(This also can apply for UBQ.)
I think it makes sense to think in these terms because now that it is a full blown bear market, perhaps the risk premium should be something higher, like "5"
Would be amazing to set at the smart contract level, that way the talent we pay out can decide on their own how much they want to gamble. They could, for example, be always paid the base rate of USDC/DAI, but then have the ability to deposit into the smart contract to mint uCR. If the risk premium is 5, then $1000 of USDC will mint 5000 uCR.
This way we no longer have to negotiate this, as the worker can decide how much risk they want on the fly.
Theoretically we could do the same for UBQ.
Algorithmic Risk Premium (UBQ)
Another interesting idea is to algorithmically define the risk premium by calculating ETH price from the peak.
If ETH peak price was the following according to CoinGecko:
All-Time High $4,878.26 -76.0%
Nov 10, 2021 (7 months)
Ethereum Price $1,168.76
4878.26 / 1168.76 = 4.1738765872
Risk premium could be 4.1738765872 for UBQ.
I think the risk premium for alts should be a function of the entire market. I also think that UBQ risk premium should consider the UBQ market price (Uniswap etc) although this is more exploitable due to its smaller liquidity compared to ETH
Algorithmic Risk Premium (uCR)
This should be a function of the TWAP and consider how often we go above peg.
The idea is that if we're constantly above peg, and uCR is redeemable most of the time; a reasonable person should conclude that the risk (and its associated premium) should be lower for holding uCR.
If we're in a situation like we have been, where its been a long time since uCR has been redeemable, then its risk premium should go much higher!
UI/UXUI development work is expected.SoliditySolidity development work is expected.
1 participant
Converted from issue
This discussion was converted from issue #189 on July 06, 2022 10:28.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Overview
Objective
Benefits
uCR
/UBQ
compensation with talent during the hiring process and have them handle it permissionlessly via this contract.Specification
The contract should...
Draft Contact Methods
Context
I was thinking we could assign an economy wide "risk premium" for uCR. This can represent the rate we pay it out. e.g.
"2" means
2 uCR
=1 USDC
"1.5" means
1.5 uCR
=1 USDC
(This also can apply for UBQ.)
I think it makes sense to think in these terms because now that it is a full blown bear market, perhaps the risk premium should be something higher, like "5"
Would be amazing to set at the smart contract level, that way the talent we pay out can decide on their own how much they want to gamble. They could, for example, be always paid the base rate of USDC/DAI, but then have the ability to deposit into the smart contract to mint uCR. If the risk premium is 5, then $1000 of USDC will mint 5000 uCR.
This way we no longer have to negotiate this, as the worker can decide how much risk they want on the fly.
Theoretically we could do the same for UBQ.
Algorithmic Risk Premium (UBQ)
Another interesting idea is to algorithmically define the risk premium by calculating ETH price from the peak.
If ETH peak price was the following according to CoinGecko:
All-Time High
$4,878.26
-76.0%Nov 10, 2021 (7 months)
Ethereum Price
$1,168.76
4878.26 / 1168.76 = 4.1738765872
Risk premium could be
4.1738765872
forUBQ
.I think the risk premium for alts should be a function of the entire market. I also think that UBQ risk premium should consider the UBQ market price (Uniswap etc) although this is more exploitable due to its smaller liquidity compared to ETH
Algorithmic Risk Premium (uCR)
This should be a function of the TWAP and consider how often we go above peg.
Beta Was this translation helpful? Give feedback.
All reactions