For builders

Drop purpose-bound gifting into checkout — or give an agent a budget it can't overspend.

rice.gift is one primitive for two surfaces: ecommerce gifting and agentic commerce. Spend caps and allow-lists are enforced on-chain, so the rules hold no matter who's spending.

What you get

One integration for both human checkout and agent-driven spend.
On-chain guardrails — spend caps and merchant allow-lists are part of the asset, not your app logic.
Sui-native rails — sealed codes, sponsored gas, and zkLogin onboarding out of the box.

The two rails

Vouchers (permissioned)

A balance scoped to a merchant, in local currency, fully backed by USDC. Redeem is closed-loop.

Sealed codes

A code encrypted so only the recipient can unseal it; redemption is recorded on-chain.

Give an AI agent a budget object instead of raw keys. It can spend only at the merchants you allow, up to the cap you set — enforced on-chain at redemption, so a misbehaving agent can't overspend or cash out.

// Illustrative: issue a capped, merchant-scoped gift for an agent to spend.
const gift = await riceGift.issue({
  rail: "voucher",
  merchant: "may-pharmacy",
  amountLocal: 42_000,      // MMK the recipient receives
  fundedWith: "USDC",       // you pay in stablecoin
  recipient: agentAddress,  // a zkLogin / agent identity
});
// The agent can redeem at `may-pharmacy` only — never elsewhere, never as cash.

Closed-loop by design

There is no function that pays a holder arbitrary cash. The only exits are redeem → the scoped merchant, or refund → the original funder. Build on that guarantee instead of re-implementing it.

Onboarding & gas

zkLogin turns a social login into a wallet — no seed phrase for your users.
Sponsored gas means recipients never need to hold SUI to open or spend a gift.

Back to overview

The two rails and how a gift flows end-to-end.