solana-studio 0.9.0 → 0.9.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0e0ff18e6789fde7b36cbf2d6c29fcce763fca5c278e3b36dbf36bd8dd792df4
-  data.tar.gz: 2e6867b16a35325e78c791e96ea909b93251428d1233dd9efb19fa938ab6106f
+  metadata.gz: a00c3f09eb98073668c9218045e49e705be6e803348ad9338e4295d32ca7c091
+  data.tar.gz: 16189d3a834e1880bbba0b37113823fdf95d4a690926d98f67120213818b70db
 SHA512:
-  metadata.gz: 908f0395ddc2ee1f56133a5ec474a67d1494cd726dde4a15c6d4c0172edab971db6ba699894e298439a028cb7e7dd8a475127079ae90de41f27a8bac6a4c9838
-  data.tar.gz: d7562cb9adac4442d8853d368b9c5cc59c85158f96103a9cf5ee6192657bf9da6cde560f5e541fe1addbc26bf45d8549370fc6790b7a4d20a0fcb5cefac4db29
+  metadata.gz: 43e0a031a5fb9c2bcb451c4bddcf2df0e79a1c1722c60e57e9fcd302699434736bf363dd12a6f1ee7f847f447a1b3aeb792e557a7874edc419714a66a9a8b094
+  data.tar.gz: 8613a4f8bcead4253fb9b1814b1fbb008d9d1f9c3db4e1e8be33b5ca5fc005ce2b7b4226f136454a52f4ef66ccec59c22cf968d6f78762558e51355a2e2de056

data/app/assets/javascripts/solana_studio/wallet_ops.js

@@ -11,11 +11,22 @@
 //
 //   walletOps.define('contest_entry', {
 //     prepare:  function (ctx) { ... return { transaction: <base58>, ...state }; },
-//     complete: function (ctx, result, state) { ... }
+//     complete: function (ctx, result, state) { ... },
+//     signOnly: true
 //   });
 //
 //   walletOps.run('contest_entry', { contestId: 12 }, { provider: ... });
 //
+// `signOnly` IS A REQUIREMENT OF THE TRANSACTION, NOT A PREFERENCE ABOUT THE
+// WALLET, and it is the intent's to declare because only the intent knows the
+// shape of the bytes it prepared. A CO-SIGNED transaction — one whose second
+// signer slot is deliberately empty because a server fills it — cannot be
+// broadcast by the wallet: the chain would reject it for a missing required
+// signature, and, worse, the signed bytes the server needs would never come
+// back to the app, so the flow fails with nothing to retry. Declaring it makes
+// the transaction's own requirement outrank the wallet's capability. Omit it
+// and nothing changes: a wallet that can broadcast still does.
+//
 // THE ONE RULE A CALLER MUST FOLLOW: handlers are registered BY NAME at page
 // load, not passed as closures. A closure is precisely what cannot survive the
 // redirect — the page that held it no longer exists when the wallet answers. The
@@ -30,7 +41,8 @@
 // WHAT THIS FILE DOES NOT DO: it does not broadcast. Signing and sending are
 // different responsibilities with different failure modes, and the wallet that
 // broadcasts differs per vendor (Phantom deprecated its send-side deeplink, so
