| Field | Type | Description | |
|---|---|---|---|
| key | oneof | | |
| | contractID | ContractID | smart contract instance that is authorized as if it had signed with a key |
| | ed25519 | | ed25519 public key bytes |
| | RSA_3072 | | RSA-3072 public key bytes (NOT SUPPORTED) |
| | ECDSA_384 | | ECDSA with the p-384 curve public key bytes (NOT SUPPORTED) |
| | thresholdKey | ThresholdKey | a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| | keyList | KeyList | A list of Keys of the Key type. |
ECDSA_secp256k1 | Compressed ECDSA(secp256k1) public key bytes | ||
delegatable_contract-id | ContractID | A smart contract that, if the recipient of the active message frame, should be treated as having signed. (Note this does not mean the code being executed in the frame will belong to the given contract, since it could be running another contract’s code via delegatecall. So setting this key is a more permissive version of setting the contractID key, which also requires the code in the active message frame belong to the contract with the given id.) |
Basic Types
Key
A Key can be a public key from either the Ed25519 or ECDSA(secp256k1) signature schemes, where in the ECDSA(secp256k1) case we require the 33-byte compressed form of the public key. We call these public keys primitive keys.
If an account has primitive key associated to it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. A Key can also be the ID of a smart contract instance, which is then authorized to perform any precompiled contract action that requires this key to sign.
Note that when a Key is a smart contract ID, it doesn’t mean the contract with that ID will actually create a cryptographic signature. It only means that when the contract calls a precompiled contract, the resulting “child transaction” will be authorized to perform any action controlled by the Key.
A Key can be a “threshold key”, which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements.
A Key can be a “key list” where all keys in the list must sign unless specified otherwise in the documentation for a specific transaction type (e.g. FileDeleteTransactionBody). Their use is dependent on context. For example, a Hedera file is created with a list of keys, where all of them must sign a transaction to create or modify the file, but only one of them is needed to sign a transaction to delete the file. So it’s a single list that sometimes acts as a 1-of-M threshold key, and sometimes acts as an M-of-M threshold key. A key list is always an M-of-M, unless specified otherwise in documentation. A key list can have nested key lists or threshold keys.Nested key lists are always M-of-M. A key list can have repeated primitive public keys, but all repeated keys are only required to sign once.
A Key can contain a ThresholdKey or KeyList, which in turn contain a Key, so this mutual recursion would allow nesting arbitrarily deep. A ThresholdKey which contains a list of primitive keys has 3 levels: ThresholdKey -> KeyList -> Key. A KeyList which contains several primitivekeys has 2 levels: KeyList -> Key. A Key with 2 levels of nested ThresholdKeys has 7 levels: Key -> ThresholdKey -> KeyList -> Key -> ThresholdKey -> KeyList -> Key.
Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.
\