/**
 * The one place Turnkey actually signs (plan 045).
 *
 * Both the server and client signers had their own copy of this — hex-encode,
 * pick a hash function, concatenate r‖s, check 64 bytes — kept in sync by
 * comment. They now share it, and because it is byte-level it satisfies
 * `OriginalsSigner.signBytes` / `ExternalSigner.signBytes` directly, so a
 * Turnkey key can author CEL events and sign credentials rather than only
 * did:webvh logs.
 *
 * Browser-safe: hex conversion goes through @noble/hashes, not `Buffer`. This
 * is a root export of `@originals/auth` and the client signer runs in the
 * browser, where `Buffer` is not defined without a bundler shim.
 */
import type { Turnkey } from '@turnkey/sdk-server';
export interface TurnkeySignBytesOptions {
    turnkeyClient: Turnkey;
    /** Turnkey sub-organization id. */
    organizationId: string;
    /** The account to sign with (address or private key id). */
    signWith: string;
}
/**
 * Signs exactly `data` with a Turnkey-held Ed25519 key.
 *
 * `HASH_FUNCTION_NOT_APPLICABLE`, and the choice is not cosmetic: Turnkey
 * REJECTS `HASH_FUNCTION_NO_OP` on an Ed25519 key with
 * `cannot use hash function NoOp to produce ed25519 signature`, which is a
 * hard failure at sign time, not a warning. Ed25519 takes the message itself
 * and hashes internally as part of the signature scheme, so there is no
 * pre-hash slot to declare as a no-op — that enum belongs to the ECDSA curves,
 * where a caller may hand over a digest.
 *
 * The intent is unchanged and is what NOT_APPLICABLE expresses here: the
 * caller (the SDK) owns canonicalization, and Turnkey signs the bytes it is
 * given verbatim rather than transforming them.
 *
 * @returns the raw 64-byte Ed25519 signature
 */
export declare function turnkeySignBytes({ turnkeyClient, organizationId, signWith }: TurnkeySignBytesOptions, data: Uint8Array): Promise<Uint8Array>;
//# sourceMappingURL=turnkey-sign-bytes.d.ts.map