Rendering Blinks via Interstitial URLs
In this section we cover Option 3 above in more detail, as it is the pure URL-encoding of the full experience: specifying both an action and the client in which it is to be executed.
Interstitials—
Interstitial URLs are website or mobile app deep link URLs specifying a client in which to sign for an action. Examples include wallets or other wallet-related applications that are typically responsible for storing keypairs, and that are capable of giving user signing experiences.
Any signing client can implement an interstitial site for execution, and developers and users can compose interstitials and actions as they see fit. We describe some examples in the next section.
User journeys—
Alice is using Jupiter to swap tokens. She chooses the paying & receiving tokens, say SOL & WIF. Near the Swap button is another button she may press, that allows for sharing the action with others.
When she presses it, she is presented with a sheet in which she can choose the signing client. It’s a CTA like “Sign with…” and then a grid of well-known wallets or key holding apps like Phantom, Backpack, Solflare, Tiplink, etc.
Once she chooses one, say Backpack, it copies to her clipboard a URL of the format https://backpack.app/?action=solana:<swap-url>
Determining interstitials—
Note that in the above example, jup.ag’s interface gives Alice choice for the interstitial, not the blink itself. When Bob taps Alice’s choice for backpack, he is taken to Backpack.
💡 If for example Dialect chose to implement an interstitial-choosing step at https://dialect.to/?action=… —where a user chooses which signing client to use—Backpack, Phantom, etc.—then this is an entirely different abstraction than an interstitial URL, and not a part of the official Blink implementation.
Last updated
