@pwngh/economy-lab
    Preparing search index...

    Interface AccrualRow

    One seller share parked on a SETTLEMENT_ACCRUAL shard by a spend or subscribe under the accrual split (config.accrualDrain). A positive row is a share awaiting the drain; a negative row is refund-recovery debt appended when a refund reverses an already-drained share. Rows are never deleted: terminal rows are the permanent per-order share record refund reads instead of the sale's legs.

    interface AccrualRow {
        amount: Amount;
        orderId: string;
        recordedAt: number;
        sellerId: string;
        seq: number;
        settledTxnId: string | null;
        shard: AccountRef;
        status: "pending" | "drained" | "refunded";
        txnId: string;
    }
    Index
    amount: Amount

    The share in CREDIT; negative on a refund-recovery row.

    orderId: string

    The order (or, for subscription charges, the posting id) the share came from.

    recordedAt: number

    Epoch ms the row was written; the drain-lag gauge ages pending rows by it.

    sellerId: string
    seq: number

    Distinguishes rows of one (orderId, sellerId): 0 for the sale share, higher for recovery rows.

    settledTxnId: string | null

    The drain or refund posting that settled the row; null while pending.

    shard: AccountRef

    The SETTLEMENT_ACCRUAL shard the spend credited; the drain debits the same row.

    status: "pending" | "drained" | "refunded"
    txnId: string

    The posting that created the row, immutable — refund matches an order's rows to its sale posting by it, so a hostile orderId that collides with another charge's key can never pull that charge's rows into a reversal.