Rhinestone lets you cover the fees for your users, billed to your organization monthly.
You can subsidise gas, bridge fees, and swap fees across all chains.
All projects in your organization share the same sponsorship.
Sponsorship is separate from the user’s own token balance. Without sponsorship, fees are deducted from the user’s tokens. With sponsorship enabled, the fees are billed to you instead. The user’s funds are never touched.
Fee Types
You can sponsor user fees in three ways:
- Cover the transaction gas
- Cover the bridging fee
- Cover the swap fee (when using swaps)
Sponsorship can be applied to all transactions or handled on a case-by-case basis.
You can sponsor both cross-chain and same-chain transactions.
How it Works
When your users make transactions, you can select which (if any) fees you are willing to sponsor. Rather than charging the user these costs, the Orchestrator instead adds them to your monthly sponsorship usage. Once your coverage is exhausted — for example, when you hit your monthly usage limit — fees will be applied to your users’ intents, ensuring continuity.
For any given intent, the orchestrator calculates 3 types of fees: swap, bridge, and gas. Swap fees are a fixed 50 basis point spread between the offer and ask tokens. Bridge fees are a fixed 3 basis points on the input token being bridged between chains. Gas fees are the sum of the estimated fill gas (including any deployment costs if the account is undeployed) and all claim transactions a relayer will need to execute to fulfill an intent.
When calculating the sponsored amount in USD, we take the cumulative fees that would otherwise be applied to the user and convert them to a USD value at the time of an intent.
Setup
You can test fee sponsorship on testnets out of the box.
For mainnet, save a card in Settings → Sponsorship in the Dashboard. See Billing for how sponsorship is invoiced and how to cap your monthly spend.
Usage
To sponsor a transaction:
Currently, the SDK doesn’t provide any policies out of the box. You can implement bespoke, flexible policies on your backend.
Here’s one example, where we only sponsor transactions that interact with a specific contract:
You can then use that function when handling the user’s transaction request: