Sui's gas sponsorship is mature at the protocol level, but the three questions of "who pays, how they pay, and how much they pay" need to be handled separately. The easiest approach is to use a ready-made Gas Station service such as Shinami or Enoki, leaving budget control and abuse prevention to the provider. If you build your own, the core risk is not in the signing step. It is what happens after you sign: a user takes the transaction you sponsored and does something you did not approve.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
First, understand: gas sponsorship and gas-free transactions are two different things
Sui currently offers two ways for users to avoid paying gas, and they suit different situations.
Sponsored Transaction: As the sponsor, you use your own SUI to pay gas for the user's transaction. The user still needs to build the transaction, but does not need to hold SUI. This works for any scenario where you want to subsidize user operations, such as a new user's first swap, in-game actions, or a business reimbursing transaction fees for employees.
Gasless Stablecoin Transfer: This is a protocol-level feature limited to whitelisted stablecoins such as USDC and USDsui for peer-to-peer transfers. The amount must be at least 0.01, and the transaction must fully consume or convert the tokens involved. No one needs to pay gas, including you. If your use case is exactly a stablecoin transfer, use this first. It costs nothing and carries no sponsor fund risk. But its scope is narrow: complex operations, non-whitelisted tokens, and amounts below the threshold are not supported.
Signature flow: who signs first determines your risk exposure
The signature structure of a sponsored transaction requires both the user and the sponsor to sign the same complete TransactionData. The signing order does not matter, but GasData must be included. The two construction methods carry different risks:
User builds first, you sign later (common for user-initiated actions): The user first builds GasLessTransactionData, which is the transaction body without gas information, and sends it to you. You check what the transaction will do, confirm it is within the allowed scope, fill in your own gas object, sign it, and send the signed complete transaction back to the user. The user then signs and submits it. The key risk here is that you must verify the transaction content before signing. If you sign without checking, the user can call any function in the transaction, including transferring assets out of your own wallet if that function happens to require your signature authorization. Sui's documentation clearly states that sponsors should "inspect the transaction and verify that it is within the scope of your approved application."
You build first, user signs later (common for reward claims and promotions): You build a transaction containing the specific operation and gas data, sign it first, and then send it to the user through email, SMS, or the app interface. The user checks it, signs it, and submits it. This method gives you control because you decide the transaction content. The risk is that the user may not sign, and your prepaid gas object remains locked until the transaction expires.
At the SDK level, onlyTransactionKind: true is used to strip gas information so the sponsor can fill it in later. The sponsor uses setGasOwner to set their own address as the gas owner. Then both parties sign separately, and two signatures are passed when submitting.
Budget control: set it in three places, not just by checking bills afterward
Per-transaction limits in each Gas Station service. Third-party services usually provide automatic budgeting or manual settings. If Shinami's Gas Station request does not specify gasBudget, it uses the automatic budget feature. Enoki allows you to configure per-transaction or per-user gas limits in the developer dashboard. If you build your own, you must explicitly set gasBudget in the SDK's GasData. Do not leave it empty or give an overly large default value. The actual gas consumption of a transaction may be far below the budget, but a maliciously constructed transaction can deliberately burn up to the budget limit.
Total consumption limits over time. Per-transaction limits cannot stop high-frequency abuse. You need to set cumulative limits by user address and time window, such as hourly or daily. Shinami provides filterable usage metrics so you can view spending over time and adjust your sponsorship strategy. Enoki also has monitoring in the Developer Portal. If you build your own, at minimum you should record each address's sponsorship count and amount on the server side and reject requests once the threshold is exceeded.
Lifecycle management of gas objects. If you use a specific SUI coin object as gas instead of an address balance, and that coin is used for sponsorship but the transaction does not go on chain, the coin cannot be used by other transactions before it expires. Shinami's sponsorship uses a one-hour expiration time by default. You need to monitor unspent sponsored transactions to avoid having many coins locked by invalid requests, which would drain your available gas pool.
Abuse prevention: verifying transaction content matters more than rate limiting
Rate limiting can stop script kiddies, but it cannot stop a carefully crafted malicious transaction. The core protection is parsing and verifying transaction intent before signing.
If you offer a "user proposes, you approve" model, check at least three things:
Whitelist the target addresses of Move calls. Only sponsor transactions that call contracts you deployed or contracts you trust. A user-built transaction can contain any
moveCall. If you do not restrict the target, the user can call a sensitive function that uses you as the sender or gas owner.Check whether the transaction references
tx.gas. If the user's transaction body contains operations such assplitCoins(tx.gas, ...), it means the user is trying to split funds from your gas coin. Some Gas Station libraries have anallowGasCoinUsagepolicy switch for this, and it should be disabled by default.Minimum payment or interaction requirements. If your scenario is that the user pays a certain token and you subsidize gas, you can set
minRequiredPaymentin the sponsorship policy. Transactions below the threshold are rejected directly, blocking requests that only try to farm gas. You can also useallowedReceiversto only sponsor transactions that pay to addresses you specify.
When building your own service, a useful protection architecture is: receive the user's kind bytes → parse the transaction → check whether the moveCall target is on the whitelist → check whether it references tx.gas → check whether the sender address is on the allowlist → check that address's cumulative daily consumption → if it passes, fill in gas and sign and return, otherwise reject.
When to use a third-party service and when to build your own
Use a third party such as Shinami or Enoki: Your team does not have dedicated staff to maintain gas infrastructure, or you want to launch as soon as possible. Shinami bills in SUI because its operating costs are mainly SUI, and it provides detailed spending metrics and Gas Station status queries. Enoki supports fiat billing. If you do not want to hold and manage SUI, this route is more direct. The main tradeoff between the two depends on your financial preference: hold SUI in exchange for more detailed metrics, or use fiat in exchange for less hassle.
Build your own: Your sponsorship logic is deeply tied to your business, and the generic policies of third-party services are not enough. Or your volume is large enough that third-party service markups are not cost-effective. The cost is that you need to implement all the verification and rate limiting logic above yourself, and manage gas coin replenishment and expiration.
Definition of done
It is not "the user successfully submitted a transaction for which you paid gas." Instead, it is: over a period of time, your sponsorship spending relative to business goals such as new user activations, transaction count, or stablecoin transfer volume stays within an acceptable range, and there is no record of an unapproved moveCall being sponsored on chain. If you only look at whether the transaction succeeded, you may be paying for someone else's arbitrage or spam transactions. Run a small-amount sponsorship for one week first, pull the target and actual gas consumption of every sponsored transaction, confirm there are no abnormal calls, and then gradually open up the budget.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
