KCC 2: Authority Schemes

1. Abstract

This specification defines canonical schemes for authorities represented in KCC-1 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 defined here has a canonical byte identifier and defines how its authority value is encoded and interpreted. A separate byte range is reserved for custom schemes defined outside KCC-2. Higher-level conventions, such as KCC-20, define the roles that use authorities, where their values and scheme bytes are stored, and the complete authorization rules and witness formats.

2. Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Normative prose is authoritative if it conflicts with pseudocode or reference code. KCC-1 [1] defines the Program ABI types, value encodings, hash notation, and P2SH envelope used here. The covenant-id/v1 scheme additionally depends on KIP-20 [2]. KCC-20 is an example consumer, not a dependency of this specification.

2.1 Authority Schemes

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

The following byte identifiers are canonical wherever a Program ABI or a higher-level convention selects a KCC-2 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.

The registry's value space is one unsigned byte (0x00 through 0xff), split into two ranges:

Values 0x05 through 0x7f are unassigned and reserved for future standard schemes. Implementations MUST reject these values and MUST NOT assign them local meanings. New standard registry values are assigned only by a Final KCC that claims them, as specified by KCC-0.

The upper half, 0x80 through 0xff inclusive, is reserved for custom schemes. These schemes MAY be adopted by ecosystem participants without waiting for KCC standardization. A convention using a custom scheme MUST specify its byte, name and version, KCC-1 value type and exact payload length, interpretation, and the checks required to establish its approval. Participants SHOULD coordinate their definitions to support interoperability.

The scheme version fixes the interpretation of the value without introducing a different KCC-1 encoding. Authority values MUST have the type and exact payload length specified in the table or the selected custom scheme definition. The scheme byte is separate from the authority value; this specification does not define a combined serialization of the two.

2.2 Public-Key Authorities

The P2PKH schemes use the unkeyed Hash(x) form defined by KCC-1 Section 3.1 [1], applied directly to the public-key bytes. Their public-key preimages are unambiguous: p2pkh-schnorr/v1 public keys MUST contain exactly 32 bytes, and p2pkh-ecdsa/v1 public keys MUST use the compressed 33-byte encoding.

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 Hash(pubkey) 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.

2.3 Script and Covenant Authorities

2.3.1 P2SH Authority

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

Because consensus requires the matching input's program R to 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 MUST check that the index is in range and the indexed input's script public key matches the construction above.

2.3.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 [2] 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).

2.4 Use by Higher-Level Conventions

KCC-2 does not prescribe generic role declarations or value-location metadata. A convention using KCC-2 MUST define:

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, KCC-20 [4] defines an owner authority using state.owner as its value and state.owner_scheme as its KCC-2 scheme byte.

3. Rationale

A shared scheme registry lets wallets, indexers, and applications interpret an authority consistently while leaving role and witness design to each application. The custom range allows ecosystem adoption before standardization: its interpretation requires agreement on the custom scheme definition because the same byte may identify different schemes in different conventions.

P2SH and Covenant IDs serve different purposes. The former commits to one exact program, including embedded state, while the latter identifies a continuing lineage whose program and state may change. Requiring a spent input allows that authority's own program to enforce participation, without prescribing one authorization protocol for every application.

4. Conformance Vectors

The vectors below are also provided in authority-schemes.json. The JSON is authoritative for automated testing. All byte strings are lowercase hexadecimal without a 0x prefix; integers and booleans are JSON numbers and booleans.

4.1 Authority Values and Encodings

The constructions array contains these five cases. Each scheme_byte is the raw registry byte, and authority_value is the raw 32-byte payload, without Script push opcodes. For every case, both argument_encoding and state_encoding are 20 || authority_value, using KCC-1 PushMinimal and PushExplicit respectively. These encodings do not include the scheme byte.

For both P2PKH cases, authority_value is Hash(public_key), computed using unkeyed BLAKE3 over the raw public-key bytes.

