import { type RevocationCheckPolicy } from './delegation.js';
import type { ActionReceipt, Delegation, BeneficiaryTrace, AttributionReport, MerkleProof, BeneficiaryInfo } from '../types/passport.js';
export declare function hashReceipt(receipt: ActionReceipt): string;
/**
 * Follow the delegation chain from an action receipt back to the human who
 * authorized it. Reports two DISTINCT, honestly-named properties:
 *
 *   resolved  Lookup success only. Every hop's (from,to) key pair maps to a
 *             known delegation record AND the principal resolves to a known
 *             beneficiary. This proves the lineage RESOLVES against the supplied
 *             records, NOT that it is authentic: a creator-supplied chain that
 *             happens to match known records can be `resolved`. Do not trust it
 *             as proof of authorization.
 *
 *   verified  Cryptographic verification. The receipt signature is authentic
 *             (checked with verifyReceipt against the executor at the chain
 *             tail) AND every delegation in the traced lineage passes
 *             verifyDelegation (its own ed25519 signature by its delegator is
 *             valid and it is within its validity window). A tampered or forged
 *             chain CANNOT be `verified`: a hop whose delegator key the caller
 *             does not hold fails verifyDelegation. This reuses the canonical
 *             verifiers and does not reimplement crypto.
 *
 *             Scope of the claim: `verified` attests that the lineage signatures
 *             are authentic and temporally valid. It does NOT check that the
 *             action was authorized (scopeUsed within the delegation scope) or
 *             that scope narrows between hops (use verifyDelegationChain /
 *             scopeAuthorizes), and it does NOT consult revocation
 *             (verifyDelegation runs fail-open on this path unless the caller
 *             threads a revocation cache).
 *
 * Every agent action resolves to a human. `verified` is the field to trust;
 * `resolved` is a convenience lookup that makes no cryptographic claim.
 */
/** Revocation posture for an attribution walk.
 *
 *  A chain walk checks MANY delegations, so it cannot take the single
 *  `cachedRevocationState` the other entrypoints take: one delegation's
 *  evidence applied to every hop would be a new defect, not a fix. Evidence is
 *  supplied per delegation through a resolver instead, the same shape the v2
 *  authority-delegation verifier uses.
 *
 *  Omitting this leaves the historical default exactly: policy `fail_open`,
 *  no evidence consulted, which is what this walk has always done. */
export interface AttributionRevocationOptions {
    revocationCheckPolicy?: RevocationCheckPolicy;
    cacheGraceMs?: number;
    /** Called once per candidate delegation. Return undefined when no evidence
     *  is held for that delegation; under `fail_closed` that hop is then not
     *  authentic, which is the point of selecting it. */
    resolveRevocation?: (delegation: Delegation) => {
        revoked: boolean;
        checkedAt: string;
    } | undefined;
}
/**
 * Legacy lineage authenticity for a chain of legacy Delegation records.
 *
 * WHAT THIS IS NOT. This is not draft-03 principal attribution and not a
 * beneficiary determination under the protocol. draft-pidlisnyi-aps-03 section 12
 * keeps four attribution axes apart: authority (the delegation chain), contribution,
 * principal (the entity on whose behalf the agent acted, reported as self_asserted,
 * principal_attested or externally_verified_principal under section 2.3), and
 * beneficiary (the entity that receives the value the work creates). The draft
 * specifies the authority and principal axes and states that it does not specify a
 * beneficiary-attribution model, so nothing this function returns is a draft-03
 * beneficiary result.
 *
 * The beneficiary here is whatever the caller's beneficiaryMap says it is. Where the
 * map has no entry, the reported beneficiary falls back to the root of the legacy
 * delegation chain, which is an authority fact, not a statement about who benefits.
 *
 * What the result does establish is lineage authenticity: whether each hop of the
 * supplied legacy chain carries a delegation whose signature and temporal validity
 * check out under the caller's revocation posture. It implies no allocation of
 * credit, benefit, compensation, liability or ownership, which section 12 places
 * outside the document and does not imply from the authority chain.
 *
 * The record type is the pre-draft compatibility Delegation, not the draft-03
 * AuthorityDelegationV1 of section 3.1. See the note on createDelegation.
 */
export declare function traceBeneficiary(receipt: ActionReceipt, delegations: Delegation[], beneficiaryMap: Map<string, BeneficiaryInfo>, revocation?: AttributionRevocationOptions): BeneficiaryTrace;
export declare function verifyAttributionReport(report: AttributionReport, publicKey: string): {
    valid: boolean;
    errors: string[];
};
/**
 * Build a Merkle root from leaf hashes.
 * Leaves are sorted for determinism — same set always produces same root.
 * Leaves and internal nodes are domain-separated; an odd node at any level
 * is carried up unchanged (never duplicated) to avoid the CVE-2012-2459
 * duplicate-leaf collision.
 */
export declare function buildMerkleRoot(leafHashes: string[]): string;
/**
 * Generate an inclusion proof for one receipt in the tree.
 * Returns the sibling hashes needed to recompute the root.
 */
export declare function generateMerkleProof(leafHashes: string[], targetHash: string): MerkleProof | null;
/**
 * Verify a Merkle inclusion proof.
 * Recompute the root from the leaf + proof, compare against claimed root.
 */
export declare function verifyMerkleProof(proof: MerkleProof): boolean;
export declare const DEFAULT_SCOPE_WEIGHTS: Record<string, number>;
export declare function computeAttribution(..._args: unknown[]): never;
export declare function computeCollaborationAttribution(..._args: unknown[]): never;
//# sourceMappingURL=attribution.d.ts.map