Hey guys, so there's been a decision upstream that has pretty deep effects on craft.

antehandler -> middleware -> antehandler

So basically we've got to rework craft and the promise of not breaking api's well, it won't be fulfilled. But that's okay, we won't dwell on that part.

In fact, Craft has become all of Notional's chains, will soon become Dig, and we'd like it to kick off a few hundred, or thousand chains.

Here's some relevant context, but it is fair to say that there are affects across the entire cosmos stack.

cosmos/cosmos-sdk#11979

cosmos/cosmos-sdk#11955

Specifcally, the SDK team has decided to revert to the antehandler pattern from middleware.

Here are the pieces of craft that are affected by this decision:

• exp module
• cosmwasm
• ibc 3.0
• groups module
• app.go
• nfts

So, that's to say that we're going to need to do significant rework here, I'd like to say that we need to give ourselves at least two weeks to sort that out, and then return to the previous release cadence.

Since Osmosis is sponsoring the use of craft as a template to be included in the sdk, and because I really want to see live integration tests across cosmos like the one that I made for Gaia that state syncs Gaia with numerous databases, I don't want to significantly change our plan or direction.

Cosmos SDK 46 reached v0.46.0-beta2, and had reached a stage where there were not supposed to be further large api breaking changes. We were actually ahead of schedule with craft, and the SDK itself was ahead of schedule, too (well, ahead of my anticipated schedule, anyhow).

Because of the reversion, some stuff will get easier, and other stuff is going to get harder.

• ibc-go v3.1.0 should work natively I think. The only changes will be to gov stuff, but not to middleware because it won't exist anymore. Here's relevant work:
  • cosmos/ibc-go#1274
  • cosmos/ibc-go#1205
• CosmWasm v1.0.0 in wasmd v0.27.0 should work, with only governance changes.
  • CosmWasm/wasmd#863

I'd like to circle back here, and really focus in on the templating aspect of the work here:

#108

Yesterday and the day before and today as well I spent a whole lot of time pulling starport out of Juno.

CosmosContracts/juno#207

So, let's run through our next steps, given all of this new information:

• Wait for the middleware reversion to be merged in the cosmos sdk:

• cosmos/cosmos-sdk#11985
• cosmos/cosmos-sdk#11979

• complete #108 by removing x/exp form craft, and adding "the base"

• cosmwasm
• ibc-go
• all modules, default in all the ways

We won't do an sdk 45 version of the base, to limit the scope of the work and lower our future technical debt.

• make a pull request of #108 to the cosmos sdk

So basically, the way that we'll be able to maintain all this code, and help others to maintain their code, is by separating the parts of developing a cosmos chain into two:

1) base
The base will include tendermint, cosmos-sdk, and ibc-go. There will be a cosmwasm flavored base, and a base without cosmwasm.

2) Features
First of all it is notable that if all features are in cosmwasm, you spin up a base, make a genesis, and just "go". Juno is a reasonable example of that playing out though I suspect that Juno will retain dominance in unpermissioned and that others will want to be a "flavored base" weather permissioned or not. We can think of osmosis as an app platform that is highly specalized around providing amm pools. It has features written in both cw and go.

Information about downstream consumers has been removed to prevent ambiguity.

Use cw-nfts given it is 721 spec
Current Rough Setup

• Update Real Estate plugin on server / update REST API to use property type, floorArea and totalVolume in MongoDB
• Setup 3 properties (no dynmap), and generate ERC20 / CW20 / 721 JSON format for that property. Use same JSON like structure as oNFT requirement. Redo python script for all in one (read from db, move into dict, output as Property-UUID.json)
• Add to CRAFT REST API the chain wasm rest queries we need to make akash team easier

Notes:
- Pinata fine? Or run our own IPFS? just putting data in the token_uri of the base64

• add "property_id" field in cw721 (rename cft721) for minting a property. Removes need for a 2nd API call after query of metadata.

OR just store the base64 / JSON data string in the token_uri. No reason to store off chain

Marketplace

update marketplace get all offerings query to show token_uri as well? Just so we dont have to query individual data for every query too. simplifies things

