/**
 * pop paymaster status — org gas-sponsorship state from the PaymasterHub.
 *
 * Getters — VERIFIED against contracts origin/main src/PaymasterHub.sol:
 *   getOrgConfig(orgId)     → (adminHatId, operatorHatId, paused, registeredAt, bannedFromSolidarity)
 *   getOrgFinancials(orgId) → (deposited, spent, solidarityUsedThisPeriod, periodStart) — 90-day periods
 *   getFeeCaps(orgId), getBudget(orgId, subjectKey), getSolidarityFund()
 *
 * ── Where the numbers come from ──────────────────────────────────────────────
 * ENTRY_POINT, the OrgConfig, the fee caps and EVERY budget now come from the
 * subgraph (see src/queries/paymaster.ts for the field-by-field verification
 * against both live deployments). That removes 3 + N eth_calls and, more
 * importantly, the serialization: ENTRY_POINT() used to have to resolve before
 * the EntryPoint deposit could even be requested, and each budget was its own
 * call. What is left is three reads — getOrgFinancials, getSolidarityFund and
 * EntryPoint.balanceOf — batched into ONE Multicall3 round trip.
 *
 * Three things deliberately stayed on RPC:
 *   • getOrgFinancials — PaymasterOrgConfig.totalSpent/.depositBalance are
 *     indexed WITHOUT the solidarity fee the hub also debits, so they sit at
 *     exactly 1/1.01 of the contract's `spent` on both live chains. `available`
 *     decides whether sponsorship still works, so it must be the chain's number.
 *     The call also carries solidarityUsedThisPeriod + periodStart, which have
 *     no subgraph field at all.
 *   • getSolidarityFund — numActiveOrgs and feePercentageBps have no field, the
 *     indexed solidarityBalance is stale on Gnosis, and
 *     solidarityDistributionPaused reads `false` on Arbitrum while the contract
 *     reports `true`.
 *   • EntryPoint.balanceOf — the ERC-4337 singleton is not a subgraph data source.
 *
 * ── Budgets and epoch rollover ───────────────────────────────────────────────
 * PaymasterHub resets `usedInEpoch` LAZILY, on the next sponsored UserOperation,
 * so a budget whose epoch elapsed months ago still reports the old spend — and
 * getBudget() returns exactly the same stale figure the subgraph does (verified:
 * both return 7993482525000000 for a Gnosis epoch that ended in May). Rather
 * than print a stale number as if it were current spend, each row is checked
 * against epochStart + epochLen and reported as lapsed, with the effective
 * (post-reset) spend of zero alongside the raw counter.
 *
 * Registration is derived exactly like the contract does it: adminHatId != 0.
 * Budget subject keys are bytes32; for hat-scoped budgets the key is the hat
 * ID zero-padded to 32 bytes (the convention used by agent setup-sponsorship).
 * The admin/operator hats are still probed by name, and the subgraph adds any
 * further subjects the org has funded — hashed keys the CLI could never guess.
 * Pass --hat to name extra subjects when running against the RPC fallback.
 */
import type { Argv, ArgumentsCamelCase } from 'yargs';
interface StatusArgs {
    org?: string;
    chain?: number;
    hat?: Array<string | number>;
}
/** Has this budget's epoch elapsed? The contract zeroes `usedInEpoch` on the next op. */
export declare function budgetEpochState(epochStart: number, epochLen: number, now: number): {
    epochEnd: number | null;
    expired: boolean;
};
export declare const statusHandler: {
    builder: (yargs: Argv) => Argv<{
        hat: string[] | undefined;
    }>;
    handler: (argv: ArgumentsCamelCase<StatusArgs>) => Promise<void>;
};
export {};