Module Accounts

There are certain modules that have their own module account. Imagine this as a wallet that is only accessible through that module. The modules, their associated wallet addresses, and their permissions are shown below:

List of Module Accounts

Name	Address	Permissions
gov	human1	burner
distribution	human1	none
evm	human1	minter burner
ibc	human1	minter burner

Account Permissions

• The burner permission designates that this account is permitted to burn or destroy tokens.
• The minter permission implies that this account is allowed to mint additional tokens.
• The staking permission means the owner has given this account permission to stake tokens on the owner's behalf.

IBC Module Accounts

There are also module accounts connected to IBC transfers. When Humans.ai is the source chain, there is a ModuleAccount account of type for each IBC connection that is used to escrow the transferred funds. According to ADR 028, their addresses are generated using the first 20 bytes of the account name's SHA256 checksum.

// accountName is composed by the current version the IBC transfer module supports (in this case, ics20-1), the portID (transfer) and the channelID
accountName := Version + "\0" + portID + "/" + channelID
addr := sha256.Sum256(accountName)[:20]

// example for channel-0
addr := sha256.Sum256("ics20-1\0transfer/channel-0")[:20]

This may be computed using the GetEscrowAccount function on IBC-go.

note

If you do the following query, these escrow accounts are not displayed:

humansd q auth module-accounts

The reason for this phenomenon is that the GetModuleAccount function utilized in the query only considers the accounts present in the permAddrs map of the AccountKeeper. This map is predefined before compilation and cannot be altered during runtime.