Dig v2 is mainly a cleanup and scope reduction release.

1. epochs did not work, let's take e'm out
2. we really do need minimum commission fees. Notional was built on Notional's osmo commission fees and that's something that we want to see happen for Dig's validators.
3. Cosmos-SDK v0.45.0

Dig community/team:

How many other state-breaking changes can we pack into v0.45.0?

:)

-J

1. learn from Osmosis proto-gen: https://github.com/osmosis-labs/osmosis/blob/main/Makefile#L180
2. refactor https://github.com/notional-labs/dig/blob/master/Makefile

• update module path (github.com/notional-labs/dig/v3)
  • #173
• finish unlocks and locks
• If removing a module (ica controller for example) set it to nil in the store
• upgrade cosmos-sdk dependency to v0.45.4

@vuongnguyen17 if you can think of anything else please do add it to this issue :)

currently, we have mono url on our site https://dig-wallet.vercel.app/ which is terrible for memory management and is prone to crash.

the goal is to split mono url into many url.

the problem is that, each url is independant of other urls. Therefore, data will not persist from url A to url B, which is suck.

because our site has to be all front - end. The solution would be to use browser local storage. (reference https://github.com/ping-pub/explorer on how to use local storage)

Is it possible to validate with Akash?
If so could a guide be provided?

merge branch "wallet-vuong-temp" to branch "web-dig-wallet"

DO NOT MERGE DIRECTLY BECAUSE THERE ARE MERGE CONFLICTS

create another branch (Ex: fix-merge-wallet-vuong-temp-to-web-dig-wallet)

and create a pr request to "web-dig-wallet" branch

until no more merge conflict, then merge.

Maybe?

Before we launch the second testnet, we should update the scaffold with Starport 0.17.1. It should merge fairly cleanly in with the work to add the NFT module.

genesis should be ionized in an opinionated manner.

10:59PM ERR CONSENSUS FAILURE!!! err="+2/3 committed an invalid block: wrong Block.Header.AppHash. Expected BD6F680E4EC85B7433B40BE64D10ECDECF75165A42C820735F78197ADCE00A09, got 84F934020D77CA68EF49ADC994A9B283DA9E07113E25FDBF6D5C04EA1EEDA15D" module=consensus stack="goroutine 308 [running]:\nruntime/debug.Stack(0xc0005f0d30, 0x1b0db40, 0xc0012e0020)\n\t/usr/lib/go/src/runtime/debug/stack.go:24 +0x9f\ngithub.com/tendermint/tendermint/consensus.(*State).receiveRoutine.func2(0xc000233500, 0x205b5e8)\n\t/root/go/pkg/mod/github.com/tendermint/[email protected]/consensus/state.go:726 +0x5b\npanic(0x1b0db40, 0xc0012e0020)\n\t/usr/lib/go/src/runtime/panic.go:965 +0x1b9\ngithub.com/tendermint/tendermint/consensus.(*State).finalizeCommit(0xc000233500, 0x2)\n\t/root/go/pkg/mod/github.com/tendermint/[email protected]/consensus/state.go:1575 +0x1385\ngithub.com/tendermint/tendermint/consensus.(*State).tryFinalizeCommit(0xc000233500, 0x2)\n\t/root/go/pkg/mod/github.com/tendermint/[email protected]/consensus/state.go:1546 +0x428\ngithub.com/tendermint/tendermint/consensus.(*State).addProposalBlockPart(0xc000233500, 0xc00062bf50, 0xc000524270, 0x28, 0xc001a90600, 0xc001a90900, 0xc03e29872ae51301)\n\t/root/go/pkg/mod/github.com/tendermint/[email protected]/consensus/state.go:1919 +0x7c5\ngithub.com/tendermint/tendermint/consensus.(*State).handleMsg(0xc000233500, 0x223be60, 0xc00062bf50, 0xc000524270, 0x28)\n\t/root/go/pkg/mod/github.com/tendermint/[email protected]/consensus/state.go:820 +0x5cc\ngithub.com/tendermint/tendermint/consensus.(*State).receiveRoutine(0xc000233500, 0x0)\n\t/root/go/pkg/mod/github.com/tendermint/[email protected]/consensus/state.go:762 +0x3f2\ncreated by github.com/tendermint/tendermint/consensus.(*State).OnStart\n\t/root/go/pkg/mod/github.com/tendermint/[email protected]/consensus/state.go:378 +0x8c5\n"

q: is this because of versioning, or is it something deeper?

BUILD_TAGS env var is being ignored, so BUILD_TAGS=muslc does not work.

Minimally, Gaia and Osmosis have this feature.

Basically it inovlves doing an export in CI and. simulating an upgrade from the current chain to the new code.

Juno's uni testnet kinda exploded due to some unknown issues, and so before our gov prop for upgrading, I'd like to simulate an upgrade. THere's an isuse on Osmosis that describes this, if someone could find it and link it here that would be super-duper.

To prevent malinvestment, new chains that link to specific properties will be undertaken only after a spawntx has occured.

The spawntx is very expensive, and results in the community undertaking to launch a new blockchain and create a physical build out.

Dig v2 was a little delayed, but for great reason!

We can now add interchain accounts to dig, but in order to do that we will need to fully remove Starport from dig because of the nodule layout.

this could be a faster way than trying to build infrastructure to handle eth - signing

Inspired by Juno

Whole new look to front - end, abandon old one

Airdrops that are not claimed or utilized could represent a large % of the float, and these unclaimed airdrops may severely negatively impact token economics. See Ion, for example, 2/3 of total float exists in inactive wallets.

We should implement a decay mechanic so that active and participating users can claim their airdrops, and after a period of time, the claimable amount decreases to 0.

Proposed claimable airdrop amount by time frame after launch:

Option 1: Short Decay
0-14 days 100%
15-30 days 50%
After 30 days: 0%

Option 2: Longer Decay
0-30 days 100%
30-45 days 50%
After 30 days: 0%

https://github.com/OmniFlix/testnets/blob/main/scripts/generate_genesis.sh

In times of differentiating apphashes recent chain-halts have shown one factor to be crucial:

• to get a chain back on it's feet everybody needs to start from the same state using the same version.

CryptoCrew is proposing to take the following path for relaunching Dig:

Plan alpha

1. a) Roll back state to height 4407835 and hash 9992D8150EEF051E0385F31389CA56A01DA30634DEDC033726262492E311B2B9 by performing:

