✅ Pay with $SAND - A mini-SDK for any website or dApp

Pay with $SAND

A mini-SDK for any website or dApp


1. Executive Summary

  • A simple “Pay with $SAND” button that any website can drop in next to “Pay with PayPal”.
  • When someone clicks it, a small pop-up asks them to confirm; seconds later the seller receives their $SAND.

Why it matters for The Sandbox

  • Gives $SAND real-world use outside the game: tipping streamers, buying merch, donating to creators.
  • Every payment is recorded on the blockchain, so results are transparent and easy to track.
  • What@sandbox/pay-with-sand, an npm package exposing
    payWithSand({ amount, orderId })
    useSandPaymentStatus(orderId)
    
    plus an optional PaymentGateway contract that logs each sale on-chain.

2. Problem Statement

Issue Effect
Each partner hand-codes approve + transfer flows Friction, errors, two signature steps
No standard “receipt” on-chain Hard to reconcile sales or split revenue
$SAND mostly stuck in-game Missed adoption opportunities in Web 2/Web 3 apps

3. Proposed Solution

Aspect Details
Package @sandbox/pay-with-sand (TypeScript / React)
Flow One click → EIP-2612 permit → single tx → PaymentDone(orderId, payer, amount)
Tech Solidity ^0.8, wagmi v1, RainbowKit
UX Modal theming, i18n, webhook callback for partner back-ends
Future-proof Contract ready for splits (90/10), refunds, NFT receipt later

3.1 End-to-End Flow

  1. User click → site calls the SDK.
  2. SDK opens a wallet modal (RainbowKit / WalletConnect).
  3. User signs one EIP-2612 permit + pay transaction.
  4. PaymentGateway.sol
    1. pulls the $SAND with transferFrom,
    2. emits PaymentDone(orderId, payer, amount),
    3. (optionally) forwards or splits the funds.
  5. A webhook service listens to the event and notifies the merchant backend.
  6. Backend unlocks the item / credit and returns “confirmed” to the front end.
  7. Front end shows “Payment confirmed” to the user.

4. Team

Name Role Experience
Gerald Kodjo Q. Aka NovaTheMachine Lead Solidity / Front-end Alchemix Loan to card , BlazerJob NPM package Nova - Google Docs

5. Technical Details

  • Standards – ERC-20 $SAND + EIP-2612 .
  • ContractPaymentGateway .
  • Infra – Alchemy RPC, Node/Express webhook, Storybook docs.
  • Sandbox tie-in – Same button can power in-world shops via an iframe.

6. Budget & Work Plan

Category Days Amount (USD)
Solidity & tests 15 4 500
React SDK 10 3 000
Webhook & docs 3 900
External audit 3 000
PM / buffer 15 % 2 435
Total 28 14 835 USD

Milestones

# Deliverable ETA Budget release
1 Test-net contract + unit tests W 3 25 %
2 npm package v0.1 + Next.js demo W 5 35 %
3 Audit fixes + main-net deploy W 6 40 %

7. DAO Alignment & KPIs

  • Decentralisation – single audited gateway, open-source repo.
  • Creator empowerment – any streamer or shop can accept $SAND instantly.
  • Interoperability – works on every EVM chain.
  • KPIs – tx count & total $SAND through gateway, npm installs, unique integrators.

8 User Flow

  1. User clicks the “Pay with $SAND” button.
  2. The modal appears, showing amount & network as before.
  3. Within the modal the user chooses a wallet:
    • Clicking MetaMask opens the browser extension popup to connect/sign in.
    • Clicking WalletConnect swaps in a QR code to scan with a mobile wallet.
  4. Once connected, the “Confirm & Pay” button becomes active – the user signs the transaction .
  5. The modal displays “Processing on-chain (tx hash…)” until confirmed .
  6. On success, a green checkmark and “Payment confirmed” appear, with an optional link to Polygonscan.
  7. On failure or user rejection, a red toast shows the error .

9. Pay WIth $SAND VS ThirdwebPay

Strategic goal for the Sandbox ecosystem Thirdweb Pay delivers… Pay-with-SAND delivers… Why the DAO cares
Make $SAND the default currency, not “just another ERC-20” $SAND appears as a custom token and is usually swapped to USDC before settlement. $SAND is the hard-wired, only currency; no swap, no dilution. Every transaction reinforces $SAND’s network effect instead of routing value into stable-coins.
Friction-free UX 2–3 signatures (approve → swap → pay) → high drop-off. One signature (permit + pay) → lower abandonment, better first-time experience. Less friction = more completed sales, more real users holding $SAND.
Zero intermediary fees so value stays with creators 0.3 % platform fee + DEX spread. 0 % protocol fee; only gas . Creators keep every token; higher earning potential attracts more builders.
Sandbox branding everywhere $SAND is spent Neutral Thirdweb UI, no Sandbox colours. Modal uses official palette & fonts. Strengthens brand consistency and keeps players inside the Sandbox visual universe.
Governance under the DAO, not a private SaaS Code, pricing and roadmap controlled by Thirdweb Inc. Contract & SDK open-source, upgradeable by Sandbox DAO. The community not a third party owns the payment rail and future .
On-chain metrics that are easy to follow Payments are routed and sometimes swapped, obscuring true $SAND volume. Every payment emits PaymentDone with clear $SAND amounts. Transparent KPI dashboard = simple tracking.