-// the app sends; Solflare and Backpack send for you). `complete` is told which
+// the app sends; Solflare and Backpack send for you) — and, where the intent
+// declares `signOnly`, per TRANSACTION as well. `complete` is told which
 // happened and owns the RPC, exactly as the existing flows already do.
 (function (W) {
   'use strict';
@@ -107,6 +119,23 @@
     return Promise.resolve(handler.prepare(ctx)).then(function (prepared) {
       var intent = { op: name, ctx: ctx, state: prepared };
 
+      // THE DECLARATION TRAVELS IN THE JOURNAL, NOT LOOKED UP FROM THE HANDLER
+      // AT THE FAR END, and that is the whole reason this line exists here
+      // rather than inside signingHop. The signing hop is taken from TWO
+      // places: this one, where the handler is certainly registered, and the
+      // connect callback, which is a DIFFERENT PAGE that may not have loaded
+      // the script that defined this intent. A handler lookup there would come
+      // back empty and silently fall through to the send-side default — the
+      // exact branch a co-signed transaction must never take. A boolean on the
+      // intent is JSON-serialisable, which is the one thing this file requires
+      // of anything that has to survive a redirect.
+      //
+      // Set ONLY when true, so the journal an undeclared intent writes is
+      // byte-identical to the one it wrote before this option existed. That is
+      // also why JOURNAL_VERSION does not move: no reader's expectations
+      // change, and bumping it would strand every trip already in flight.
+      if (handler.signOnly) intent.signOnly = true;
+
       // Already connected? Go straight to signing. Otherwise connect first and
       // carry the intent through — sessions do not expire on any of the three
       // wallets, so this branch is taken once per user, not once per action.
@@ -145,18 +174,38 @@
     return signingHop(provider, connected, opts);
   }
 
-  // Which signing method this wallet gets is a CAPABILITY QUESTION, not a
-  // preference: Phantom's send-side deeplink is deprecated, so it signs and the
-  // app broadcasts. Asking the provider keeps that fact in the profile table
-  // where it is asserted, rather than branching on a wallet name here.
+  // Which signing method this wallet gets is TWO questions asked in order, and
+  // the order is the point.
+  //
+  // FIRST, what does the TRANSACTION allow? A co-signed transaction has an
+  // empty signer slot the server fills, so the wallet must sign and hand the
+  // bytes back — broadcasting it is not a worse option, it is a broken one.
+  // An intent that knows this declares `signOnly` and that answer is final.
+  //
+  // SECOND, and only for everything else, what can the WALLET do? Phantom's
+  // send-side deeplink is deprecated, so it signs and the app broadcasts;
+  // Solflare and Backpack broadcast for you. Asking the provider keeps that
+  // fact in the profile table where it is asserted, rather than branching on a
+  // wallet name here.
+  //
+  // Asking them the other way round is the bug this replaced: capability alone
+  // sent every co-signed transaction to the wallet's broadcaster on any wallet
+  // that had one.
+  //
+  // A wallet with no signTransaction at all would be refused BY NAME by the
+  // provider's own capability gate rather than quietly broadcast here. No
+  // profile is in that state today (all three sign), and this is the branch
+  // that would have to be revisited if one ever were.
   function signingHop(provider, journal, opts) {
+    var intent = journal.intent;
     var payload = {
       journal: journal,
-      transaction: journal.intent.state.transaction,
+      transaction: intent.state.transaction,
       redirectLink: opts.redirectLink,
-      intent: journal.intent
+      intent: intent
     };
-    return provider.can('signAndSendTransaction')
+    var signOnly = !!(intent && intent.signOnly);
+    return (!signOnly && provider.can('signAndSendTransaction'))
       ? provider.beginSignAndSendTransaction(payload)
       : provider.beginSignTransaction(payload);
   }
@@ -234,6 +283,18 @@
       if (!handler || typeof handler.prepare !== 'function' || typeof handler.complete !== 'function') {
         throw new Error('walletOps.define("' + name + '") needs both prepare and complete');
       }
+      // REFUSED RATHER THAN COERCED, because every wrong answer here fails in
+      // the dangerous direction. A typo'd `signOnly: 'true'` read as truthy
+      // would sign-only a flow that wanted the wallet to broadcast; read
+      // strictly, it silently sends a co-signed transaction to a broadcaster.
+      // Neither is discoverable at the call site, and both surface as a chain
+      // error one page death later. So the option is a boolean or it is a bug.
+      if (handler.signOnly !== undefined && typeof handler.signOnly !== 'boolean') {
+        throw new Error(
+          'walletOps.define("' + name + '") signOnly must be true or false, got ' +
+          typeof handler.signOnly
+        );
+      }
       handlers[name] = handler;
     },
 

data/lib/solana_studio/version.rb

@@ -16,5 +16,5 @@ module SolanaStudio
   # through the normal cycle. Splitting the version out is the same shape
   # studio-engine already uses (lib/studio/version.rb) and hands each file back
   # to its real owner: this one to the release, the gemspec to the PR.
-  VERSION = "0.9.0"
+  VERSION = "0.9.1"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: solana-studio
 version: !ruby/object:Gem::Version
-  version: 0.9.0
+  version: 0.9.1
 platform: ruby
 authors:
 - Alex McRitchie
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2026-09-08 00:00:00.000000000 Z
+date: 2026-09-09 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: ed25519