sudo systemctl stop digd
digd --home ~/.dig rollback

1. b) or restore a snapshot created from height 4407835 - need to preserve and restore priv_validator_state when taking this path!

link: https://quicksync.ccvalidators.com/SNAPSHOTS/dig-1_20221029_default.tar.lz4
md5-sum: 7fb412ee169f7e181ad653602a5ac55e
height: 4407835
size: 137MB

• previously signed rounds of 4407836 must not be signed again - this is why we restore our validator state before starting up the node

2. compile digd v2.6.0 using go 1.19.3 and move binary to correct folder (~/.dig/cosmovisor/upgrades/v2/bin/ for cosmovisor users)

3. start nodes at a coordinated date with enough time to prepare. as soon we reach the latest round and have >2/3 VP agreeing the chain will resume. Tests using digd v2.6.0 on the above provided snapshot have shown good results.

Backup plan

Plan alpha could fail in case of the following situations:

• digd v2.6.0 is unable to produce a deterministic result in block 4407836 due to unforseen reasons
• the chain is able resume but one or more validators are hardslashed because they didn't preserve and restore their validator state and doublesign by accident

In the case plan alpha fails we have two options:

a) if the chain resumes we could revert any possible hardslashes in an upgrade, like secret network and chihuahua did recently

b) last resort would be to use a state-export of block 4407835 to create a new genesis and relauch dig-1 from this state while accepting the archive problem. CryptoCrew have exported that state and are providing it here: https://quicksync.ccvalidators.com/SNAPSHOTS/dig-export-4407835.json

Looking for validators / node runners willing to run some lightly tested code for snapshot restores.

This should help especially if you are not able to prune.

If you need much more instruction than this, we recommend you don't do this on a validator node because it may put you at risk of double signing.

There will be a formal release later.

git clone https://github.com/chillyvee/dig 
cd dig
git checkout cv331_snapshot
go mod edit -replace github.com/cosmos/cosmos-sdk=github.com/chillyvee/[email protected]
go mod edit -replace github.com/cosmos/iavl=github.com/chillyvee/[email protected]
go mod tidy
make install

