ORIGINAL MintEXP Actual Application Docs (Webapp & SDK)

[Reecepbcups]

from craft/boring.pdf

EXAMPLE:

https://gist.github.com/Reecepbcups/4bdc9c5df2f4c366b47a7be1ebb5e378

Rough Outline

struct RequestExpMint: 
- string walletToBeWhitelisted      
- string depositAssets                  (ex. $ETH, BTC, ATOM, etc -DAO needs mutlisig wallets for)
- int     maxMintableExp              (max number of exp they can mint, regardless of price)
- string closePoolDate                 (After pass, ISO 8601 format for when they can no longer mint EXP from this proposal)
- string vestingPeriodEnd            (ISO 8601 format for when they can burn and redeem their exp)

This means we can handle this with a modified SoftwareUpgradeProposal

REST API:

ex: https://api.chihuahua.wtf/cosmos/gov/v1beta1/proposals where "@type": "/cosmos.craft.v1beta2.RequestExpAssetProposal" & "status": "PROPOSAL_STATUS_PASSED"

{
  "proposal_id": "1",
  "content": {
    "@type": "/cosmos.craft.v1beta2.RequestExpProposal",
    "title": "Requesting EXP to contribute to the CRAFT DAO",
    "description": "what I can contribute here, why I should be accepted plz"
    "walletToBeWhitelisted": "craft10r39fueph9fq7a6lgswu4zdsg8t3gxlqd6lnf0", 
    "depositPools": ["BTC", "ETH", "ATOM"],     // Do we really need this?
    "maxExpMint": 10000,                       // EXP will mint at NAV/expOutstanding via webapp @ deposit time
    "closePoolDate": "2022-08-15T12:00:00Z",   // when they can no longer mint exp from this proposal, 08/2022
    "vestingPeriodEnd": "2030-01-01T00:00:00Z",  // 01/2030 they can burn EXP
   },
   "status": "PROPOSAL_STATUS_PASSED",
  }
}

// could also use epoch times if easier backend, this just makes prop easier to read for DAO holders

WEBAPP:

when someone request to mint, it can search through passed proposals with type cosmos.craft.v1beta2.RequestExpProposal.
It will ensure the "closePoolDate" has not passed & that the recipiant wallet are allowed to mint. If not, disallow the user

From here it can allow minting EXP in the given POOLS required by the wallet based on their deposit

Webapp also takes care of the deposit rates using following formulas

expPrice = (NAV/TokensOutstanding)      
ethDepositRate=(ethPrice/expUSDPrice)
atomDepositRate=(atomPrice/expUSDPrice)
...

Questions:

• So like the Token Faucet idea I had in game for CRAFT (iptable whitelist our machines), can we mint & faucet the same with EXP? may require adding MintCoins() from bankKeeper and removing how it sends from local acc -> chain

• Can we mint tokens with vesting times? or can this only be done via genesis

• Can we just edit x/bank/client/cli/tx.go to deny sending EXP token in the message?

[catShaark]

Can we just edit x/bank/client/cli/tx.go to deny sending EXP token in the message? no we can't

[vuong177]

Can we mint tokens with vesting times? or can this only be done via genesis?
I think we can't.

According to the Cosmos-sdk documentation:
The requirements for this vesting account is that it should be initialized during genesis with a starting balance X and a vesting end time ET.

vesting-sdk-doc

[faddat]

Hi gents, on my call with reece, I basically encountered that this is a non-viable solution:

DAO funds really have to be kept in a module account so that their security is consensus enforced.

Our end solution is likely to look like applying some of /x/groups concepts to /x/gov

we can mint tokens that have the "forever vesting-- using cosmos sdk messages (gov v1beta2)

[Reecepbcups]

Will post new issue tomorrow outlining this in a more consensus driven way

[Reecepbcups]

update tom likes this better - says even if we value the EXP side of things at 0, CRAFT still has value.
EXP doesn't have to be on chain, the above proposal just has to add constant swap rates
ex: proposal 10eth -> 5000EXP

we need other assets non ibc native so proposals can fund other incentives
ex: DAO gets 10ETH to purchase NFT's, and then distributes these to random Land Plot owners.
This ETH wallet is held by DAO members and is multisig

The above solution IS webapp based and not state driven, but aligns with the DAOs goals
if we value EXP at 0, then CRAFT still has massive value

ROUGHLY:

{
    "proposal_id": "1",
    "content": {
      "@type": "/cosmos.craft.v1beta2.RequestExpProposal",
      "title": "Requesting EXP to contribute to the CRAFT DAO",
      "description": "ETH so the DAO can purchase NFT's for the community, BTC just to increase the DAO value",
      "walletToBeWhitelisted": "craft10r39fueph9fq7a6lgswu4zdsg8t3gxlqd6lnf0", 
      "depositPools": {
        "BTC": {
            "amount": 10,
            "expRequest": 5000,
            "closePoolDate": "2022-08-15T12:00:00Z"
        },
        "ETH": {
            "amount": 5,
            "expRequest": 250,
            "closePoolDate": "2022-08-15T12:00:00Z"
        },
      },                                 
      "vestingPeriodEnd": "2030-01-01T00:00:00Z"
    },
    "status": "PROPOSAL_STATUS_PASSED"
}

or

      "depositPools": {
        "BTC": {
            "depositAmount": 10,
            "expPerOneDeposit": 500, // so total is 5000exp here
            "closePoolDate": "2022-08-15T12:00:00Z"
        },

then the CraftMint module would only be allowed to mint the max amount above. Logic:
OnProposalPass, update CraftMintKeeper depositAmount*depositRate for each asset (ex: 1BTC @ 10,000EXP per)
Then the minter can now at max mint 10,000 since the proposal passed. Limiting downside of EXP to a rouge node