Cashier - No-code tool to build and share web3 transactions in minutes, from your phone

Community Showcase
1

Cashier team is aiming to beta launch in June, and we’d love to hear your thoughts!

Project highlights

Cashier allows non-coders to build and share light web3 transaction pages (i.e. tips, airdrops, asset swaps, payments, gift baskets, piggy banks, donations, etc) within minutes from their phone.

40% of web3 jobs in '25 are non-code related. This indicates there are many non-tech web3 users, and much more if we include consumers. Cashier aims to empower non-coders like marketers or consumers, or even solopreneurs who are too busy to code, with a light tool to utilize web3 smart contract transactions for user engagement, fun, and payments.

Key features of Cashier are:

  • No-code UI for creating transaction pages, optimized for mobile use.
  • Library of templates for common transactions.
  • Gating mechanisms and flow customization.

Below is a GIF snippet of UX where user is claiming from a token basket:

(Please find full demo video here)

Web3 advantages

Web3 provides 3 distinct advantages for Cashier:

  • Secure and tamperproof transactions
  • Flexibility to offer diverse transaction use cases
  • Open and collaborative environments

Our aim is to build a transaction solution that mirrors users intents, not just provide simple transfers. To do that, the solution must be both flexible enough to handle forever-evolving user-level rules (validations, dependencies, gates, oracles, etc), without compromising security.

It is simply not practical, if at all possible, to do this on web2. Time, effort, resources would be exorbitantly expensive. Web2 is ok for checkout payments or bank-to-bank transfers, but nothing very flexible. On the other hand, web3 was born to handle flexible use cases with ledgers and smart contracts. We can mould transactional activities around day-to-day user needs, not the other way around.

Moreover, in the long run, we believe web3 transaction solutions will open doors for b2b collaborations that were not possible in web2. Web3 solutions run on open blockchains ecosystems that invite synergy. On the other hand, web2 solutions work behind closed walls and require complex and custom b2b integrations.

We admit aforementioned advantages really pay off once web3 transactions get mass adoption. But at the rate that financial and payment rails are converting to blockchains and stable-coins getting adoption, we believe this is a vision worth betting on. Moreover, we believe there are sufficient areas where we can add value to web3 native customers, while web3 inches towards mainstream adoption.

How is it built

Key pillars of Cashier are the link service, the frontend, and the transaction manager. What makes Cashier special is that various types of transactions are orchestrated with these three services.

1320×902 59 KB

Link service

All transactions are pre-defined in the backend in the link service, based on two contexts:

  • transaction link type (i.e. airdrop, tip, payment, etc)
  • user action (i.e. creating the tx link, using the tx link, withdrawing from the tx link)

For example, a tip link claim transaction is pre-configured as: transfer asset from link to user wallet. Whereas a invoice link payment transaction is pre-configured as: transfer asset from user wallet to the link.

The link service also handles state machines for each transaction link and for each link user.

Frontend

The frontend is merely a vessel where we collect from the users the last missing info from the pre-defined transactions above.

For example, although we pre-defined what transfers each transaction link type should make, the transaction creator must still define what assets and amount should be used. We collect this info via the frontend UI.

Transaction manager

Everything written above about how link service and frontend handle transactions are described in a chain-agnostic way. We just call these user intents.

When its time to actually execute the intents, the transaction manager uses chain adapters to assemble the relevant ICRC requests and either triggers them in the backend via the canister or in the frontend via the wallet.

The transaction manager also handles dependencies and sequencing of transactions, allowing us to create interesting transaction types. For example, we can create a transaction that sends a receipt NFT when a user sends a payment. Or we can create an exchange transaction where a user who holds a collection of rare NFTs (which may have more value sold together) can sell them together for 1000 ckUSDC. All of these transactions can be simply configured in the backend, and just require matching frontend flow.

Language, framework, tools

The frontend is built with React

  • Frontend is hosted on one canister.
  • For state management, we use Zustand.
  • For data caching, we use React Quer.
  • For handling wallet connect, we use Identity Kit.
    • For beta launch, we require users to use Internet Identity. This is because IC wallets currently do not support ICRC-112 and cannot execute batch transactions.
    • After beta, we plan to enable link users to claim or pay with other wallets, when only 1 asset is involved in the transaction.

Backend is built with Rust

  • Backend is hosted on another canister.
    • Cashier backend handles link service and transaction manager.
    • Token storage backend handles wallet store token data and cached balance.
  • For unit tests, we use faux for mocking struct.
  • For flow testing, we use Picjs.

Internet Computer superpowers

We built on Internet Computer for several reasons:

Smart contracts beyond ledgers

We needed a smart contract solution that allows us to flexibly and securely handle additional info or rules (validations, dependencies, gates, etc), not just asset transfers. Internet Computer is the only solution that allows us to implement such user-level rules, in addition to transfers, on smart contracts.

Frontend on-chain

Internet Computer uniquely allows frontend to securely run on a blockchain. Because we plan to introduce massive amounts of transaction templates, we needed a solution that would secure transactions end-to-end. Having the frontend onchain gives us a pice of mind that there are no security grey zones that can be tampered with.

Chain fusion

Our longer term vision is to support multi-chains. Once we build adapters for Bitcoin, Ethereum, or Solana, similar transaction types should be possible on respective chains. Its also not too far fetched to imagine, with the current architecture, implementing cross-chain transaction links that airdrop Bitcoin assets, but gate it with an IC NFT.

Roadmap and next steps

We have completed the foundational work and are testing several basic use case transaction templates. We aim to beta launch in June.

1920×1080 109 KB

Upcoming beta version includes:

  • Basic use case transaction templates:
    • Send tip link.
    • Send token basket.
    • Send airdrop.
    • Receive payment.
  • Relying party wallet executes transactions.

Coming in Q3~4 and beyond are:

  • Advanced use case transaction templates:
    • Swap assets.
    • Receive donations, with options.
    • etc.
  • Gating mechanisms
    • password.
    • time.
    • social accounts.
    • etc.
  • Support account delegation wallets with claiming or paying transactions with one asset.
  • NFT support: ICRC-7 and EXT.

Growth

We plan to grow by dogfooding our own product. We will experiment with different transaction links to engage with our users and either improve existing transaction templates or create new ones.

We are also eager to foster partnerships. We’d be happy to find ways to collaborate and add value to fellow dapps. Please reach out to hello@cashierapp.io if you are interested.

Development

We plan to incorporate our community feedbacks in our roadmap decisions. We value the different perspectives our community can offer, beyond what we see, hence would love to hear their thoughts on what matters or doesn’t matter to them. Please feel free to share your thoughts through this feedback form.

We also plan to grow our team to accelerate growth. We are looking for an experience backend engineer who has built complex projects. If you are interested in joining the team, please reach out to people@cashierapp.io with your resume and github. Alternatively, we’d be happy to align on bounty projects with anyone with experience with our upcoming roadmap items.

Monetization

We are building the project for profit and aim to monetize by charging modest fees to create transaction links and also from swaps in the wallet. We’d need to experiment with pricing to see how price-sensitive users are with our services.

Resources

Please see below links to some of our resources:

2 Likes