Make the following edits to your config.toml

[statesync]
  chunk_fetchers = "4"
  chunk_request_timeout = "10s"
  discovery_time = "15s"
  enable = true
  rpc_servers = "https://rpc-1-dig.notional.ventures:443,https://rpc-1-dig.notional.ventures:443"
  temp_dir = ""
  trust_hash = "fc25ffbbd03fac9c7a32f3c9a1fde171771786ea36999144565cc6ef41834de8"
  trust_height = "4409000"
  trust_period = "168h0m0s"

Dig need a testnet. Very need to update to dig-v2. Can you make it ?
@mgialong215, @MasterPi-2124, @lichdu29 .

There are so many different versions of keplr which use different endpoints.

This causes great disturbance in the force for users.

some import dig to keplr which uses:

1. 123.456.789:2203
2. digapi.chillvalidator...
3. bla bla bla

We must unify all different keplr into one single version

The only website authorized for people to add dig to their keplr is: https://dig-wallet.vercel.app/

The only endpoints:

1. api-1-dig.notional.ventures
2. rpc-1-dig.notional.ventures

• add feature: "add dig wallet" to branch web-dig-wallet which uses endpoints as above
• deploy new "https://dig-wallet.vercel.app/"
• announce the change to the whole community. That all other versions are not quality assured by Notional.

GODL token

Prepared for: Notional Labs
Prepared by: William Gray, Marketing Director
3 May 2022

Proposal abstract:

A gold-backed stablecoin in Cosmos, on a CW20 token on Dig Chain. An ICO will be conducted in Cosmos to raise money for the gold-backed token, which will then be spent on Gold, with a small percentage going to Notional for building the token. Successive funding rounds can later be completed in short periods (to protect against volatility in the gold market) to raise more funds to buy more gold. Gold will be stored with a licensed and insured vault. The name GODL is a play on the term HODL.

GODL price will be pegged to one ounce of gold (spot price at time of writing = $1,858) .

PROJECT SUMMARY

Objective
To create a gold-backed stablecoin in Cosmos that people can use as a hedge against market volatility. The token will be the only one of its kind in Cosmos and will thus likely gather attention and demand quickly.

Goals

• To test the market for demand for a gold-backed stablecoin
• To bring more value to the parent Dig Chain (gas fees paid in $DIG)
• To bring more value to Cosmos by providing the option to buy gold with crypto
• To set the stage for further stablecoins backed by silver and other precious metals.

Solution

• Create a CW20 token on Dig Chain
• Use initial liquidity from (Bank/Osmosis)
• List initial token on Osmosis to gather attention
• Launch an ICO to raise funds to buy more gold
• Use the proceeds to buy gold (stored in vault, secure, insured)
• Perform successive funding rounds in future to increase supply

Project Outline

• The supply will only ever equal the amount of gold purchased so it is backed pound-to-pound. GODL token will require $DIG as gas to work.
• Secure parter to provide initial liquidity (to prove concept + gain exposure)
• Create CW20 token and list on Osmosis DEX, et al.
• Raise funds in gold funding round
• Use funds to purchase gold from supplier (already have supplier)
• Issue tokens to wallets
• Perform successive funding rounds
• Expand to silver stablecoin

Project Sustainability

Gold sold during ICO phase will be priced slightly above market value. This is normal practice when buying gold at retail (supplier buys at market rate and sells at small increase to make a profit). The small increase will pay for Notional's development on the project.

This project is one of several that can be launched on Dig Chain to increase its use-case and thus increase the $DIG token value. This will benefit Notional in the long run.

Details:

Details

• Supplier can be paid in US-backed stablecoin
• No VAT on gold bullion
• Storage: Vault in London - fees are ￡65 (GBP) per month for ￡100,000 worth of gold or over. Stored with Brinks.
• We are able to buy gold at wholesale price: confirmed
• Holders of GODL could redeem the real gold and have it posted to them - they would need to give one GODL token to receive one ounce of gold, two GODL tokens to receive two ounces, and so on. This would be standardized.
• Redeemed gold will come in the form of one ounce gold bullion bars.

