@rhinestone/shared-configs 2.11.1 → 2.12.0

package/dist/src/generated/packageVersion.d.ts

@@ -1,2 +1,2 @@
-declare const PACKAGE_VERSION = "2.11.1";
+declare const PACKAGE_VERSION = "2.12.0";
 export { PACKAGE_VERSION };

package/dist/src/generated/packageVersion.js

@@ -2,5 +2,5 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.PACKAGE_VERSION = void 0;
 // Auto-generated by scripts/generate.ts. Do not edit manually.
-const PACKAGE_VERSION = "2.11.1";
+const PACKAGE_VERSION = "2.12.0";
 exports.PACKAGE_VERSION = PACKAGE_VERSION;

package/dist/src/types.d.ts

@@ -118,6 +118,49 @@ interface TokenEntry {
      */
     nearAssetId?: string;
     unpriced?: boolean;
+    /**
+     * Whether this token may collateralise an unsponsored intent's gas refund.
+     *
+     * Opt-in and independent of every other field here: catalog membership is a
+     * routing and metadata statement, and settling a refund is a transferFrom
+     * against the account, so a fee-on-transfer or falsely-succeeding token
+     * shorts the relayer rather than the user. A token can be listed for routing
+     * and refused here, or carried here with no settlement coverage at all.
+     *
+     * A chain's native token is always eligible and needs no entry — the
+     * Paymaster settles it from a deposit rather than a transfer.
+     */
+    gasRefund?: boolean;
+    /**
+     * Whether this token may carry an app-fee carve.
+     *
+     * Same shape of assertion as `gasRefund`, different mover: the carve is an
+     * `ERC20.transfer` that runs failure-tolerantly on-chain, so a token that
+     * succeeds without moving the full amount over-credits the derived ledger
+     * that withdrawal pays out against. Opt-in for the same reason — adding a
+     * token to the catalog must not silently widen what can carry a fee.
+     */
+    appFee?: boolean;
+}
+/**
+ * A token we are willing to be PAID in that is not in the chain's routing
+ * catalog.
+ *
+ * Separate from `tokens` rather than an entry in it: catalog membership answers
+ * routing and metadata questions and is scanned on every intent, so folding
+ * these in would both make them routable and add a balance call per asset to
+ * every quote. Nothing here is a statement about routing.
+ */
+interface PaymentTokenEntry {
+    symbol: string;
+    /** EVM only — both payment paths are EVM calls. */
+    address: string;
+    decimals: number;
+    priceSymbol?: string;
+    /** See `TokenEntry.appFee`. */
+    appFee?: boolean;
+    /** See `TokenEntry.gasRefund`. */
+    gasRefund?: boolean;
 }
 /**
  * A chain's block explorer. Split into a base and paths rather than a single
@@ -379,6 +422,13 @@ interface ChainEntry {
     nativeToken: NativeTokenEntry;
     wrappedNativeToken: NativeTokenEntry;
     tokens: TokenEntry[];
+    /**
+     * Tokens accepted as PAYMENT that are not in `tokens` — see
+     * `PaymentTokenEntry`. Absent means the chain has none, not that payment is
+     * unsupported: a catalog token can opt in through its own flags, and the
+     * native token is always eligible for a gas refund.
+     */
+    paymentTokens?: PaymentTokenEntry[];
     settlementLayers: SettlementLayer[];
     settlementConfig?: SettlementConfig;
     swapQuoters: SwapQuoter[];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rhinestone/shared-configs",
-  "version": "2.11.1",
+  "version": "2.12.0",
   "description": "Reusable configuration files for Rhinestone services",
   "author": {
     "name": "Rhinestone",