alice's account, her named permissions along with their hierarchical dependencies, and her linked
activeauthority table. It also shows that a weight threshold of two must be reached in
activeauthority in order to allow an action associated with the active permission to be executed by or on behalf of
accountschema below). More importantly, each account holds the list of named permissions assigned to it. This allows a flexible permission structure that makes single or multi-user authorizations possible (see 3. Permissions).
nametype consists of a 64-bit value that encodes alphanumeric characters into 5-bit chunks, except the last character, if any, which uses a 4-bit chunk. The
nametype is used to encode account names, action names, etc. The
time_pointtype stores timestamps in microseconds. The
assettype associates a currency or token symbol with a given amount. The
account_resource_limittype keeps track of the amount used, available, and maximum that can be used in a given window for the given resource (NET or CPU). The
permissiontype holds the list of permission levels associated with the account (see 3. Permissions).
parentfield links the named permission level to its parent permission. This is what allows hierarchical permission levels in EOSIO.
actor:child-permissionauthorization within an action to be implicitly satisfied if the
actor:parent-permissionis also satisfied. An authorization quorum or "threshold" must still be met for the action to be authorized for execution (see 3.2.2. Authority Threshold).
contract[::action]). However, defining explicit
actor:permissionauthorizations within actions is preferred versus associating permissions to the whole contract.
active, which sits one level below the
ownerpermission within the hierarchy structure. As a result, the
activepermission can do anything the
ownerpermission can, except changing the keys associated with the owner. The
activepermission is typically used for voting, transferring funds, and other account operations. For more specific actions, custom permissions are typically created below the
activepermission and mapped to specific contracts or actions. Refer to the Creating and Linking Custom Permissions for more details.
activepermission gets compromised.
key_weighttype contains the actor's public key and associated weight. The
permission_level_weighttype consists of the actor's
[email protected]level and associated weight. The
wait_weightcontains the time wait and associated weight (used to satisfy action authorizations in delayed user transactions (see Transactions Protocol: 3.6.3. Delayed User Transactions). All of these types allow to define lists of authority factors that are used for satisfaction of action authorizations (see 3.2.1. Authority factors below).
publishnamed permission is shown below. According to its contents, in order to authorize an action under that permission, a threshold of two must be reached. Since both
[email protected]factors have a weight of two, either one can satisfy the action authorization. This means that either
stacywith a permission level of
activeor higher can independently execute any action under
EOS3Wo1p9er7fh...to satisfy the action authorization. This is because each public key has a weight of 1 in the authority table.
contract[::action]. It does not afford, however, any other account any access or authority to execute that
contract[::action]. This is by design and the process is controlled by a permission evaluation mechanism, described next.
activepermission. Again, this can be customized by creating children permissions under
activeor by creating alternate permissions under
owner(see 3.1. Permission Levels). Creating custom permissions under
active) is recommended. This is because if the keys associated with the
activepermission are compromised, the security of the account will not be compromised.
publishpermission created for message posting on a social media application. However, we do not want to associate that permission with sensitive actions, such as transferring or withdrawing funds. Under this scenario, it makes sense to link the
social::postaction to the
publishpermission. This allows to define an authority structure which can authorize
post, but cannot satisfy the default
activepermission for all other actions. That authority structure could delegate itself to a different account at any named permission level. If it did so to another
publishpermission on another account, that would be purely coincidental.
actor:permissionmeets or exceeds the minimum permission as defined by the per-account permission links.