Authority Schemes

1. Abstract

This specification defines canonical schemes for authorities represented in KCC1 Program ABIs. An authority is a public key, key commitment, program, or covenant lineage whose approval may be required for an application operation.

Each scheme has a canonical byte identifier and defines how its authority value is encoded and interpreted. Higher-level conventions, such as KCC20, define the roles that use authorities, where their values and scheme bytes are stored, and the complete authorization rules and witness formats.

Reference implementations: Non-normative Silverscript and Argent code is provided in KCC2 reference code.

2. Authority schemes

An authority value identifies or commits to an authority. An authority scheme defines the value's KCC1 type, meaning, and minimum approval check.

The following byte identifiers are canonical wherever a Program ABI or a higher-level convention selects a KCC2 authority scheme:

The byte identifies the scheme, not the authority. A higher-level convention MAY support only a subset of these schemes, but MUST use the canonical byte for every scheme it supports. Unassigned byte values are reserved for future KCCs.

The scheme version fixes the interpretation of the value without introducing a different KCC1 encoding.

3. Public-key authorities

The P2PKH schemes use the keyed Hash(x, key) form defined by KCC1 Section 3.1 [1]. Their domain-separation key is UTF8("PublicKeyHash"):

P2PKHHash(pubkey) = Hash(pubkey, UTF8("PublicKeyHash"))

The same key is used for both P2PKH schemes. Their public-key preimages are unambiguous because p2pkh-schnorr/v1 requires exactly 32 bytes and p2pkh-ecdsa/v1 requires exactly 33 bytes.

Approval under p2pk-schnorr/v1 MUST include a valid signature by the public key stored in the authority value.

Approval under either P2PKH scheme MUST reveal the corresponding public key, require its P2PKHHash to equal the authority value, and include a valid signature by that key.

The higher-level convention defines the signed message, signature encoding, witness location, and any additional authorization conditions.

4. Script and covenant authorities

4.1 P2SH authority

For p2sh/v1, R is the exact P2SH redeem script and the authority value is its commitment as defined by KCC1 Section 7 [1]. Approval under this scheme MUST include a transaction input whose script public key is the KCC1 version-0 P2SH envelope for that commitment.

Because the matching input's program R must be revealed and accept the transaction, it participates as an authority according to its own script logic (see P2SH reference).

A higher-level convention defines how the matching P2SH input is located. It MAY include the input index in its witness, in which case the application checks that the indexed input's script public key matches the construction above.

4.2 Covenant-ID authority

Approval under covenant-id/v1 MUST include a transaction input belonging to the KIP-20 [2] lineage identified by the authority value. That input likewise participates according to its own program logic. The program and state within a lineage may evolve while its Covenant ID remains stable.

KIP-20 provides OpCovInputCount(covenant_id), so an application can test for participation by requiring OpCovInputCount(authority_value) > 0 without an input-index witness. The matching input may be the active input itself.

For covenant-id/v1, requiring a matching input is the minimum approval check. A higher-level convention MAY additionally authenticate the program template and inspect the state of one or more matching inputs. It may also enumerate outputs belonging to the same covenant ID, authenticate their program templates, and validate their states. These checks constrain how the authority covenant participates, rather than merely requiring its presence.

Using a Covenant ID authority to require and optionally inspect another covenant's participation is a common form of inter-covenant communication (ICC).

5. Use by higher-level conventions

KCC2 does not prescribe generic role declarations or value-location metadata. A convention using KCC2 defines:

1. the authority role, such as owner, issuer, or admin;
2. the field containing the authority value;
3. the field containing the authority-scheme byte, or a fixed scheme;
4. the supported scheme subset; and
5. the complete authorization and witness rules.

For example, KCC20 defines an owner authority using state.owner as its value and state.owner_scheme as its KCC2 scheme byte.

6. References

• [1] KCC1, Covenant definition, concepts, bytes layout and ABI.
• [2] KIP-20, Covenant IDs.