/**
 * One rung of the ladder: its index, the 32-byte Ed25519 seed behind it, and
 * the update key's public multibase as the log carries it.
 */
export interface LadderRung {
    index: number;
    seed: Uint8Array;
    keyMultibase: string;
}
/**
 * Derives the 32-byte update-key seed of rung `index`.
 *
 * @param options {object}
 * @param options.ladderSeed {Uint8Array}
 * @param options.index {number}   the rung index, from 0
 * @returns {Uint8Array}
 */
export declare function ladderRungSeed({ ladderSeed, index }: {
    ladderSeed: Uint8Array;
    index: number;
}): Uint8Array;
/**
 * Derives rung `index` in full: seed and public multibase.
 *
 * @param options {object}
 * @param options.ladderSeed {Uint8Array}
 * @param options.index {number}   the rung index, from 0
 * @returns {Promise<LadderRung>}
 */
export declare function ladderRung({ ladderSeed, index }: {
    ladderSeed: Uint8Array;
    index: number;
}): Promise<LadderRung>;
/**
 * Derives the 32-byte Ed25519 seed of the ladder VM -- the STABLE SIBLING: a
 * dedicated key derived once from the ladder seed, distinct from every rung,
 * published verbatim in the account document (the seed is random, so the
 * hash-commitment rule permits it) and stable across rung spends, so a
 * delegation it signed survives every ladder advance. It carries the
 * credential's document-visible authority (`assertionMethod` and
 * `capabilityDelegation`), while update authority stays on the rungs -- the
 * two roles never share a key.
 *
 * Its life is the credential's: the VM is installed in the entry that makes
 * the credential standing (`publishUnlockKey`) and struck in the entry that
 * retires it (`removeUnlockKey`). Enrollment never touches it, so several
 * VMs stand on an account with several standing credentials.
 *
 * Because the key is derived, removing its verification method is never the
 * terminal remedy: a later reinstall republishes the same key under the same
 * id, and any still-unexpired delegation it signed resumes verifying the
 * moment the method returns. Revoking the delegations themselves (and,
 * ultimately, rotating the credential) is what actually ends its authority.
 *
 * @param options {object}
 * @param options.ladderSeed {Uint8Array}
 * @returns {Uint8Array}
 */
export declare function ladderVmSeed({ ladderSeed }: {
    ladderSeed: Uint8Array;
}): Uint8Array;
/**
 * The ladder VM's public key multibase, as the document publishes it (see
 * {@link ladderVmSeed} for what the key is).
 *
 * @param options {object}
 * @param options.ladderSeed {Uint8Array}
 * @returns {Promise<string>}
 */
export declare function ladderVmKeyMultibase({ ladderSeed }: {
    ladderSeed: Uint8Array;
}): Promise<string>;
/**
 * Derives the 32-byte update-key seed of an annex generation's rung 0 --
 * the credential's STATIC update key on that generation's annex log. The
 * sequence is domain-separated per generation by the generation id
 * (`<generationId>/rung/0` under the one ladder salt): one shared sequence
 * would hand the storage host, a legitimate reader of the private annex, a
 * revealed key matching the ACCOUNT log's standing commitment, and a fresh
 * per-generation sequence is what makes GC replacement self-healing (no rung
 * index survives the deleted log, and none is needed).
 *
 * The generation id is trusted here rather than re-validated -- the annex
 * ceremonies assert the `gen-<random>` shape (`assertGenerationId`)
 * before any derivation, and the label families stay disjoint for any
 * generation id regardless (an account-rung label carries exactly one
 * slash).
 *
 * @param options {object}
 * @param options.ladderSeed {Uint8Array}
 * @param options.generationId {string}   the generation collection's name
 * @returns {Uint8Array}
 */
export declare function clientAnnexRungSeed({ ladderSeed, generationId }: {
    ladderSeed: Uint8Array;
    generationId: string;
}): Uint8Array;
//# sourceMappingURL=ladderDerivation.d.ts.map