1559: https://res.cloudinary.com/stargaze/image/upload/w_700/b5ij1wrgjzmzcivljffz.jpg 1980: https://res.cloudinary.com/stargaze/image/upload/w_700/u5swhukgqofrwrqj7vyp.jpg 2979: https://res.cloudinary.com/stargaze/image/upload/w_700/ouw1ndsrjjbhe0btkn6u.jpg 3105: https://res.cloudinary.com/stargaze/image/upload/w_700/ay895kdyocd5ublmlukw.jpg 3797: https://res.cloudinary.com/stargaze/image/upload/w_700/ucjpnj0fh1segz3fuwqf.jpg 3799: https://res.cloudinary.com/stargaze/image/upload/w_700/plbs1zrqrdmizjpo8mnb.jpg 8842: https://res.cloudinary.com/stargaze/image/upload/w_700/badkx397up5ww8epsldm.jpg 8961: https://res.cloudinary.com/stargaze/image/upload/w_700/snav2rleap7jhvzm8pyo.jpg 9045: https://res.cloudinary.com/stargaze/image/upload/w_700/w91bnc1hjm6yfjdvpngz.jpg 8602: https://res.cloudinary.com/stargaze/image/upload/w_700/are9u3qwmgvf78mzwawf.jpg

Begin by writing out the proposal description in markdown. Confirm that it's under the charlimit (5k until Theta and 10k after). Then generate the proposal with --offline so that it is not signed but the json is created. Pipe it into a file like unsigned.json. You can leave the description empty or with dummy text here because the CLI will try to escape the chars but likely not the way you want. > gaiad tx gov submit-proposal software-upgrade v7-Theta \ --title v7-Theta \ --deposit 50000uatom \ --upgrade-height 10085397 \ --upgrade-info '{"binaries":{"linux/amd64":"https://github.com/cosmos/gaia/releases/download/v7.0.0/gaiad-v7.0.0-linux-amd64?checksum=sha256:dc0e5b6690a55f0f1c41ad96f068049e25d9e85d53c0587284b7f1a1f9a51545","linux/arm64":"https://github.com/cosmos/gaia/releases/download/v7.0.0/gaiad-v7.0.0-linux-arm64?checksum=sha256:994f67ec8134504ae032a1ae58caf769b5a9a1581a38705efd94ab654a7f6173","darwin/amd64":"https://github.com/cosmos/gaia/releases/download/v7.0.0/gaiad-v7.0.0-darwin-amd64?checksum=sha256:2b7425b27e1c04877f0e9230f1657bee1b3274b73bee8f550a290cc505444dbf","windows/amd64":"https://github.com/cosmos/gaia/releases/download/v7.0.0/gaiad-v7.0.0-windows-amd64.exe?checksum=sha256:1362b026e942cc16ab2b7f35a3ff39fb9075dcde70570635485d4b1866e1d036"}}' \ --description "#test\r\n\r##test" \

