import type { ZcapClient } from '@interop/ezcap';
import type { ICapabilityAgent } from '../webvh/zcap.js';
/**
 * A ZcapClient signing with the account ladder's document-visible
 * verification method -- the ladder VM, derived from the credential's ladder
 * seed and published under `assertionMethod` and `capabilityDelegation` only.
 * Its keyId is `<accountDid>#<ladderVmMultibase>` (the flat Multikey shape
 * `ladderVerificationMethod` publishes, which `@interop/zcap`'s `isController`
 * check and the server's fragment resolver both depend on).
 *
 * Only DELEGATION is licensed for this client: the ladder VM carries no
 * `capabilityInvocation`, so an invocation signed with it fails the server's
 * current-key-set rule by construction. It exists so a ladder-anchored
 * account -- or a transient session holding nothing but the unlock credential
 * -- can mint the client annex generation delegation and the ladder-signed
 * renewals.
 *
 * That one-sided relation set is also how this library and the storage server
 * recognize a ladder VM. The annex's per-visit transient VM is the sibling
 * case and holds BOTH relations (decision 0013): it invokes the generation
 * delegation for the visit's own requests and delegates the visit's grants
 * onward, so it never matches the asymmetry.
 *
 * @param options {object}
 * @param options.accountDid {string}   the account did:webvh
 * @param options.ladderSeed {Uint8Array}   the credential's ladder seed, from
 *   its unlock record
 * @returns {Promise<ZcapClient>}
 */
export declare function ladderVmZcapClient({ accountDid, ladderSeed }: {
    accountDid: string;
    ladderSeed: Uint8Array;
}): Promise<ZcapClient>;
/**
 * The account ladder VM's key pair presented as a plain did:key agent -- the
 * ladder-anchored signup's BOOTSTRAP identity. The data Space (and the
 * auxiliary annex Space) of a credential-anchored signup are created
 * under this
 * did:key, exactly the role the founding client's persisted did:key plays in
 * the enrolled-client flow: any later login that decrypts the unlock record
 * re-derives the ladder seed and can finish (or unwind) a torn bootstrap --
 * the durability precondition restored by derivation instead of persistence.
 *
 * The derivation matches {@link ladderVmZcapClient}'s exactly
 * (`Ed25519VerificationKey.generate` over `ladderVmSeed`), so the bare
 * did:key controller and the document-published ladder VM are one key.
 *
 * @param options {object}
 * @param options.ladderSeed {Uint8Array}   the credential's ladder seed
 * @returns {Promise<ICapabilityAgent>}
 */
export declare function ladderVmAgent({ ladderSeed }: {
    ladderSeed: Uint8Array;
}): Promise<ICapabilityAgent>;
/**
 * The ladder VM's two presentations from ONE key generation: the bare did:key
 * agent a bootstrap identity invokes as, and the ZcapClient that delegates
 * under `<accountDid>#<multibase>`. A caller needing both -- a ceremony that
 * mints delegations while invoking as the ladder -- takes them here instead of
 * paying the Ed25519 generation twice.
 *
 * @param options {object}
 * @param options.accountDid {string}   the account did:webvh
 * @param options.ladderSeed {Uint8Array}   the credential's ladder seed
 * @returns {Promise<{ agent: ICapabilityAgent, zcapClient: ZcapClient }>}
 */
export declare function ladderVmSigners({ accountDid, ladderSeed }: {
    accountDid: string;
    ladderSeed: Uint8Array;
}): Promise<{
    agent: ICapabilityAgent;
    zcapClient: ZcapClient;
}>;
//# sourceMappingURL=zcap.d.ts.map