Can we get REST back or will @Reecepbcups need to grpc?

If @Reecepbcups needs to consume a grpc interface, is it worth the time?

• CosmWasm

  • Implement the protobufs in cosmos-sdk like stargaze

• Cosmos-sdk

  • NFT module in comsos-sdk (not sure if complete)

• Irismod

  • Not sure if this is relevant, since iris did https://github.com/bianjieai/tibc-go

• onft

  • nft standard from omniflix team

Give @Reecepbcups a menu of ways to do NFTs so we can choose one. Run this past @shanev from Stargaze.

Notes by @chalabi2

• Cosm JS on SDK 46 github issue cosmos/cosmjs#1093
• Testnet v4 v2 (Upgrade the chain to allow for sdk 46 beta)
• Reece mentioned issue creating NFT's on Craft
• Jacob Tom - May 1st 1 week block

Users will enter the DAO through a Queue.

they should propose their contribution to the DAO, typically in asset form, but the DAO can accept any type of contribution because the DAO is manually operated.

The DAO controls a governance proposal that can create exp and send it to a address.

joining the DAO is a gov prop for which the user spends craft

need to get addresses from cabcom

Not home, will fix later tonight / Sunday

snapshotDB, err := sdk.NewLevelDB("metadata", snapshotDir)
worked efore

We are reusing v0.1.1 for testnet-1 v2 equal stake anyways

craftd q bank balances craft1xxqq26cv7hsuzapvmrrkfrhjan7tuafawnj4qq --height 13641
- amount: "9999972000"
  denom: ucraft


craftd tx distribution withdraw-rewards $(craftd keys show pbcups --bech val -a) --commission --from $(craftd keys show pbcups -a) --chain-id craft-v4 --fees 200ucraft

craftd q tx --type=hash 22D119D1BA4694941DBBD5004FFC7AFCDA644BF9613F634AC957FCC072718922

craftd q bank balances craft1xxqq26cv7hsuzapvmrrkfrhjan7tuafawnj4qq --height 13642
- amount: "10000426400"
  denom: ucraft
- amount: "11"
  denom: uexp

2 validators have been jailed, so maybe when withdrawing it gave some EXP from their slash?

hi, could you guys please have a go at:

• applying the osmosis app.go style & folder structure here
• putting an osmosis-style upgrade template folders -- let's say two of them, with commented out text and example code here
• loading this into tinyport as a template
• test the tinyport template - the first template is called 46-cw
• take cosmwasm out of 46-cw, but keep everything else, and call that 46
• update the current template in tinyport to the latest versions for sdk 0.45.*, and to the osmosis app / upgrade folder style
• make a template for 0.45.*
• submit tinyport to the cosmos-sdk, in the folder template -- if you can think of a better name all the better. Just keep the templating features, and maybe the serve feature.

So we'd end up with 5 work products:

