XChain Platform Action - DELEGATE

This action manages the signing key bound to a staked validator, supporting four flavors: capability delegation (v0), contract-targeted delegation (v1), capability revoke (v2), and contract-targeted revoke (v3).

PARAMS

Formats

Version 0 - Capability Delegation

• VERSION|NEW_SIGNING_PUBKEY

Version 1 - Contract-Targeted Delegation

• VERSION|NEW_SIGNING_PUBKEY|TARGET_CONTRACT_INDEX|TICK

Version 2 - Capability Revoke

• VERSION|SIGNING_PUBKEY

Version 3 - Contract-Targeted Revoke

• VERSION|SIGNING_PUBKEY|TARGET_CONTRACT_INDEX|TICK

Examples

DELEGATE|0|abc123...def
Rotate the signing key for the broadcaster's capability stake

DELEGATE|1|abc123...def|500|MYTOKEN
Rotate the signing key for the broadcaster's (contract=500, tick=MYTOKEN) stake row

DELEGATE|2|abc123...def
Revoke the specified signing key from the broadcaster's capability stake

DELEGATE|3|abc123...def|500|MYTOKEN
Revoke the specified signing key from the broadcaster's (contract=500, tick=MYTOKEN) stake row

Rules

• SIGNING_PUBKEY (the indexer’s canonical name for this field across all versions) must be a valid 64-character hex-encoded Ed25519 public key. The wire field is labeled NEW_SIGNING_PUBKEY in v0/v1 and SIGNING_PUBKEY in v2/v3, but the indexer parses and stores the value as SIGNING_PUBKEY in all four cases.

v0 (capability rotate)

• BTC chain only.
• Broadcasting address must have an active capability stake (gated by the 6-block activation delay).
• SIGNING_PUBKEY (wire: NEW_SIGNING_PUBKEY) must not already be in use by any active stake or delegation.

v1 (contract rotate)

• Works on any chain (BTC, LTC, DOGE).
• Broadcasting address must own an active STAKE v3 row for (TARGET_CONTRACT_INDEX, TICK) (the lookup filters on contract index, broadcasting source, and tick; SIGNING_PUBKEY in the wire format is the new key to rotate to, not a lookup field).
• TARGET_CONTRACT_INDEX must be a positive integer pointing at a stakeable contract.
• TICK must match the existing stake row’s token.
• SIGNING_PUBKEY (wire: NEW_SIGNING_PUBKEY) must not already be in use by any active stake or delegation scoped to the same contract.

v2 (capability revoke)

• BTC chain only.
• Broadcasting address must have an active delegation for the specified SIGNING_PUBKEY (gated by the 6-block activation delay), or an active capability stake whose original signing key is SIGNING_PUBKEY; revoking the original stake key is what completes the key-compromise procedure (see Notes).
• A stake key already revoked by a previous v2 cannot be revoked again. Re-staking the same key later (STAKE v2 re-activation) clears the revocation.

v3 (contract revoke)

• Works on any chain (BTC, LTC, DOGE).
• Broadcasting address must own an active contract-targeted delegation matching (TARGET_CONTRACT_INDEX, SIGNING_PUBKEY, TICK).
• TARGET_CONTRACT_INDEX must be a positive integer pointing at a stakeable contract.
• TICK must match the existing delegation’s token.

Activation and Deactivation Delay

All four versions are gated by an activation delay (measured in blocks of the chain on which the action was broadcast) before taking effect, tracked via the activation_block / deactivation_block columns on the delegations (v0/v2) or contract_delegations (v1/v3) tables. The delay is calibrated per chain for approximately 60 minutes of reorg protection: 6 blocks on BTC (~10 min/block), 24 on LTC (~2.5 min/block), 60 on DOGE (~1 min/block); a flat block count would otherwise give DOGE only about 6 minutes. Capability-staking delegations (v0/v2) are BTC-only and use the 6-block BTC value; contract delegations (v1/v3) apply the per-chain value. The worked examples below use BTC’s 6 blocks.

• v0 / v1 (rotate): the new delegated key does not take effect immediately; it becomes active after 6 blocks. During the delay, signatures from the new key are rejected.
• v2 / v3 (revoke): revocation does not take effect immediately; the key remains active for 6 blocks after the action confirms.

This prevents short-range chain reorgs from leaving a stake without a valid signer.

Effective Signer Set (Additive Until Revoked)

Capability delegation (v0/v2) is additive: a delegation adds a signing key, it never replaces one. A staking address’s effective signer set at block height h is:

• the original signing keys of its active stakes at h, excluding keys revoked via v2 whose revocation is in effect at h, plus
• the keys of its active delegations at h (activation delay passed, not revoked).

Every consensus surface resolves through this one definition: capability snapshots, PBFT quorum membership and counts, on-chain signature verification (e.g. PRICE v0), and validator reward attribution. A delegated key is backed by the delegating address’s aggregate active stake; delegating never changes staked amounts, it only changes which keys may sign.

Collision rules keep the set unambiguous: a key can never simultaneously be a stake key and a delegated key (STAKE v1 rejects keys held by an active delegation; DELEGATE v0 rejects keys held by any active stake or delegation), and a key can only be delegated by one address at a time.

Notes

• Use v0/v1 to rotate signing keys for security hygiene without disrupting validator status.
• Use v2/v3 to remove a delegated key without replacing it. A stake with no valid signing key will not participate in validator duties until a new key is delegated via v0/v1.
• The 6-block delay means that for emergency key compromise scenarios, operators must:
  1. Broadcast a rotate (v0/v1) with a new key (takes 6 blocks to activate)
  2. Broadcast a revoke (v2/v3) for the old key (takes 6 blocks to deactivate); for a compromised original stake key, this is the v2 stake-key revoke
  3. During the overlap window, both keys are valid; the new key takes effect approximately 6 blocks before the old key is fully revoked.

stateDiagram-v2
    [*] --> old_key_active: old key is sole valid signer
    old_key_active --> new_key_pending: DELEGATE v0/v1 rotate broadcast<br>(new key)
    new_key_pending --> overlap: 6 blocks, new key activates
    overlap --> old_key_revoking: DELEGATE v2/v3 revoke broadcast<br>(old key)
    old_key_revoking --> new_key_only: 6 blocks, old key deactivates
    new_key_only --> [*]

• A v2 stake-key revocation is cleared only by re-staking the same key (STAKE v2 re-activation); there is no separate “un-revoke”. Rotating back to a revoked original key is otherwise impossible (v0 rejects keys with stake history).
• Does not affect staked token amounts or capability qualifications.

Copyright © 2025–2026 Dankest, LLC

Based on XChain Platform by Dankest, LLC – https://dankest.llc

Licensed under the GNU Affero General Public License v3.0 (AGPL-3.0-or-later) with a commercial license available for proprietary use.

You may use, modify, and distribute this material under the terms of the License. See LICENSE and NOTICE for full terms. See the licensing overview.