@klappay/types 6.0.0 → 6.1.0

package/dist/index.d.mts

@@ -1519,6 +1519,8 @@ declare const CheckChargeResponseSchema: z.ZodObject<{
     }>>;
 } & {
     transactionSender: z.ZodNullable<z.ZodString>;
+    tokenSenders: z.ZodArray<z.ZodString, "many">;
+    userOperationSenders: z.ZodArray<z.ZodString, "many">;
     confirmationProgress: z.ZodNullable<z.ZodObject<{
         network: z.ZodEnum<["base", "optimism", "polygon", "ethereum", "arbitrum", "avalanche", "bnb", "tron", "arc"]>;
         blocksSeen: z.ZodNumber;
@@ -1612,6 +1614,8 @@ declare const CheckChargeResponseSchema: z.ZodObject<{
     settledAt: string | null;
     lastActivityAt: string;
     transactionSender: string | null;
+    tokenSenders: string[];
+    userOperationSenders: string[];
     confirmationProgress: {
         network: "base" | "optimism" | "polygon" | "ethereum" | "arbitrum" | "avalanche" | "bnb" | "tron" | "arc";
         percent: number;
@@ -1698,6 +1702,8 @@ declare const CheckChargeResponseSchema: z.ZodObject<{
     settledAt: string | null;
     lastActivityAt: string;
     transactionSender: string | null;
+    tokenSenders: string[];
+    userOperationSenders: string[];
     confirmationProgress: {
         network: "base" | "optimism" | "polygon" | "ethereum" | "arbitrum" | "avalanche" | "bnb" | "tron" | "arc";
         percent: number;

package/dist/index.d.ts

@@ -1519,6 +1519,8 @@ declare const CheckChargeResponseSchema: z.ZodObject<{
     }>>;
 } & {
     transactionSender: z.ZodNullable<z.ZodString>;
+    tokenSenders: z.ZodArray<z.ZodString, "many">;
+    userOperationSenders: z.ZodArray<z.ZodString, "many">;
     confirmationProgress: z.ZodNullable<z.ZodObject<{
         network: z.ZodEnum<["base", "optimism", "polygon", "ethereum", "arbitrum", "avalanche", "bnb", "tron", "arc"]>;
         blocksSeen: z.ZodNumber;
@@ -1612,6 +1614,8 @@ declare const CheckChargeResponseSchema: z.ZodObject<{
     settledAt: string | null;
     lastActivityAt: string;
     transactionSender: string | null;
+    tokenSenders: string[];
+    userOperationSenders: string[];
     confirmationProgress: {
         network: "base" | "optimism" | "polygon" | "ethereum" | "arbitrum" | "avalanche" | "bnb" | "tron" | "arc";
         percent: number;
@@ -1698,6 +1702,8 @@ declare const CheckChargeResponseSchema: z.ZodObject<{
     settledAt: string | null;
     lastActivityAt: string;
     transactionSender: string | null;
+    tokenSenders: string[];
+    userOperationSenders: string[];
     confirmationProgress: {
         network: "base" | "optimism" | "polygon" | "ethereum" | "arbitrum" | "avalanche" | "bnb" | "tron" | "arc";
         percent: number;

package/dist/index.js

@@ -770,10 +770,16 @@ var CheckChargeRequestSchema = import_zod14.z.object({
 });
 var CheckChargeResponseSchema = ChargeSchema.extend({
   transactionSender: import_zod14.z.string().nullable().describe(
-    "The `txHash` transaction's own sender (`from`) \u2014 who actually signed and submitted it on-chain, which stays the payer's own wallet even when the transaction swaps through a router/aggregator on the way to paying, unlike the credited transfer's `from` (which can be the router/pool contract, not the payer). `null` unless `txHash`/`network` was passed in the request and a successful receipt was found for it \u2014 a hint-less background scan, an unaccepted network, or a not-found/reverted transaction all leave this `null`."
+    "The `txHash` transaction's own sender (`from`) \u2014 whoever signed and submitted it on-chain. For a wallet that signs its own transactions this is the payer, including when the payment swaps through a router/aggregator on the way (where the credited transfer's own `from` is the router, not the payer). It is **not** the payer when someone else submits the transaction on the payer's behalf \u2014 a gas-sponsoring relayer (e.g. an EIP-7702 smart account) or an ERC-4337 bundler; see `tokenSenders`/`userOperationSenders` for those. Only populated when `txHash`/`network` was passed in the request and that transaction actually paid this charge: on a `pending`/`partially_paid`/`expired` charge, a successful receipt containing at least one Transfer of an accepted token (on that network) to this charge's address \u2014 even one not yet deep enough to be credited; on an already-`confirmed`/`underpaid` charge, a transaction already credited to this charge on that network. Anything else \u2014 a hint-less background scan, an unaccepted network, a not-found/reverted transaction, or a successful transaction that never paid this charge \u2014 leaves this `null`, so it never vouches for a hash that didn't pay this charge."
+  ),
+  tokenSenders: import_zod14.z.array(import_zod14.z.string()).describe(
+    "Checksummed addresses the paying token transfers came from \u2014 the `from` of every Transfer in the `txHash` transaction that was emitted by an accepted token's own contract and sent to this charge's address (mints from the zero address excluded). Covers a wallet whose transaction was submitted by someone else, e.g. an EIP-7702 smart account paying through a gas-sponsoring relayer, where `transactionSender` is the relayer but the tokens left the wallet itself. Transfer events emitted by any other contract are ignored, since any contract can emit a Transfer-shaped event. For a swap-to-pay this is the router/pool, not the payer. Evidence, not identity \u2014 Klappay doesn't decide who the payer is. A transaction that settles several parties at once can list more than one address here if more than one of them paid this charge in that transaction, so combine it with your own per-`txHash` uniqueness. Same population rule as `transactionSender`; `[]` whenever that field is `null`."
+  ),
+  userOperationSenders: import_zod14.z.array(import_zod14.z.string()).describe(
+    "Checksummed ERC-4337 smart-account addresses (`UserOperationEvent.sender`) whose own successful user operation produced a paying transfer to this charge in the `txHash` transaction \u2014 the case where a bundler, not the account, is `transactionSender`, including an account that swapped through a router on the way to paying. Only events from the official EntryPoint contracts (v0.6, v0.7, v0.8, v0.9) count. A transfer is attributed to a user operation only when it happened inside that operation's own execution, so other, unrelated accounts bundled into the same transaction are never listed, and a transfer that can't be attributed to exactly one operation isn't listed at all. Evidence, not identity. Same population rule as `transactionSender`; `[]` whenever that field is `null`, and also `[]` for any transaction that isn't an ERC-4337 bundle."
   ),
   confirmationProgress: ConfirmationProgressSchema.nullable().describe(
-    "Present when this check found a real matching transfer on-chain that has not yet reached its network's required confirmation depth \u2014 use it to render a progress bar while waiting. `null` when nothing new was found, when the charge is already terminal (this check short-circuits with no RPC call), or once the transfer is deep enough to have already been credited (the charge's own `status` field is the signal for that, not this one)."
+    "Present when this check found a real matching transfer on-chain that has not yet reached its network's required confirmation depth \u2014 use it to render a progress bar while waiting. `null` when nothing new was found, when the charge is already terminal (no re-scan and nothing credited \u2014 at most one receipt read, only when `txHash` is a transfer already credited to it, to fill `transactionSender`), or once the transfer is deep enough to have already been credited (the charge's own `status` field is the signal for that, not this one)."
   )
 });