for vega-upgrade gaiad tx gov submit-proposal software-upgrade Vega \ --title Vega \ --deposit 500000uatom \ --upgrade-height 8695000 \ --upgrade-info '{"binaries":{"linux/amd64":"https://github.com/cosmos/gaia/releases/download/v6.0.0/gaiad-v6.0.0-linux-amd64?checksum=sha256:d9b4391065a338107ca240f29539d62572fe1e85a6c455576afc5e93dba7f402","linux/arm64":"https://github.com/cosmos/gaia/releases/download/v6.0.0/gaiad-v6.0.0-linux-arm64?checksum=sha256:e348259fb9ca5d516a8754ea1f15255ef32e7656e79d52a87616edb16f0a7343","darwin/amd64":"https://github.com/cosmos/gaia/releases/download/v6.0.0/gaiad-v6.0.0-darwin-amd64?checksum=sha256:e0de182c098ab68d3ef4bab8a3d12aca100b9f1d18d873d66e82ec2c187a1735","windows/amd64":"https://github.com/cosmos/gaia/releases/download/v6.0.0/gaiad-v6.0.0-windows-amd64.exe?checksum=sha256:713cb6c1a7ef555d5ed64f036f65b039b44b76f314855e2f7d2a5330568e6100"}}' \ --description "This on-chain upgrade governance proposal is to adopt gaia v6.0.0 which includes a number of updates, fixes and new modules. By voting YES to this proposal, you approve of adding these updates to the Cosmos Hub.\n\n### Background\n\nSince the last upgrade at height 6910000 there have been a number of updates, fixes and new modules added to the Cosmos SDK, IBC and Tendermint. The following updates are included in gaia v6.0.0:\n * Bump [Cosmos-SDK](https://github.com/cosmos/cosmos-sdk) to [v0.44.3](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.44.3) which notably includes fixes for the vesting accounts and two new modules outlined below. For a full list of updates in Cosmos-SDK v0.44.3 please see the [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/release/v0.44.x/CHANGELOG.md#v0443---2021-10-21)\n * Add the [authz](https://github.com/cosmos/cosmos-sdk/tree/v0.44.3/x/authz/spec) module to the Cosmos Hub. `x/authz` is an implementation of a Cosmos SDK module, per [ADR 30](https://github.com/cosmos/cosmos-sdk/blob/v0.44.3/docs/architecture/adr-030-authz-module.md), that allows granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations must be granted for a particular Msg service method one by one using an implementation of the `Authorization` interface.\n * Add the [feegrant](https://github.com/cosmos/cosmos-sdk/tree/v0.44.3/x/feegrant/spec) module to the Cosmos Hub. This module allows accounts to grant fee allowances and to use fees from their accounts. Grantees can execute any transaction without the need to maintain sufficient fees.\n * **NOTICE** It's imortant to highlight [PR #10041](https://github.com/cosmos/cosmos-sdk/pull/10041) which impacts **WALLETS AND EXCHANGES**. This update has removed the deprecated the legacy REST endpoints for broadcast & encode. **This means `POST /tx` and `POST /txs/encode` no longer work**. Please see the [REST Endpoints Migration guide](https://docs.cosmos.network/master/migrations/rest.html) to migrate to the new REST endpoints.\n * Add [IBC](https://github.com/cosmos/ibc-go) as a standalone module from the Cosmos SDK using version [v2.0.0](https://github.com/cosmos/ibc-go/releases/tag/v2.0.0). See the [CHANGELOG.md](https://github.com/cosmos/ibc-go/blob/v2.0.0/CHANGELOG.md) for details.\n * Please note that the governance parameter for `MaxExpectedBlockDelay` is set to 30 seconds. This means if a connection is opened with a packet delay of 1 minute, it requires 2 blocks to be committed after the consensus state is submitted before the packet can be processed.\n * Add [packet-forward-middleware](https://github.com/strangelove-ventures/packet-forward-middleware) [v1.0.1](https://github.com/strangelove-ventures/packet-forward-middleware/releases/tag/v1.0.1) as per [Proposal #56](https://www.mintscan.io/cosmos/proposals/56) prepared and tested by [Strangelove Ventures](https://www.strangelove.ventures/). This feature allows multi-hop IBC transfer messages so that a user can send tokens from chain A to chain C via chain B.\n * Bump [Liquidity](https://github.com/gravity-devs/liquidity) module to [v1.4.2](https://github.com/Gravity-Devs/liquidity/releases/tag/v1.4.2) to ensure compatibility with Cosmos-SDK.\n\n### Ready for Production\n\nThese changes have been extensively tested by various Cosmos Core Contributor teams including [Hypha Co-Op](https://hypha.coop/), [Informal Systems Co-Op](https://informal.systems/), [Interchain GmbH](https://interchain.berlin/), [Regen Network](https://regen.network/), [Strangelove Ventures](https://strangelove.ventures/), [Tendermint Inc](https://tendermint.com/) and more. The release candidate for this update was run as a local testnet and a public testnet with a successful upgrade; documentation can be found [here](https://github.com/cosmos/vega-test).\n\n### On-Chain Upgrade Process\n\nWhen the network reaches the halt height, the state machine program of the Cosmos Hub will be halted. The classic method for upgrading requires all validators and node operators to manually substitute the existing state machine binary with the new binary. There is also a newer method that relies on [Cosmovisor](https://github.com/cosmos/cosmos-sdk/tree/master/cosmovisor) to swap the binaries automatically. Cosmovisor also includes the ability to download the binaries automatically before swapping them. Instructions specific to the upgrade can be found [here](https://github.com/cosmos/gaia/blob/main/docs/gaia-tutorials/upgrade-node.md). To test a simulated local upgrade please see the [local testnet documentation](https://github.com/cosmos/vega-test/blob/master/local-testnet/README.md). Because it is an onchain upgrade process, the blockchain will be continued with all the accumulated history with continuous block height.\n" \ --fees 300uatom \ --gas auto \ --from deploy \

This is the script that needs to be run on both servers, except the chain id needs to be changed on the second server Introduction Alice is on chain test-1 and has 100 tokens bob is on chain test-2 does not have any token. alice knows an faucet user on chain test-2, so she can sometimes ask faucet user to send her some tokens. now, alice wants to send some native token of chain test-2 to bob.

