The bank module provides these exported keeper interfaces that can be passed to other modules that read or update account balances. Modules should use the least-permissive interface that provides the functionality they require.
Best practices dictate careful review of
bank module code to ensure that
permissions are limited in the way that you expect.
# Blocklisting Addresses
x/bank module accepts a map of addresses that are considered blocklisted
from directly and explicitly receiving funds through means such as
MsgMultiSend and direct API calls like
Typically, these addresses are module accounts. If these addresses receive funds outside the expected rules of the state machine, invariants are likely to be broken and could result in a halted network.
By providing the
x/bank module with a blocklisted set of addresses, an error occurs for the operation if a user or client attempts to directly or indirectly send funds to a blocklisted account, for example, by using IBC (opens new window).
# Common Types
An input of a multiparty transfer
An output of a multiparty transfer.
The base keeper provides full-permission access: the ability to arbitrary modify any account's balance and mint or burn coins.
Restricted permission to mint per module could be achieved by using baseKeeper with
WithMintCoinsRestriction to give specific restrictions to mint (e.g. only minting certain denom).
The send keeper provides access to account balances and the ability to transfer coins between accounts. The send keeper does not alter the total supply (mint or burn coins).
The view keeper provides read-only access to account balances. The view keeper does not have balance alteration functionality. All balance lookups are