Why Photon?

Photon exists because the hardest part of putting users on chain is rarely your contract logic. It's the two problems that sit in front of it: users who hold no gas, and the operational plumbing of getting transactions reliably mined.

Both are sharpest on Hyperliquid: HyperEVM users still need HYPE for gas, and HyperCore actions need careful signing. Photon sponsors the first and forwards the second, and its gasless smart accounts turn a HyperEVM account into a single-signature gateway to Core. See Hyperliquid on Edith.

The cold-start problem

A new user signs up for your app. Before they can do anything on chain — mint, claim, vote, transfer — they need the chain's native token to pay gas. Which means an exchange account, a KYC flow, a purchase, a bridge, a wallet top-up. For a user who just wanted to press one button in your product, that's not friction; it's a cliff. Most never come back.

Gas sponsorship removes the cliff. With Photon, the transaction your product needs is executed by Photon's relayer, which pays the gas in the native token. Your user needs no balance at all, on any chain. You settle the cost from a prepaid USD balance on your Photon account — a predictable line item, denominated in a currency your finance team understands, instead of a per-user, per-chain token logistics problem.

The plumbing problem

Even with funded users, running your own transaction pipeline means owning a stack of unglamorous machinery: a hot wallet and its key security; nonce sequencing under concurrency; fee estimation across chains with different fee markets; detecting stuck or dropped transactions; retrying with backoff without double-spending; and monitoring all of it. Every team that builds this builds roughly the same thing, and the failure modes are subtle — a single nonce gap can silently wedge everything behind it.

Photon is that machinery as an API. One POST with intent — to, callData, chainId — and the signing, pricing, broadcasting, retrying, and notifying are handled for you. The overview describes the moving parts.

What sponsorship changes for product UX

When gas disappears from the user's side of the interaction, on-chain actions stop being a separate, ceremonial flow and become ordinary product features:

• Onboarding collapses to your own signup. The first on-chain action can happen seconds after account creation.
• Actions become one-tap. No "insufficient funds for gas" dead-ends, no interrupting a flow to send the user off to acquire tokens.
• Multi-chain stops mattering to users. Your product can act on whichever chain is right for the feature; the user never learns which token pays for what.
• Costs become yours to shape. Sponsoring is a pricing decision — absorb it, bundle it into a subscription, or cap it per user with spending limits — rather than a burden pushed onto each user.

When not to use Photon

Sponsorship is a tool, not a default. Skip it when:

• Your users are already funded and self-sufficient. If your audience is DeFi-native and comfortably pays its own gas, a relayer in the path adds a hop without adding value. Let their wallets submit directly.
• The transaction must originate from the user's own address. Photon's relayer is the on-chain sender for standard sponsored transactions. Protocols that key behavior to msg.sender won't see your user. EIP-7702 authorizations and funding-signed transactions — where Photon tops up the user's address and broadcasts a transaction they signed — cover many of these cases, but if neither fits, direct submission is the honest answer.
• You need custody of the signing key. Photon signs sponsored transactions with its own relayer keys. If your compliance or custody model requires that every signature come from a key you hold and control, a relayer that signs on your behalf is the wrong shape regardless of how well it works.

If you're still reading, the quickstart will have you relaying a sponsored transaction in a few minutes.