Task 1 # configure gaiad so that there is relevant chain info in two different directories: gaiad config chain-id test-1 gaiad config node http://165.22.23.73:26657 gaiad config keyring-backend test gaiad config chain-id test-2 --home ~/.gaiad2 gaiad config node http://164.90.226.126:26657 --home ~/.gaiad2

This challenge is to demonstrate understanding of and ability to use the new Interchain Accounts IBC module and the Cosmos Hub specific Interchain Account Auth module (mauth) as well as a general understanding for running cosmos-sdk validators nodes, relayers and IBC. To begin, we created 3 digital ocean nodes. Node 1 - gaia test-1 (165.22.23.73) This is a gaia blockchain using chain id test-1 with the ica ibc module, as well as our new mauth module which allows arbitrary messages to be executed by a private key controlled account. On this blockchain we pre-populated 3 accounts with stake token. demowallet (used as a faucet) val (used as a validator) rly (used by a relayer)

This on-chain upgrade governance proposal is to adopt gaia v6.0.0 which includes a number of updates, fixes and new modules. By voting YES to this proposal, you approve of adding these updates to the Cosmos Hub. Background Since the last upgrade at height 6910000 there have been a number of updates, fixes and new modules added to the Cosmos SDK, IBC and Tendermint. The following updates are included in gaia v6.0.0: Bump Cosmos-SDK to v0.44.3 which notably includes fixes for the vesting accounts and two new modules outlined below. For a full list of updates in Cosmos-SDK v0.44.3 please see the CHANGELOG.md Add the authz module to the Cosmos Hub. x/authz is an implementation of a Cosmos SDK module, per ADR 30, that allows granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations must be granted for a particular Msg service method one by one using an implementation of the Authorization interface. Add the feegrant module to the Cosmos Hub. This module allows accounts to grant fee allowances and to use fees from their accounts. Grantees can execute any transaction without the need to maintain sufficient fees. NOTICE It's imortant to highlight PR #10041 which impacts WALLETS AND EXCHANGES. This update has removed the deprecated the legacy REST endpoints for broadcast & encode. This means POST /tx and POST /txs/encode no longer work. Please see the REST Endpoints Migration guide to migrate to the new REST endpoints.

record of proposals Gm proposal #24: In addition to the rewards specified in proposal #8, score snapshot reports also receive 0.5 points per counted score-changing event. This reward must be included in the snapshot for which the reward is collected. by Judd Passed PASSED Gm proposal #25: After creating a score snapshot, at least ten minutes must pass before this player is eligible to claim another score snapshot reward. by Judd Passed

Starting from early recorded state: gm, Judd: 19 Charlie: 17 Billy: 11 Validatus: 5 Ismail: 4 Ankit: 5 Brian: 3

Get the hex representation of the multisig signer addresses of multisig cosmos1unc788q8md2jymsns24eyhua58palg5kc7cstv with 2/3 signers: > gaiad keys parse cosmospub1addwnpepqdffnd5p089hkxq9jt3grlcn79c0a0yeuumuu9nmas0vvtqmxa0fx0j4xg8 human: cosmospub bytes: EB5AE98721035299B68179CB7B180592E281FF13F170FEBC99E737CE167BEC1EC62C1B375E93 > gaiad keys parse cosmospub1addwnpepqwc5kp5my47sppxecut5hs5yk7jmvg3znhfr0tzc32jghme350enxlz7d2k human: cosmospub bytes: EB5AE9872103B14B069B257D0084D9C7174BC284B7A5B622229DD237AC588AA48BEF31A3F333

In order to send vesting ATOM it has to be to a brand new account. If the recipient has ever owned ATOMs in the account, or made any transactions it will not be possible to send them vested ATOMs. They must create a new account EACH time they receive ATOMs. (For full documentation on vesting see the spec here) To create a vesting account first find the date that they should unlock and convert to UNIX time in seconds (not milliseconds). Let's say we want it to vest on Dec 31st at 11:59pm +59 sec, 2022. We can use a service like this one and enter the date and convert to UNIX epoch time (in seconds) to be 1624600453. This is the number we use in our next command. Then create a gaiad command like so: gaiad tx vesting create-vesting-account <cosmosaddress> \ <number>uatom <UNIX-time> \