id              = p2pk-schnorr
scheme_byte     = 00
value_type      = pubkey
public_key      = 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
authority_value = 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

id              = p2pkh-schnorr
scheme_byte     = 01
value_type      = byte[32]
public_key      = 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
authority_value = f9f2a0b353f482f415281da3a00929d08a7d9a6498054f5ef6623b5580e607f7

id              = p2pkh-ecdsa
scheme_byte     = 02
value_type      = byte[32]
public_key      = 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
authority_value = 1a15d6547364ad963c3b840e885639bb8136a4de757c0e7cf63f5de2f1cfbdbe

id              = p2sh
scheme_byte     = 03
value_type      = byte[32]
redeem_script   = 51
authority_value = ce57216285125006ec18197bd8184221cefa559bb0798410d99a5bba5b07cd1d
script_public_key.version = 0
script_public_key.script  = aa20ce57216285125006ec18197bd8184221cefa559bb0798410d99a5bba5b07cd1d87

id              = covenant-id
scheme_byte     = 04
value_type      = byte[32]
covenant_id     = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
authority_value = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

The P2SH example uses the KCC-1 Section 11.2 [1] hash fixture R = 51 (OP_1), it is not a secure authorization program. The Covenant ID is an opaque fixture for a consensus-authenticated input lineage, not a genesis-ID derivation. KCC-2 defines no new Covenant ID hash or byte order.

4.2 Minimum Approval Checks

Each approval_checks entry selects a construction by its construction ID and supplies a context and an expected boolean. The contexts below test KCC-2's minimum checks only. All assigned schemes are supported in these cases.

For signature schemes, public_key is the key used for verification, and signature_valid is the result of signature verification under that key using the higher-level convention's message and signature encoding.

For P2SH, input_script_public_keys lists the spent inputs' authenticated script public keys, each with separate version and script fields. For Covenant IDs, input_covenant_ids lists their authenticated IDs, with null for an input without a covenant binding. The active input is included at active_input_index.

5. Reference Implementation

Non-normative reference code illustrates the minimum checks in Silverscript and Argent. These snippets are not a complete application or a demonstrated conformance-passing implementation.

6. Security Considerations

Consensus validity alone does not establish authorization under the consuming application's policy. The application MUST enforce the selected authority scheme's approval checks and any additional authorization conditions.

Authority values and scheme selections MUST come from authenticated program state or another source authenticated under the application's authorization rules. Accepting an attacker-selected authority or changing its scheme without authorization defeats the checks even when a signature is valid.

Public-key schemes rely on signature security, correct public-key and signature validation. P2PKH additionally relies on BLAKE3 commitment security. P2SH relies on BLAKE2b commitment security. Length checks and scheme validation prevent interpreting the same payload under an unintended verification rule. A key commitment alone is not approval: the revealed key MUST also verify the required signature.

KCC-2 does not choose a signed message, signature encoding, or replay domain. The consuming convention is responsible for binding approval to the intended operation and relevant state and transaction data.

P2SH and Covenant-ID checks rely on consensus validation of spent inputs and their authenticated UTXO data. Witness-supplied metadata or a matching output alone provides no such guarantee. An input-index witness MUST be in range and select an input whose full script public key, including its version, matches. A P2SH authority commits to every byte of R, including embedded state. A template match is not an exact-script match.

Participation is only the minimum approval condition. An anyone-can-spend program, a permissive branch, or a covenant that permits arbitrary co-spending may participate without approving the application's intended operation. Applications MUST ensure the authority's own rules constrain that use, or add appropriate template, state, and transition checks.

7. References

• [1] KCC-1, Covenant definition, concepts, bytes layout and ABI.
• [2] KIP-20, Covenant IDs.
• [3] KCC-0, KCC Purpose and Guidelines.
• [4] KCC-20, Fungible Token Covenant Specification.

8. Copyright

Copyright and related rights waived via CC0.