--gas 100000 --fees 2500udig yields result of 0udig is smaller than 2500udig: insufficient funds: insufficient funds as an example

I have just briefly tested whether the testnet would run on a Raspberry Pi. But the v2.0.0 alpha says no.

github.com/CosmWasm/wasmvm/api

/usr/bin/ld: skipping incompatible ../go/pkg/mod/github.com/!cosm!wasm/[email protected]/api/libwasmvm.so when searching for -lwasmvm
/usr/bin/ld: cannot find -lwasmvm: No such file or directory
/usr/bin/ld: skipping incompatible ../go/pkg/mod/github.com/!cosm!wasm/[email protected]/api/libwasmvm.so when searching for -lwasmvm
collect2: error: ld returned 1 exit status

I try to upgrade to v2.0.1 of dig-test. After the upgrade, I stop the chain at height X (200) and restart with the new binary and get the following error:

Steps to Take

1. Start an older version of dig
2. Submit an upgrade proposals -> Deposit -> Vote
3. Wait until the height is reached
4. Checkout new version of dig
5. Build a new execute file of dig
6. Stop the current chain and restart with the new binary

After restarting, it returns an error:
failed to load latest version: failed to load store: initial version set to 200, but found earlier version 1

My setup scripts

#!/bin/bash

KEY="test"
CHAINID="dig-testnet"
KEYRING="test"
MONIKER="local-testnet"
KEYALGO="secp256k1"
LOGLEVEL="info"
VALIDATOR="validator"
VESTING="vesting_account"


echo >&1 "installing dig"
rm -rf $HOME/.dig
make install

dig config keyring-backend $KEYRING
dig config chain-id $CHAINID

# determine if user wants to recorver or create new

digd keys add $VALIDATOR --keyring-backend $KEYRING
MY_VALIDATOR_ADDRESS=$(digd keys show $VALIDATOR -a --keyring-backend $KEYRING)

digd keys add $VESTING --keyring-backend $KEYRING
MY_VESTING_ACCOUNT=$(digd keys show $VESTING -a --keyring-backend $KEYRING)

echo >&1 "\n"

# init chain
digd init $MONIKER --chain-id $CHAINID

# Change parameter token denominations to ubaby
cat $HOME/.dig/config/genesis.json | jq '.app_state["staking"]["params"]["bond_denom"]="stake"' > $HOME/.dig/config/tmp_genesis.json && mv $HOME/.dig/config/tmp_genesis.json $HOME/.dig/config/genesis.json
cat $HOME/.dig/config/genesis.json | jq '.app_state["crisis"]["constant_fee"]["denom"]="stake"' > $HOME/.dig/config/tmp_genesis.json && mv $HOME/.dig/config/tmp_genesis.json $HOME/.dig/config/genesis.json
cat $HOME/.dig/config/genesis.json | jq '.app_state["gov"]["deposit_params"]["min_deposit"][0]["denom"]="stake"' > $HOME/.dig/config/tmp_genesis.json && mv $HOME/.dig/config/tmp_genesis.json $HOME/.dig/config/genesis.json
cat $HOME/.dig/config/genesis.json | jq '.app_state["gov"]["deposit_params"]["min_deposit"][0]["amount"]="100000"' > $HOME/.dig/config/tmp_genesis.json && mv $HOME/.dig/config/tmp_genesis.json $HOME/.dig/config/genesis.json
cat $HOME/.dig/config/genesis.json | jq '.app_state["gov"]["deposit_params"]["max_deposit_period"]="200s"' > $HOME/.dig/config/tmp_genesis.json && mv $HOME/.dig/config/tmp_genesis.json $HOME/.dig/config/genesis.json
cat $HOME/.dig/config/genesis.json | jq '.app_state["gov"]["voting_params"]["voting_period"]="250s"' > $HOME/.dig/config/tmp_genesis.json && mv $HOME/.dig/config/tmp_genesis.json $HOME/.dig/config/genesis.json
cat $HOME/.dig/config/genesis.json | jq '.app_state["mint"]["params"]["mint_denom"]="stake"' > $HOME/.dig/config/tmp_genesis.json && mv $HOME/.dig/config/tmp_genesis.json $HOME/.dig/config/genesis.json