Working Group Repository Video Meeting Link Telegram Invite Calendar Invite Mission Statement Highlight, discuss and solve the emerging challenges that need to be addressed by application level developers to ensure a high quality user experience when dealing with an IBC connected Internet of Blockchains. This is part User Interface questions (how to display an IBC connected asset? What level of transparency or insight on security should be my responsibility as an interface developer?) as well as developer experience questions (how do I query the balance of a user with mutli-chain assets and display those assets in a clear and friendly manner?). 15th Meeting: Monday JUNE 8th 3:00 - 4:00pm UTC

contract InfectMe { uint contractTokenId; function updateTokenId(uint tokenId) onlyOwner { contractTokenId = tokenId; } function infectMe() { kudzu.transferFrom(address(this), msg.sender, contractTokenId);

Agenda Intros Alix @ Ledger - Stargate integration of Ledger Product Manager for the team What direction and adaptation is needed Ge

NFT Prior Art New Model Patches (solc v0.4.18) NFT + Metadata Tutorial (solc v0.5.0) Clovers Network (solc v0.4.18) Attributes External Metadata contract for updateable URLs

Links Here - https://cutt.ly/scavenge Discord Channel Tutorial Tutorial Github Slides Connect to the live app scavengeCLI config node "tcp://188.166.52.77:26657"

Ethermint has existed in one form or another for quite awhile. The most recent version (v2) has been shepherded by ChainSafe via a grant from the ICF. At it's core it is the Ethereum Virtual Machine built as a Cosmos SDK module. It comes with a REST client that exposes an Ethereum RPC endpoint (defualt localhost:8545) that accepts all normal etheruem interactions. This includes pointing common Etheruem tools like Truffle or Metamask to the endpoint and interacting with it like a normal Ethereum network. The benefit of running Ethermint instead of GoEthereum (GETH) or the Parity Client is that instead of just a Proof-Of-Authority validation (or classic proof of work) Ethermint uses Tendermint consensus. Furthermore, by being present within the Cosmos SDK, it is possible for the other modules to interact directly with Ethermint. For example, hooks can be set in BeginBlock or EndBlock which will be executed on the EVM at the beginning or ending of each block. This would allow things like subscriptions to be executed automatically. It would also allow things like contract deployment to be routed via governance so that not just anyone can deploy code but only those approved by Governance. Peggy has also existed in one form or another for quite some time. In general, Peggy is an oracle layer that allows communication between networks with probabilistic finality like Ethereum. An early version was created by @joon#0284 as part of a hackathon. More recent versions of unidirectional peggy and bidirectional peggy have been created by SwishLabs. Peggy currently supports the transfer of Ether and ERC-20s from an EVM based chain that it is connected to. Currently it works like this: Validators run on the SDK chain like normal. These validators have voting power based on token balances, referred to as weight. This weight gives them authority to validate blocks, but it also give them authority to make claims about the state of Ethereum. If a user locks up Ether or an ERC-20 on Ethereum (or any other EVM based chain that Peggy is made aware of), one or more validators are able to witness this event and make a claim about the event on the SDK chain. Once there is a threshold of validators who have made the same claim with enough weight, the claim is considered valid. A valid claim will result in a corresponding token being minted in the SDK owned by an address designated in the original lock-up transaction. If the claims never reach a threshold, it is considered a failed claim and marked as so. This is the basics of the original unidirectional bridge but peggy also has the feature of moving assets from the SDK chain to the EVM based chain. In this scenario there are either tokens on the SDK chain which originated there, or tokens which were minted there based on validator claims of the tokens being locked up on the EVM chain. I will refer to these as SDK-Native-SDK-Tokens and EVM-Native-SDK-Tokens respectively. When an SDK-Native-SDK-Token is moved to the EVM chain, it is moved to an escrow account on the SDK chain and an event is emitted. The validators will witness this event and make a claim on the EVM chain about such an event. The EVM chain keeps a record of all the SDK validators and their corresponding weights. Similarly to the EVM -> SDK process, a threshold of weight is required before the Claim is considered valid. At that point the EVM contract will mint a new token that represents the SDK-Native-SDK-Token. This new token will be a SDK-Native-EVM-Token.

# Cosmos NFT Module * [Abstract](#Abstract) * [Summary](#Summary) * [Types](#Types) * [BaseNFT](#BaseNFT) * [\*A Note on Metadata](#A-Note-on-Metadata) * [NFT Interface](#NFT-Interface) * [NFTs](#NFTs) * [Collection](#Collection) * [Collections](#Collections) * [Owner](#Owner) * [IDCollections](#IDCollections) * [IDCollection](#IDCollection) * [Msg Types](#Msg-Types) * [MsgTransferNFT](#MsgTransferNFT) * [MsgEditNFTMetadata](#MsgEdit