Blinks on Sui

You are learning a move

No active mission. Use this page to improve one real decision; reading alone is not proof.

Which controls must a Sui transaction link expose before a person can inspect, approve, and execute it safely?

A blink is a URL that encodes a Programmable Transaction Block (PTB). Share it anywhere a link can go — social post, email, QR code, physical tag. The recipient clicks, sees a transaction modal, approves, and the transaction executes. No app download. No separate wallet setup beyond the initial one-time step.

The Solana Origin

Solana introduced this pattern as Actions and Blinks in 2024. A blink URL resolves to a JSON spec describing the transaction. Wallets parse the spec and render a standard UI. The transaction executes without the user navigating to a dApp.

The key insight: if every link can carry a transaction, then every platform that carries links becomes a transaction surface. X posts, Discord messages, Telegram links — all become points of financial interaction.

Sui Equivalent

Sui's PTB model maps directly to this pattern:

Concept	Solana	Sui
Transaction encoding	Action JSON spec	PTB params in URL or QR
Atomicity	Transaction	PTB (up to 1,024 ops, ~390ms)
Wallet render	Blink UI (wallet extension)	dApp Kit transaction modal
Sponsorship	Relayer (optional)	Sponsored tx (native)
Onboarding	Existing wallet required	zkLogin — OAuth → address

Sui's advantage: sponsored transactions mean the platform pays gas, and zkLogin means users don't need a pre-funded wallet. A new user can click a blink, sign in with Google, and execute a transaction in a single flow.

How It Works

1. Encode PTB as URL parameters
   ?module=link&fn=createLink&creator=0xABC&platform=p1&reward=100

2. User clicks link (social, email, QR code, NFC tag)

3. dApp Kit renders transaction modal
   Shows: what the transaction does, gas cost, expected result

4. User approves
   With existing wallet OR via zkLogin (OAuth flow)

5. PTB executes on-chain (~390ms)
   Events emitted. State updated. Attribution recorded.

The user never visits a dApp directly. The transaction comes to them.

Attribution × Blinks

The intersection that makes this architecturally significant: a blink URL IS an attribution event.

When the link module creates a link object, it records the genealogy — who created it, who shared it, which platform carried it. Every blink share is a link creation. Every blink click is a potential conversion event. The collision module scores quality to prevent spam.

Creator mints content → generates blink URL
Sharer posts URL → link object created on-chain
Buyer clicks → transaction executes
Attribution automatically recorded → revenue splits run

No centralized affiliate platform. No cookie tracking. Purely on-chain attribution from the moment the URL is shared.

PTB Construction

// Encode blink action
const blinksUrl = new URL(`${APP_BASE}/action`);
blinksUrl.searchParams.set("module", "link");
blinksUrl.searchParams.set("fn", "createLink");
blinksUrl.searchParams.set("creator", creatorAddress);
blinksUrl.searchParams.set("platform", platformId);
blinksUrl.searchParams.set("reward", rewardAmount.toString());

// On click — decode and construct PTB
const tx = new Transaction();
tx.moveCall({
  target: `${LINK_PKG}::link::create_link`,
  arguments: [tx.object(platformId), tx.pure.address(creatorAddress), tx.pure.u64(rewardAmount)],
});

// Platform sponsors gas — user never holds SUI
const { digest } = await sponsoredExecute(tx, userAddress);

Use Cases

Use case	What the blink encodes	What executes
Content attribution	link::createLink	Records referral, sets reward
Prediction bet	prediction_game::placeBet	Stakes tokens, records position
NFT purchase	kiosk::purchase	Transfers object, pays creator royalty
Device registration	device_registry::register	Mints device identity object
Loyalty redemption	loyalty::redeem	Burns points, delivers reward

Physical Tags

Blinks extend to physical space. A QR code is a blink. An NFC tag is a blink. A product label, a venue entrance, a machine — any surface that can carry a URL can carry a transaction.

Physical DePIN applications: a device scans a QR code to register on-chain, an installer taps an NFC tag to provision a sensor, a farmer scans a field marker to log an observation. The device_registry module's state machine transitions map directly to blink-triggered events.

Limits, checks, and failure modes

• A URL transport does not prove consent, beneficiary value, correct attribution, or a legitimate standard decision.
• Reject a blink when the recipient cannot inspect the exact transaction, signer, object permissions, sponsor, expected state change, and failure path.
• Treat replay, link substitution, stale object state, malicious sponsorship, wallet rendering differences, and inaccessible approval flows as design failures.
• Keep participant refusal and stop authority outside token ownership or transaction success.

Proof of done

The concept is ready for a bounded implementation test when a cold participant can inspect, refuse, or execute one PTB from the link; reconstruct the resulting state and attribution receipt; and distinguish transaction completion from the later beneficiary outcome.

Context

• Regenerative Standards Economy — Sui Blinks are a possible transport and settlement mechanism for consented commitments and receipts, not evidence that the economy exists or authority to revise its standards.
• Intelligent Hyperlinks — Three generations of the same invention
• Sui Development — PTB construction and what we've built
• Solana Blinks — The origin pattern
• Sui Standards — PTBs, zkLogin, sponsored transactions

Links

• Mysten Labs Blinks Discussion — Community conversation
• Solana Actions Spec — Origin pattern reference
• dApp Kit Transaction Modal — The render layer

Questions

Changes my mind: a bounded test shows that the blink transport cannot preserve inspectable consent, safe refusal, correct state transition, and reconstructable receipts across supported wallets.

Next question: Which single PTB is valuable enough to test without treating transaction completion as outcome proof?

If every link on the internet became a potential transaction entry point — what does that do to the incentive structure of sharing?

• What stops blink spam when anyone can create attribution links?
• If the link IS the contract, who owns the relationship — the creator, the sharer, or the platform?
• At what point does on-chain attribution become more trusted than first-party analytics?