@arkade-os/sdk Documentation - v0.5.0-rc.11
    Preparing search index...

    Interface ContractManagerConfig

    Configuration for the ContractManager.

    interface ContractManagerConfig {
        chainTip?: () => Promise<{ height: number; time: number } | undefined>;
        contractRepository: ContractRepository;
        indexerProvider: IndexerProvider;
        intentRepository?: IntentRepository;
        lookAhead?: LookAheadConfig;
        onVtxosPersisted?: (
            contract: Contract,
            vtxos: ExtendedVirtualCoin[],
        ) => Promise<void>;
        onVtxosSpent?: (vtxos: Outpoint[]) => Promise<void>;
        vtxoSyncMaxAgeMs?: number;
        walletRepository: WalletRepository;
        watcherConfig?: Partial<ContractWatcherConfig>;
    }
    Index

    Properties

    chainTip? contractRepository indexerProvider intentRepository? lookAhead? onVtxosPersisted? onVtxosSpent? vtxoSyncMaxAgeMs? walletRepository watcherConfig?

    Properties

    chainTip?: () => Promise<{ height: number; time: number } | undefined>

    Current chain tip height, for the blockHeight a PathContext carries. Absent, or resolving undefined, leaves blockHeight unset.

    isCltvSatisfied answers false outright for a height-typed locktime when blockHeight is missing, so every such path was reported unspendable however mature it was. Nothing populated this before, which made that the only behaviour available. Seconds-typed locktimes read currentTime and are unaffected either way.

    Block-typed CSV is not fixed by this. isCsvSpendable also needs the VTXO's confirmation height, and status.block_height is never populated for a virtual coin, so it stays false regardless of the tip.

    Both fields matter. height answers height-typed timelocks; time (the tip's timestamp, in SECONDS) is what seconds-typed ones should be judged against, because the machine's clock is an estimate of chain time and a drifting one reads the boundary wrong.

    Resolve undefined rather than rejecting when the tip cannot be read: the callers treat it as "unknown", which is the pre-existing behaviour, and a path query is not worth failing over a provider hiccup.

    contractRepository: ContractRepository

    The contract repository for persistence

    indexerProvider: IndexerProvider

    The indexer provider

    intentRepository?: IntentRepository

    Optional intent store. When present, the online sync path reconciles persisted non-terminal settlement intents against authoritative indexer state (crash recovery) on boot and reconnect — see reconcileIntents. Absent ⇒ no-op.

    lookAhead?: LookAheadConfig

    Enables the HD look-ahead watch window. Absent ⇒ feature off (static / non-HD wallets, third-party embedders). See ContractManager.refillLookAhead.

    onVtxosPersisted?: (
        contract: Contract,
        vtxos: ExtendedVirtualCoin[],
    ) => Promise<void>

    Optional exit-data capture hook. Fired best-effort after VTXOs are persisted so a configured virtualTxRepository can store each one's unilateral-exit branch. Absent ⇒ no-op.

    onVtxosSpent?: (vtxos: Outpoint[]) => Promise<void>

    Optional exit-data prune hook. Fired best-effort with the spent outpoints on vtxo_spent so a configured virtualTxRepository can drop their branch. Absent ⇒ no-op.

    vtxoSyncMaxAgeMs?: number

    How stale ContractManager.getContractsWithVtxos may let its opportunistic sync be before repeating it. 0 (default) repeats it every call. A send syncs, selects, then submits, so its coins are already one submit latency stale; this widens that bound by this value, and is therefore a budget rather than a free saving.

    walletRepository: WalletRepository

    The wallet repository for virtual output storage (single source of truth)

    watcherConfig?: Partial<ContractWatcherConfig>

    Watcher configuration

    Settings

    Member Visibility

    On This Page

    Properties