@rhinestone/shared-configs 1.18.0 → 1.19.0

package/dist/configs/chains.json

@@ -1657,7 +1657,7 @@
         "network": "mainnet",
         "roles": {
             "destination": true,
-            "origin": false
+            "origin": true
         },
         "settlementLayers": [],
         "stack": "vanilla",

package/dist/src/__tests__/chainVirtualization.test.js

@@ -65,18 +65,28 @@ const TRON_CAIP2 = "tron:mainnet";
         }
     });
     (0, bun_test_1.describe)("chain roles", () => {
-        (0, bun_test_1.it)("splits HyperCore by direction: Core L1 originates, venues receive", () => {
-            // Deposits arrive from the Core L1 without naming a venue; a delivery
-            // must name the account it credits. Declaring it here is what makes a
-            // perp *deposit source* unrepresentable rather than merely unimplemented,
-            // and all three ids share the `hypercore:` namespace — so a namespace
-            // switch could not draw this line at any level of effort.
+        (0, bun_test_1.it)("splits HyperCore by direction: spot both ways, perp delivery-only", () => {
+            // Declaring it here is what makes a perp *deposit source* unrepresentable
+            // rather than merely unimplemented, and all three ids share the
+            // `hypercore:` namespace — so a namespace switch could not draw this line
+            // at any level of effort.
+            //
+            // Spot originates because a HyperCore deposit already IS a spot credit:
+            // ingestion admits only an absent `destinationDex` or an explicit
+            // `"spot"`. Perp stays delivery-only — a managed account cannot sign
+            // perp→spot, so a perp deposit would strand.
+            (0, bun_test_1.expect)((0, index_1.canBeOrigin)(index_1.HYPERCORE_SPOT_CHAIN_ID)).toBe(true);
+            (0, bun_test_1.expect)((0, index_1.canBeDestination)(index_1.HYPERCORE_SPOT_CHAIN_ID)).toBe(true);
+            (0, bun_test_1.expect)((0, index_1.canBeOrigin)(index_1.HYPERCORE_PERP_CHAIN_ID)).toBe(false);
+            (0, bun_test_1.expect)((0, index_1.canBeDestination)(index_1.HYPERCORE_PERP_CHAIN_ID)).toBe(true);
+        });
+        (0, bun_test_1.it)("keeps the retiring hypercore:mainnet readable as an origin", () => {
+            // Stored `deposits.chain` rows and account rules still carry the spelling
+            // (RHI-5606). Until they are all migrated and the entry dropped, a
+            // consumer resolving one must still get an origin, or those deposits are
+            // rejected as unmapped rather than degrading quietly.
             (0, bun_test_1.expect)((0, index_1.canBeOrigin)(1337)).toBe(true);
             (0, bun_test_1.expect)((0, index_1.canBeDestination)(1337)).toBe(false);
-            for (const venue of [index_1.HYPERCORE_SPOT_CHAIN_ID, index_1.HYPERCORE_PERP_CHAIN_ID]) {
-                (0, bun_test_1.expect)((0, index_1.canBeOrigin)(venue)).toBe(false);
-                (0, bun_test_1.expect)((0, index_1.canBeDestination)(venue)).toBe(true);
-            }
         });
         (0, bun_test_1.it)("defaults both directions for chains that declare no roles", () => {
             // Absent `roles` must mean both, so adding the field is a no-op for every

package/dist/src/chainVirtualization.d.ts

@@ -13,8 +13,8 @@ export declare function canBeOrigin(chainId: number): boolean;
  * Whether funds can be DELIVERED to this chain — i.e. it is a valid intent
  * destination.
  *
- * False for `hypercore:mainnet`: deposits arrive from the Core L1 venue-agnostically,
- * but a delivery must name the account it credits, so `hypercore:spot` /
+ * False for the retiring `hypercore:mainnet`, which names the Core L1 without
+ * naming the account a delivery would credit, so `hypercore:spot` /
  * `hypercore:perp` are the only HyperCore destinations. Answering that from data
  * is what lets a consumer refuse the ambiguous id without knowing its number.
  */

package/dist/src/chainVirtualization.js

@@ -46,8 +46,8 @@ function canBeOrigin(chainId) {
  * Whether funds can be DELIVERED to this chain — i.e. it is a valid intent
  * destination.
  *
- * False for `hypercore:mainnet`: deposits arrive from the Core L1 venue-agnostically,
- * but a delivery must name the account it credits, so `hypercore:spot` /
+ * False for the retiring `hypercore:mainnet`, which names the Core L1 without
+ * naming the account a delivery would credit, so `hypercore:spot` /
  * `hypercore:perp` are the only HyperCore destinations. Answering that from data
  * is what lets a consumer refuse the ambiguous id without knowing its number.
  */

package/dist/src/chains.js

@@ -1741,7 +1741,7 @@ const chains = {
         "network": "mainnet",
         "roles": {
             "destination": true,
-            "origin": false
+            "origin": true
         },
         "settlementLayers": [],
         "stack": "vanilla",

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

@@ -1,2 +1,2 @@
-declare const PACKAGE_VERSION = "1.18.0";
+declare const PACKAGE_VERSION = "1.19.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 = "1.18.0";
+const PACKAGE_VERSION = "1.19.0";
 exports.PACKAGE_VERSION = PACKAGE_VERSION;

package/dist/src/hypercore.d.ts

@@ -20,9 +20,10 @@ export declare const HYPERCORE_PERP_CHAIN_ID = MainnetNetwork.HYPERCORE_PERP;
 /**
  * The Core L1 itself (`hypercore:mainnet`) — HyperCore as a deposit SOURCE.
  *
- * Deposits arrive here with no venue in them, which is what `deposits.chain` and
- * the QuickNode webhook already mean, so this stays a live registry entry with
- * `roles: { origin: true, destination: false }`.
+ * BEING RETIRED (RHI-5606). `HYPERCORE_SPOT_CHAIN_ID` now carries both
+ * directions and is the spelling to write; this one stays a live registry entry
+ * only while stored `deposits.chain` rows and account rules still name it, so
+ * that resolving one still yields an origin. Read it, never write it.
  *
  * It is deliberately NOT aliased to either venue for delivery: it defaulted to
  * perp, so pointing it at spot would silently move funds and pointing it at perp

package/dist/src/hypercore.js

@@ -50,9 +50,10 @@ exports.HYPERCORE_PERP_CHAIN_ID = networks_1.MainnetNetwork.HYPERCORE_PERP;
 /**
  * The Core L1 itself (`hypercore:mainnet`) — HyperCore as a deposit SOURCE.
  *
- * Deposits arrive here with no venue in them, which is what `deposits.chain` and
- * the QuickNode webhook already mean, so this stays a live registry entry with
- * `roles: { origin: true, destination: false }`.
+ * BEING RETIRED (RHI-5606). `HYPERCORE_SPOT_CHAIN_ID` now carries both
+ * directions and is the spelling to write; this one stays a live registry entry
+ * only while stored `deposits.chain` rows and account rules still name it, so
+ * that resolving one still yields an origin. Read it, never write it.
  *
  * It is deliberately NOT aliased to either venue for delivery: it defaulted to
  * perp, so pointing it at spot would silently move funds and pointing it at perp

package/package.json

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