Thirdweb Pay is a fine generic checkout; Pay-with-SAND is purpose-built for our token, zero-fee, single-click, Sandbox-branded, and governed by the DAO not a SaaS provider.

Discovery: Heard about the Sandbox DAO Grants via Questbook.

Hi NovaTheMachine,

It’s not clear to me how your solution works. Could you please provide many more details about it, and share information such as your portfolio, social media, and LinkedIn to verify your experience?

Regards,

Detailed Proposal for Pay with $SAND

Hi Yuelwolf, thank you for reviewing my application.
Below you’ll find a deeper dive into how the solution works, plus my professional background and public links for verification.

Hello @NovaTheMachine

Please edit the original post so we have the project more organized and don’t create a new post for each update. Tag me once you’ve made the changes. The way you’re presenting the information is confusing to me, as I see two different portfolios and people. Additionally, the proposal is still unclear. You’re talking about a one-year roadmap with integrations across a large number of ecosystems, which doesn’t align with the milestones in the initial proposal. I need a clear roadmap and corresponding milestones so we can evaluate the proposal.

Hello @yuelwolf

NovaTheMachine is simply my dev handle , my real name, Gérald , is on the GitHub and LinkedIn , so it should be clear we’re talking about one person.

The forum is limited to two links, so i used a google drive.
As for the timeline, the one-year roadmap was explicitly labelled “future vision”; the grant request itself is limited to the three milestones .

Hello @NovaTheMachine ,

Thanks for the clarification! I’d like to dive a bit deeper into how you envision the user experience. Any UI sketches would also be very helpful to see how this mini-SDK would function when integrated into a web page.

1 Like

Hi @yuelwolf,

I’ve just updated the proposal with a user flow and embedded the actual Pay-with-SAND modal UI sketch. Let me know if you’d like any tweaks or more context!

1 Like

What differentiates or what is the value proposition of this mini-SDK compared to other existing solutions in the market, such as Thirdweb Pay, among many others that already offer ready-to-integrate payment systems?

Hi @yuelwolf I’ve updated the proposal !

If I understand correctly, you are proposing a kind of user-customizable API, is that it?

Yes that’s it

1 Like

I love the idea.
Is it something upgradable/customizable ? I mean adding other features/tokens in the futur?

Thanks for the support @sebga i appreciate. yes , contract, UI, and SDK are all designed to be upgraded or extended; today it’s 100 % SAND, tomorrow we can toggle on additional tokens or features with a DAO-approved upgrade .

1 Like

The most important point remains security.

I agree that security is extremely important, I’ve thought about it from the beginning, that’s why I’ve planned a security audit. If that’s one of your questions, the smart contract and the code won’t be modifiable without us realizing it, there’s little chance that attacks will come from there. From the smart contract point of view, I’ve done everything to reduce the attack surface, there will be one or two public functions and the contract will not store tokens.

1 Like

Hello Nova,

Which entity would be responsible for auditing the contract?

1 Like

I think the best solution is to use audit competition platforms like Code4Rena, because companies like certik or openzepplin are overpriced

1 Like

Hello Nova,

I’ve been reviewing the contract auditing process, and unfortunately, I found that on platforms like Code4rena, the rewards are quite high to attract Wardens to review the contract. This means $3k would likely be insufficient to get a quality review on such platforms.

I suggest two alternatives: either look for an option that fits the budget on other platforms or with verified professionals, or change the project’s approach to use a third-party contract that guarantees security.

Hi @yuelwolf

Good news on the audit front:

Hashlock.com has agreed to audit our gateway for $3 k , they normally quote $5 k minimum.

In parallel, I’ve lined up an extra pass from independent warden Jacobo Lansac (GitHub → GitHub - JacoboLansac/audits) for €500.
That second review gives us another set of eyes without blowing the budget.

With those two layers we stay within the original $3 k envelope yet still get a recognised firm plus a seasoned warden on the code. Let me know if that satisfies the security requirement or if you’d like me to explore further options.

Hello @NovaTheMachine

Great news. I will evaluate your project and return ASAP.

1 Like