# Set gas limit in genesis
# cat $HOME/.dig/config/genesis.json | jq '.consensus_params["block"]["max_gas"]="10000000"' > $HOME/.dig/config/tmp_genesis.json && mv $HOME/.dig/config/tmp_genesis.json $HOME/.dig/config/genesis.json

# Allocate genesis accounts (cosmos formatted addresses)
digd add-genesis-account $VALIDATOR 10000000stake --keyring-backend $KEYRING

# Sign genesis transaction
digd gentx $VALIDATOR 7000000stake --keyring-backend $KEYRING --chain-id $CHAINID

# Collect genesis tx
digd collect-gentxs

# Run this to ensure everything worked and that the genesis file is setup correctly
digd validate-genesis

# Start the node (remove the --pruning=nothing flag if historical queries are not needed)
digd start

My upgrade script

#!/bin/bash

CHAINID="dig-testnet"
KEYRING="test"
VALIDATOR="validator"
VESTING="vesting_account"

shopt -s expand_aliases

MY_VALIDATOR_ADDRESS=$(digd keys show $VALIDATOR -a --keyring-backend $KEYRING)
MY_VESTING_ACCOUNT=$(digd keys show $VESTING -a --keyring-backend $KEYRING)

echo "===> Submitting governance proposal"
digd tx gov submit-proposal software-upgrade "v2" \
  --title "Upgrade Software" \
  --description "test software upgrade proposal" \
  --deposit 100000stake \
  --upgrade-height=200 \
  --from $MY_VALIDATOR_ADDRESS \
  --keyring-backend $KEYRING \
  --chain-id $CHAINID --yes

echo "===> Waiting for transaction to be effective"
sleep 15

echo "===> Voting governance proposal"
digd tx gov vote 1 yes --from $MY_VALIDATOR_ADDRESS --keyring-backend $KEYRING --chain-id $CHAINID --yes

I'm looking for a solution to solve and found this https://github.com/cosmos/cosmos-sdk/issues/8265

After that, I changed something in the source code, retested it and I found that, in this function

if I remove wasm.ModuleName, authz.ModuleName to

then, it can run normally.

The story is that modified keplr for dig has added support for eth address. But, it is not the same for cli.

Objective: "digd keys add temp" must return eth address instead of "dig1981hjrhewkrhqwr".

The library to convert. @romelukaku knows

• extract which library from @romelukaku

Before we launch MainNet we want to be using the latest Cosmos SDK.

• the API server needs to be wired up to check the validity / ownership of addresses
• the processor that queries bsc needs to be built
• airdrop mechanism needs to be licensed
• decision needs to be made weather or not to airdrop on eth, tron, bsc by weight of account

I am trying to setup a node on digv1 as I want to be in the active set, but I am not able too. I have tried changing up the reset point, my keyname, and init moniker to no luck.

Steps to reproduce
git clone https://github.com/notional-labs/dig && cd dig/
git checkout master
git reset --hard a5a3969
go mod tidy
go install ./...

digd keys add joel
digd init carbonator --chain-id dig-1

wget -O ~/.dig/config/genesis.json https://github.com/notional-labs/dig/raw/master/networks/mainnets/dig-1/genesis.json

digd start --p2p.seeds [email protected]:26656,[email protected]:6969 --p2p.persistent_peers [email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656

Error
12:51AM INF Reconnecting to peer addr={"id":"ab2fa2789f481e2856a5d83a2c3028c5b215421d","ip":"144.91.117.49","port":26656} module=p2p
12:51AM INF Dialing peer address={"id":"ab2fa2789f481e2856a5d83a2c3028c5b215421d","ip":"144.91.117.49","port":26656} module=p2p
12:51AM ERR dialing failed (attempts: 1): auth failure: secret conn failed: read tcp 65.108.125.182:43496->185.214.135.205:26656: i/o timeout addr={"id":"e9e89250b40b4512237c77bd04dc76c06a3f8560","ip":"185.214.135.205","port":26656} module=pex
12:51AM ERR dialing failed (attempts: 1): auth failure: secret conn failed: read tcp 65.108.125.182:38408->185.194.219.128:26656: i/o timeout addr={"id":"eb55b70c9fd8fc0d5530d0662336377668aab3f9","ip":"185.194.219.128","port":26656} module=pex