import type { DIDLog } from '@interop/did-method-webvh';
import type { AccountLogSigner } from './accountEntry.js';
import type { WebvhEnrollmentKeys, WebvhIdStore } from './didWebvh.js';
/**
 * Enrolls a second wallet client into the published did:webvh document -- the
 * log half of the enrollment ceremony. Two entries, forced by prerotation (a
 * new update key must hash into the PREVIOUS entry's `nextKeyHashes`):
 *
 * 1. **Commit**: a sparse entry extending `nextKeyHashes` with the new
 *    client's update-key and staged-key hashes (document and `updateKeys`
 *    untouched).
 * 2. **Add**: an entry adding the new client's verification methods (its
 *    Ed25519 key under the four signing relationships, its X25519 twin under
 *    `keyAgreement`) and its update key to `updateKeys`.
 *
 * On the CLIENT arm both entries are signed by the enrolling client's active
 * update key (quorum-of-one: any single enrolled client can enroll). On the
 * LADDER arm they are signed by the acting credential's rung, through the
 * credential's bridge delegation: the commit entry carries the new client's
 * two hashes beside the rung's own carry-over hash, and the add entry is
 * signed by the same rung, revealed by the commit (`decisions/0018`).
 *
 * The ceremony is resumable from stored state alone: a tear after the commit
 * is detected by its hashes already standing in `nextKeyHashes` (skip to the
 * add entry), and a completed enrollment is detected by the update key
 * already being authorized (no-op). Re-running with the same key set
 * converges without forking the log.
 *
 * Each entry publishes conditionally on the read it was built on (the add
 * entry on the mid-ceremony re-read), so a concurrent ceremony -- a
 * revocation, another enrollment -- can never be erased by this one; a lost
 * race re-runs from the top (see {@link withLogConflictRetry}) and rebases on
 * the new head.
 *
 * @param options {object}
 * @param options.idStore {WebvhIdStore}
 * @param options.signer {AccountLogSigner}   who signs both entries: the
 *   enrolling client's own update-key seeds, or the acting credential's
 *   ladder seed
 * @param options.newClient {WebvhEnrollmentKeys}   the enrollee's public
 *   halves
 * @param [options.expectedDid] {string}   the account DID the log must
 *   resolve to. Every read and publish runs under the store's own chain-head
 *   pin
 * @returns {Promise<{ did: string, log: DIDLog }>}   the account DID and the
 *   post-add log -- the head this call published, or the already-enrolled
 *   head it found -- so an orchestrator can anchor what follows (the ladder
 *   branch's escrow append) at the add entry's version
 */
export declare function enrollWebvhClient(options: {
    idStore: WebvhIdStore;
    signer: AccountLogSigner;
    newClient: WebvhEnrollmentKeys;
    expectedDid?: string;
}): Promise<{
    did: string;
    log: DIDLog;
}>;
//# sourceMappingURL=enrollClient.d.ts.map