Intro In this article we'll go over the creation of a multisig wallet, and how to perform some actions with it. Setup We'll create a multisig with 3 members with a 2/3 passing threshold. First create the 3 members, Alice, Bob and Carol: simd keys add alice --keyring-backend test --home ./.testnets/node0/simd/ simd keys add bob --keyring-backend test --home ./.testnets/node0/simd/

In a server v2 world, x/consensus will work as a companion module to the consensus engine of choice. So very likely every consensus module that has a server/plugin for Cosmos SDK will have its own x/consensus. Consensus messages The AppManager's BlockRequest (of the DeliverBlock method) contains a list of "consensus messages", to be handled by the x/consensus module. These messages can be: Pre defined: like the CometInfo which is inserted during FinalizeBlock with no intervention from the block proposer. Proposer defined: like the result of block extensions.

Things we'd like to have Dynamic members: with enough signatures, the account participants can change its members. Flexible sig power: we want different member structures to be possible (by weight, m-of-n, tiers of members, etc). Many signing algos. Migration of existing multisigs Allow sending messages in behalf of individual members (most likely a separate implementation) Dynamic members & flexible sig power We want to allow members of an account to be able to update it with a specific message for it.

This is a proposal to fund a core development and testing package on the Cosmos Hub for 2024. The teams that would receive funding if this proposal passes are the Cosmos Hub Teams from Informal Systems and Hypha Worker Co-operative. The total budget is $5.7 million USD (to be held in 30% ATOM, 70% USDC), plus 100k ATOM in performance bonuses, for a total of 914,285.71 using a spot price of 7 USD. This funding would replace both teams’ current funding from the Interchain Foundation and have these teams be directly accountable to the community. As of October 26, 2023, this represents approximately 18% of the community pool. Notes: - ATOM values have been calculated using a spot price of $7 USD as of October 26, 2023. - This budget only covers the teams at Hypha and Informal that work specifically on the Cosmos Hub. - The ATOM total requested from the community pool includes a 25% buffer on the budget amount to cover fluctuation in ATOM price over the 2-week voting period. Any unused buffer will be returned to the community pool. This proposal is summarized by the following propositions: (1) The release of 1,117,857.14 ATOM to finance:

x/accounts allows us to create new account types that can go from very basic to very complex. Accounts can have their own store (not by account type but by account) and ways of executing messages and authenticating the sender. This doc is for new comers to understand the basics. Implementation details are ignored. What's a bundler? It's a participant of the network, similar to a relayer in IBC. So it's who sends the actual messages to the chain, basically broadcasts and pays for the tx. Who can be a bundler? Anyone can be a bundler.

This issue aims to summary the current status and lay out what would be needed for reducing the amount of sign modes the SDK handles by default. Current status The SDK currently has 4 sign modes: Direct Direct Aux Textual Amino JSON

Overview of ABCI++ With the release of v0.50 of the Cosmos SDK we get the latest version of CometBFT and the brand new ABCI++ interface. Previously with ABCI, the consensus engine (CometBFT) would interact with the app (Cosmos SDK) at decision time when the block has already been created and its contents set. ABCI++ allows the application to intervene at three key places of consensus execution: PrepareProposal: At the moment a new proposal is to be created, the proposer can incorporate application-dependent logic/work into the proposal creation process. ProcessProposal: As a proposal is being validated, validators can perform application-dependent work and checks. This enables validators to evaluate the proposal's compatibility with the application's state and requirements. ExtendVote and VerifyVoteExtensions: Applications can extend the voting process by requiring their validators to perform additional actions beyond simply validating blocks. The application can provide specific instructions or checks that validators must execute before casting their votes.

Module of the month: x/bank 🔥 Module of the Month: Bank from Cosmos SDK Delving into the Bank module (x/bank) from the @cosmos_sdk: Not just any module, but the engine behind multi-asset coin transfers in the Cosmos Ecosystem. Handling both standard and special-case transfers. (1/7) Who's using x/bank? Well, pretty much every chain in the Cosmos Ecosystem. The Cosmos Hub, Osmosis, Celestia, Axelar, Stride and many others use x/bank. Also modules like Staking, Distribution, and even IBC make use of this module to do asset transfer and minting. (2/7) Why is x/bank the Module of the Month? For our first release we wanted to showcase one of the basics but at the same time most important module in the Ecosystem. It's a module often overlooked but always reliable and trusted by developers. (3/7)

Conclusion No issues found. Some stuff can be simplified, lacks some tests and godocs. module.go RegisterGRPCGatewayRoutes Has an ignored error, in the original implementation it panics. fee_utils.go Move tests from antetest/fee_utils_test.go to the same directory; and suite is unnecessary (they are unit tests). getMinGasPrice and bypassMinFeeMsgs don't have a unit test

VoteInfos https://github.com/cosmos/cosmos-sdk/blob/aba08339140d4856a6a4ca7197870de79c8d6447/baseapp/baseapp.go#L91 -> why absent validators? If we do this in BeginBlock: // set the signed validators for addition to context in deliverTx app.voteInfos = req.LastCommitInfo.GetVotes() voteInfos is a bit confusing: voteInfos: This parameter carries the list of validators whose precommit is missing, either because they did not vote or because the proposer did not include their vote. This information is