• Tinyport (or whatever we call it but let's not call it a scaffolding tool that name is cursed)

• SDK 46, ibc v3, CW template

• sdk 46, ibc v3 template

• sdk 45, ibc v3 + CW template

• sdk 45, ibc v3 template

Why?

Well, the primary lesson I got from craft so far is that integration testing isn't really happening between libraries in cosmos. But it's cool I think it's been a really great way to learn the relationships between things. When we started using 46, that was speculative.

but I ran

craftd testnet start --enable-logging

and saw months being saved....

So then we:

• upgraded ibc-go to support sdk 46
• upgraded cosmwasm to support sdk46
• (khanh I'll giv eyou edit on this issue-- you did some integration work here and you should describe it)

what kind of integration testing is needed?

• cosmwasm + mainline sdk
• IBC-go + mainline sdk
• mainline sdk + cw + IBC-go

Basically we need to test against IBC-go even if it no longer lives in the cosmos-sdk repo, and same for cosmwasm.

what else will this do?

I loved starport. But then spm and cosmoscmd broke maintenance, and frankly it’s too many features.

SDK repo contains simapp, but that isn’t a template. This is a templating solution for the cosmos sdk that we can maintain for:

• the prior version
• the tip of the repo

this way, we can notice and understand breaking changes in ci before people try to build with the code.

Write, and cover all test cases for craft.

• Keeper test
• CLI test
• types test

In order to test IBC, we should make a channel to some ibc-enabled mainnet, then fire a bunch of transactions. In the past I have used osmo and gaia for this test.

Create IBC testing for exp module .

• cosmos/cosmos-sdk#12221

... is a reversion from tm 35 to 34 because of what sounds like the same issue that we had with our testnet. I believe that these issues stem from problems in pure propagation in tendermint 35.

How much like middle wear this is another crossroads for us. We will need to Refactor CW and ABC go once again if SDK 46 reverts to TM 35. I assume that the changes will be approximately as large as the middle where changes so about one week on timeline. When I was speaking with Chalabi earlier he suggested, why don't we put up a test net work and invite maintainers at https://github.com/tendermint/tendermint to run nodes, so that we can all try and solve the problem.

So I am cutting a testnet from the current code after only a brief review.

the goal is to enable the sdk to ship with tm 35, and to fix the bug in tm 35.

{
"@type": "/cosmos.vesting.v1beta1.PermanentLockedAccount”,
"base_vesting_account": {
"base_account": {
"address": “craft1304875kjndsfavnsioduv”,
"pub_key": null,
"account_number": "0",
"sequence": "0"
},
"original_vesting": [
{
"denom": “exp”,
"amount": "42669329758"
},
“end_time”: “0”,
],
"delegated_free": [],
"delegated_vesting": [],
}

https://github.com/cosmos/cosmos-sdk/blob/428ae3c15c1729197291e2a3fe77013f255cefb5/x/auth/types/auth.pb.go#L31

https://github.com/notional-labs/craft/blob/master/cmd/craftd/cmd/genaccounts.go

we can either have an add-genesis-account that has a --permanent-vesting-account flag (just create the flag) and ensure that it doesn't check the keyring for the key in question -- or we generate json similar to or the same as the json above.

https://github.com/notional-labs/craft/runs/4946257997?check_suite_focus=true#step:4:180

Just as users enter via a queue, they also exit via a queue. Exit is triggered by the exit tx, which may well live in a module called exit.

Exp holders can exit at any time.

exits are batched to ensure impartiality.

There is one exit in every

- sdk 46 rc2 w/ tm 34 https://github.com/notional-labs/craft/tree/real-46 branch

• Fix EXP #133

Next Steps:
- oNFT & Marketplace -> v46 & used (I do for nft real estate & skins)

• Going to use the NFT marketplace & CW721 as I have converted it to use BankMSG from CW20 message

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?

migrate err: config.info: key not foundmigrate err: data.info: key not foundmigrate err: keyhash.info: key not foundEnter keyring passphrase:
Error: read /root/.craftd/config: is a directory

Stargaze and Osmosis have used x/claims to allow for airdrops to be claimed in stages.

Tom can you lay out what the stages should look like?

https://youtu.be/tDxKhiJfgYk

So they…. Built a computer.

And soundtrack
And video

Spent time (work) on each piece of it

I can’t imagine a world where this doesn’t have some kind of value or one where a curation mechanism cannot enhance the value of these objects.

Problem

Consensus Failure since upgrade w/ test_node.sh

• https://gist.github.com/Reecepbcups/93a06f1d28b92e8fccad94a52ce5ec22
• Craftd Version Ubuntu laptop go1.17.6
• Craftd version arch server go1.18

Tested OSs

Ubuntu 18.04 bionic | x86_64 Linux 5.0.0-36-generic | Dell XPS Laptop
Arch Linux | x86_64 Linux 5.16.15-arch1-1 | Hetzner Server

Steps

I was running on last commit before today (git reset --hard 6509b94ae60b9925703220422ba1636e1e2591e5) & had an open RPC & rest server up on the machine.

I upgraded to latest (git pull git checkout v0.4.0) then go install ./.... When I ran ./test_node.sh again, I got the following
https://gist.github.com/Reecepbcups/93a06f1d28b92e8fccad94a52ce5ec22 (line 65)

I have since deleted ~/go/bin ~/go/pkg to try and revert back to the previous working version, but to no luck.

(For the craft wallet to pay another wallet. The "Faucet" from DAO -> players)

I tried doing a keyring-backend=test but had issues...
May have been due to peer issues & long blocktimes. Will re-test again soon

Then this will also be used for any ORM data we need to save

And possibly for NFTs? Hmm

Finish adapting cw to sdk46

Majority unbonded at block height 1001 (looks like 75% of the set)

https://gist.github.com/Reecepbcups/f57bd5fc9257b2d9a239601c4f7dca7d

4:11EST - March 24th US time:
active val: 12
jailed val: 30

by 5:18am, only Chandra Station was active

Problem:

We need a way for someone to make a Proposal, which when passed allows for the wallet to swap an IBC asset for our minted EXP.

• This EXP is not transferable to other accounts, but only minted and burned via some Transactions we define.
• This EXPs value is derived from its (Net Asset Value / Total EXP Outstanding). [So if the account holds 1000UST, and 500EXP are in supply, the mint rate is 2UST->1EXP {1000UST/500 = 2}]
• In the future we want to allow other assets such as ATOM, OSMO, etc. to be used if possible

Toms Document:

https://github.com/notional-labs/craft/blob/master/boring.pdf

FLOW CHART

https://www.canva.com/design/DAE6agPTlL4/CW5CTBuBsVGAvsQCoYcF4w/view?utm_content=DAE6agPTlL4&utm_campaign=designshare&utm_medium=link&utm_source=publishsharelink

Modified Requirements:

struct RequestExpMint: 
- string walletToBeWhitelisted      
- int    maxMintableExp              (max number of exp they can mint, regardless of price)
- string closeMintDate               (After pass, ISO 8601 format for when they can no longer mint EXP from this proposal)
- string vestingPeriodEnd            (mint tokens to account with "forever vesting"-- using cosmos sdk messages (gov v1beta2), then when this period ends the user can BURN their EXP to get UST/IBC assets back after 28 day burn period)

Python Rough Example: https://gist.github.com/Reecepbcups/4bdc9c5df2f4c366b47a7be1ebb5e378.
(Just Assume held_assets in the DAO are IBC enabled and could be held in a module wallet / sub account with authz or something)

Example:

craft11111 creates a Text Proposal with the following values

"title": "Requesting EXP to contribute to the CRAFT DAO",
"description": "what I can contribute here, why I should be accepted plz"
"walletToBeWhitelisted": "craft10r39fueph9fq7a6lgswu4zdsg8t3gxlqd6lnf0", 
"maxExpMint": 10000,
"closeMintDate": "2022-08-15T12:00:00Z",
"vestingPeriodEnd": "2030-01-01T00:00:00Z",

Title and Description just give the voters information on why they should vote yet to allow them into the DAO
walletToBeWhitelisted: is a CRAFT wallet which will be given the EXP asset in echange for UST / IBC assets
maxExpMint: is the max amount of EXP token a user can mint (ex. 1UST -> 1EXP)
closeMintDate: deadline for when they can no longer mint new EXP

IF the dao votes on this and it passes (PROPOSAL_STATUS_PASSED), their address craft11111 is now whitelisted So they can now mintExp via some Tx we create

They now can mint 100EXP for 100UST assuming EXP is $1 per coin.

• These EXP are locked in their account & can not be sent to another address. They can only be Staked,Vote, & Burned (reverse swap, future feature)

if "closeMintDate" passes, craft11111 can no longer mint EXP bc the date passed
if user has minted "maxExpMint", they can no longer mint any more bc that was their limit

Faucet

• For in game rewards, we need a way to send tokens from chain -> a wallet.

This will be firewalled so only the DAO's servers (minecraft & webapp) can make request.

• Provided a server is compromised, the wallet/moduleAccount holding the tokens can only hold/mint a select amount daily, thereby reducing the impact on the chain

Example:

• User A completes an in game task. When they do this, we make a request to the blockchain asking for 5craft tokens. like:
  https://faucet-craft.notional.ventures:4500/craft10r39fueph9fq7a6lgswu4zdsg8t3gxlqd6lnf0/5craft
  OR
  pass through JSON to 4500 port
  { "address": "craft10r39fueph9fq7a6lgswu4zdsg8t3gxlqd6lnf0", "coins": [ "5craft" ]}";

    NOTE: This endpoint https://faucet-craft.notional.ventures:4500 we would whitelist with iptables on the machine so ONLY our servers can access this port.
    The faucet account would have a limited amount of coins on it, so any breach would be limited if our webapp / minecraft servers were taken over.
  

Integration Code which did this on a x.45 chain:

https://github.com/notional-labs/craft/blob/master/minecraft-integration/craft-integration/src/main/java/com/crafteconomy/blockchain/core/request/BlockchainRequest.java#L73

don’t require memo of time, but ensure Tx is AFTER time generated on the server epoch
This way double sign can't happen, minor logic change

change config to have a TAX server account & the ESCROW account (API) depending on where payments are routed

Following the command provided is the HowTo, I cannot create a key with a Ledger :

go install ./...
[...]
~/go/bin/craftd keys add craft_testnet --ledger
Error: failed to generate ledger key: failed to retrieve device: ledger nano S: support for ledger devices is not available in this executable

Issue
Currently the only way for me to generate a transaction in game is with
craftd tx bank send <FROM> <TO> <AMOUNT>token --chain-id craft --generate-only

While this can work, it is a crutch being the only request not done with the Blockchain API/Tendermint.
(Currently has to run the binary with java runtime, then parse JSON correctly to save to Redis
Overall keeping everything in 1 place will make things more efficient / easier to implement equally.

Proposal
Implement Query on :1317 or :26657 to return a generated JSON transaction.

Example
http://localhost:26657/gen_tx?from=craft1234...&to=craft5678...&amount=5&memo="Some Desc Here"

Returns
{"body":{"messages":[{"@type":"/cosmos.bank.v1beta1.MsgSend","from_address":"craft1234","to_address":"craft5678","amount":[{"denom":"token","amount":"5"}]}],"memo":"Some Desc Here","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""}},"signatures":[]}

Then memo can be used in the webapp & in game to describe transactions

Change #1 - will just hardcode transaction within Integration plugin rather than need to use an endpoint

No longer needed, done in game:
When generating a Tx, is it possible to also have a TxUUID?
If so, returning a unique transaction hash with it would allow for me to save that as Map<TxID, Map<PlayerID, MetaData>> in game while waiting for it to be signed. Then I can iterate redis keys, check signed TxID’s, and run the MetaData for the UUID
I assume not but worth knowing just incase it is

Tested on

Arch Linux - x86_64 Linux 5.16.15-arch1-1
go version go1.18 linux/amd64 (installed with notional.giit standup.bash script)

Ubuntu 20.04 focal - x86_64 Linux 5.13.0-40-generic
go version go1.17.8 linux/amd64

tag: v0.3.0-alpha (latest commit)

Arch Server Steps / Environment

git clone https://github.com/notional-labs/craft.git
cd craft
go install ./...

[root@CraftExpValidator ~]# craftd version --long
build_deps:
- cloud.google.com/[email protected]
- cloud.google.com/go/[email protected]
- cloud.google.com/go/[email protected]
- cloud.google.com/go/[email protected]
- filippo.io/[email protected]
- github.com/99designs/[email protected] => github.com/cosmos/[email protected]
- github.com/CosmWasm/[email protected] => github.com/notional-labs/[email protected]
- github.com/CosmWasm/[email protected]
- github.com/Workiva/[email protected]
- github.com/armon/[email protected]
- github.com/aws/[email protected]
- github.com/beorn7/[email protected]
- github.com/bgentry/[email protected]
- github.com/bgentry/[email protected]
- github.com/btcsuite/[email protected]
- github.com/cenkalti/backoff/[email protected]
- github.com/cespare/xxhash/[email protected]
- github.com/cockroachdb/apd/[email protected]
- github.com/coinbase/[email protected]
- github.com/confio/ics23/[email protected]
- github.com/cosmos/[email protected]
- github.com/cosmos/[email protected]
- github.com/cosmos/[email protected]
- github.com/cosmos/cosmos-sdk/[email protected]
- github.com/cosmos/cosmos-sdk/[email protected]
- github.com/cosmos/[email protected]
- github.com/cosmos/[email protected]
- github.com/cosmos/ibc-go/[email protected] => github.com/notional-labs/ibc-go/[email protected]
- github.com/creachadair/[email protected]
- github.com/davecgh/[email protected]
- github.com/desertbit/[email protected]
- github.com/dvsekhvalnov/[email protected]
- github.com/felixge/[email protected]
- github.com/fsnotify/[email protected]
- github.com/go-kit/[email protected]
- github.com/godbus/[email protected]
- github.com/gogo/[email protected]
- github.com/gogo/[email protected] => github.com/regen-network/[email protected]
- github.com/golang/[email protected]
- github.com/golang/[email protected]
- github.com/golang/[email protected]
- github.com/google/[email protected]
- github.com/google/[email protected]
- github.com/google/[email protected]
- github.com/google/[email protected]
- github.com/googleapis/gax-go/[email protected]
- github.com/gorilla/[email protected]
- github.com/gorilla/[email protected]
- github.com/gorilla/[email protected]
- github.com/grpc-ecosystem/[email protected]
- github.com/grpc-ecosystem/[email protected]
- github.com/grpc-ecosystem/[email protected]
- github.com/gsterjov/[email protected]
- github.com/hashicorp/[email protected]
- github.com/hashicorp/[email protected]
- github.com/hashicorp/[email protected]
- github.com/hashicorp/[email protected]
- github.com/hashicorp/[email protected]
- github.com/hashicorp/[email protected]
- github.com/hashicorp/[email protected]
- github.com/hdevalence/[email protected]
- github.com/improbable-eng/[email protected]
- github.com/jmespath/[email protected]
- github.com/klauspost/[email protected]
- github.com/lib/[email protected]
- github.com/libp2p/[email protected]
- github.com/magiconair/[email protected]
- github.com/mattn/[email protected]
- github.com/matttproud/[email protected]
- github.com/minio/[email protected]
- github.com/mitchellh/[email protected]
- github.com/mitchellh/[email protected]
- github.com/mitchellh/[email protected]
- github.com/mtibben/[email protected]
- github.com/oasisprotocol/[email protected]
- github.com/pelletier/[email protected]
- github.com/pkg/[email protected]
- github.com/pmezard/[email protected]
- github.com/prometheus/[email protected]
- github.com/prometheus/[email protected]
- github.com/prometheus/[email protected]
- github.com/prometheus/[email protected]
- github.com/rakyll/[email protected]
- github.com/rcrowley/[email protected]
- github.com/regen-network/[email protected]
- github.com/rs/[email protected]
- github.com/rs/[email protected]
- github.com/spf13/[email protected]
- github.com/spf13/[email protected]
- github.com/spf13/[email protected]
- github.com/spf13/[email protected]
- github.com/spf13/[email protected]
- github.com/spf13/[email protected]
- github.com/stretchr/[email protected]
- github.com/subosito/[email protected]
- github.com/syndtr/[email protected]
- github.com/tendermint/[email protected]
- github.com/tendermint/[email protected]
- github.com/tendermint/[email protected]
- github.com/tendermint/[email protected]
- github.com/tendermint/[email protected]
- github.com/ulikunitz/[email protected]
- [email protected]
- golang.org/x/[email protected]
- golang.org/x/[email protected]
- golang.org/x/[email protected]
- golang.org/x/[email protected]
- golang.org/x/[email protected]
- golang.org/x/[email protected]
- golang.org/x/[email protected]
- golang.org/x/[email protected]
- google.golang.org/[email protected]
- google.golang.org/[email protected]
- google.golang.org/[email protected]
- google.golang.org/[email protected]
- gopkg.in/[email protected]
- gopkg.in/[email protected]
- gopkg.in/[email protected]
- nhooyr.io/[email protected]
- sigs.k8s.io/[email protected]
build_tags: ""
commit: ""
cosmos_sdk_version: v0.46.0-beta2.0.20220418184507-c53157dd63f6
go: go version go1.18 linux/amd64
name: ""
server_name: <appd>
version: ""

craftd testnet start --chain-id craft-aaa --v 4
craftd keys add test --recover (then copy pasted MNEMONIC)

craftd q exp white_list --chain-id craft-aaa --node http://65.108.125.182:26657
Error: rpc error: code = Unknown desc = unknown query path: unknown request

craftd tx exp spend 100node0token --from test --chain-id craft-aaa --node http://65.108.125.182:26657
code: 2
unable to resolve type URL /craft.exp.v1beta1.MsgSpendIbcAssetToExp: tx parse error

When I try to query the failed hash, it errors out.
craftd q tx --type=hash AB327D4BDCF8FA0E3C253251F6F27B608776EC97B6AED96D3713EFA8EEDCEF6A --chain-id craft-aaa --node http://65.108.125.182:26657
Error: RPC error -32603 - Internal error: tx (AB327D4BDCF8FA0E3C253251F6F27B608776EC97B6AED96D3713EFA8EEDCEF6A) not found, err: %!w()

We will need to contribute upstream to ibc-go to remove the legacytx lib from it

https://gist.github.com/Reecepbcups/cc77dd8ba6815811fc22c77024771076

Need guides on flow of commands, was not able to mint EXP in my test environment (go command cli panics, chain still operational)

proposal

when making the proposal, user needs to specify a vesting period for the EXP.
They can stake during this time, but can not burn it to the other asset until that time passes

craft tx exp burnexp [dao_member_address]

• This message burns the entire users EXP, when it should allow for a user to burn partial of their EXP.

Like so:
craft tx exp burnexp [dao_member_address] [exp_to_burn_amount]

What is the difference between "tx exp spend [coins]" & "tx exp fund [coins]" as 2 separate commands?

• It seems spend [coins] should be the only command, and should do the "fund [coins]" logic all in 1 right?

craftd tx exp adjust [price]

• So pricing is required to be done manually? What about a smart contract which queries the balances of DAO wallets, and returns the value in USD (coingeko, LP pools in osmo or something). Not sure how Luna did it, not my specialty yet

craft tx exp send [amount]

"send [amount] from module escrow to the DAO address" so the DAO has some EXP in a module account it uses for sending?

https://github.com/Reecepbcups/airdrop-tools

Get a Juno / AKT / Cosmos export @ any block height & test the tooling works with it as well as the osmo one

write tool to iterate through all lines & parse data correctly

Relook at #17 @ merge logic over into it

Then merge into scripts/airdrop

x86_64 Linux 5.16.15-arch1-1
Disk: 16G / 492G (4%)
CPU ~0.3% on craftd

Have had this issue with other versions of sdk as well, may be a v46-alpha3.0 bug since we are not running beta-1

craftd start --mode=validator

craftd tx bank send reece craft1wge927s299f5ecc940nyf3jqpdx3e6vvn0tw0z 1000ucraft
# <Waits 30 seconds>

craftd q tx --type=hash 1387EE12095023DD058AB806FAC05F6FB2E7B25948BA04C2DC72404C5F6119BD
# Error: RPC error -32603 - Internal error: tx (1387EE12095023DD058AB806FAC05F6FB2E7B25948BA04C2DC72404C5F6119BD) not found, err: %!w(<nil>)

# restart validator
craftd start --mode=validator

# <waits 30-60 seconds>

craftd q tx --type=hash 1387EE12095023DD058AB806FAC05F6FB2E7B25948BA04C2DC72404C5F6119BD
# correct /cosmos.bank.v1beta1.MsgSend query output as expected

Please use this issue to document the intended airdrop design as carefully as possible.

It is likely to be the largest blocker to genesis.

Now, craft doesn't have a makefile. We should create a makefile for easier run/ test node.