[xGov-3244303791] - BubbaPay: send ASAs to anyone with a claim link

Governance Discussions xGov Proposals
1

Hi all,

Hereby submitting my BubbaPay proposal for discussion.

About:

BubbaPay is an Algorand dApp that lets users send any ASA with a claim link - no address from the recipient needed. After setting up and funding an escrow, you can share the link directly via WhatsApp or Telegram with one click.

How It Works:

You specify the ASA, amount, and whether you’d like to include “fee coverage”, which is useful if the recipient doesn’t have an Algorand wallet yet and would need to opt-in.

The flow is simple:

  1. Deploy the App.
  2. Sign a second transaction that funds the escrow App.
  3. Receive a unique claim link you can instantly share.

The recipient just clicks the link, connects a wallet, signs an opt-in transaction if needed, and claims the funds with a single tap. From the “Manage Links” page, you can reclaim unclaimed funds or “clean-up” completed escrows to ensure no funds are lost: opting out of the ASA, deleting the App, and retrieving Algo from limbo. You can also generate and share a referral link. If someone connects their wallet through it, you earn their full platform fee whenever a link they create gets claimed.

Details:

The codebase is written in JavaScript, using the AlgoSDK 3.4.0JS and use-wallet + use-wallet-ui by txnlab. The smart contract is in TEAL.

Usage:

The app launched on Algorand Mainnet just 2 weeks ago (23Sep). Since launch, 6 unique Algorand addresses have created escrows (3 Oct). Previously, in June, on testnet, 5 community members tested the app’s early version and provided helpful feedback.

Value to the Algorand Ecosystem:

1. A useful ecosystem tool. BubbaPay expands the way ASAs can be used across the Algorand ecosystem and beyond. Projects can use it for giveaways or rewards, and community members can easily send ASAs (like Ballsack or USDC) to friends without worrying about addresses or opt-ins.

2. A fully open-sourced repo. The codebase is public and offers a reference for developers new to Algorand or the JS SDK. It also serves as a template for anyone looking to build similar escrow or just the transaction composition flows. I believe it’s a valuable contribution to Algorand’s open-source base.

Rationale funding amount:

The funding request is based on two things:

  1. 1. Open-sourcing and contributing the full BubbaPay repo to Electric Capital.

    2. BubbaPay maintenance and deployment on Algorand mainnet.

This proposal is retroactive of course, but I’m committed to maintaining BubbaPay, adding new ASAs, fixing bugs when they appear, and continuing to promote it as a community tool on X.

Links:

Github: GitHub - nvds888/bubbapay

Website: https://www.bubbapay.app/

Documentation: BubbaPay - Send Crypto Anywhere

X: https://x.com/BubbaPay_

Testnet launch post on X: https://x.com/okido_123/status/1928491868234363380

About the team:
Okido

I started building on Algorand in early 2025, first creating Planeify, a gamified plane-spotting app that logged spots onchain. The project received strong community support and reached 100+ users and 2,000+ spots before being sunset after two months of public beta due to limited monetization potential and the time investment needed to realistically scale. Since May 2025, I’ve also been working on BubbaPay, first called NomizoPay, which launched for testnet in June and mainnet late September.

Beyond building on Algorand the past year, I’ve worked across several blockchain ecosystems in non-technical roles, including running an Accelerator program for impact and sustainability projects in the Polygon ecosystem, and organising/supporting numerous developer and community events globally with well-known partner organisations. A few years ago, I also had the opportunity to do a summer internship at the Algorand Foundation. Currently, Algorand related, I’m working on a startup and participating in the upcoming Startup Challenge organised by the Foundation.

X: https://x.com/okido_123

Let me know if you have any questions or feedback!

6 Likes
2

Beta, Experimental— I’m curious, couldn’t someone subscribing to the chain just watch for app creations where the TEAL matches your program (line for line excluding any constants you may insert) and just instantly claim?

You stated that anyone with the link can claim funds, so theoretically anyone familiar with your approval program can also claim them if they chose to watch for them?

Thats a pretty big concern for me.

2 Likes
3

Hi Leo, thanks for your reply.

During deployment a new account is generated and set as “authorized claimer” in global state. The creator’s address is also set. Only the creator can reclaim funds, and the authorized claimer can claim. The private key of the new account is part of the shareable URL - basically like a gift card code, anyone that has the full link can claim. When claiming, the private key is used to send the claim call to the App to release the funds to the user’s connected wallet.

1 Like
4

There seems to be room for development, such as exploring more advanced use cases or improving convenience in the future, but I believe it may still be too early to propose a retroactive grant. Current grants do not take future outcomes into account; they evaluate only the benefits or results that the product has produced at this point in time. (I think the shift from the old system to this approach was intended to focus solely on products that actually produce results, because previously there were cases where something was developed but not used and eventually disappeared.) In that context, even if we include testing, we would need to evaluate usage by only 11 users (and even on the mainnet, some of these users may be using it only for testing), which makes it difficult to demonstrate meaningful results.

For feedback purposes, I conducted various tests. Currently, on Algorand, even if the recipient does not hold any ALGO at all, it is possible to send assets using the Inbox feature implemented in wallets such as Pera Wallet. Regarding usability, both the Inbox feature and this tool require instructing the recipient on how to install a wallet and sign transactions. With the Inbox feature, you need to explain how to copy an address. In contrast, with this tool, you also need to explain how to use WalletConnect. Since this tool requires the recipient to use not only a wallet but also a new service—a dApp—honestly, the recipient ends up having more steps to follow.

In the case of the Inbox feature, during the sending process, the sender needs to instruct the recipient on wallet installation and usage, then wait for the recipient to provide their address. In contrast, with this tool, the sender can provide instructions and a receiving URL, completing the process in a single step. I felt that this is the main advantage of using this tool.

However, considering that the recipient’s effort increases, and that the ASA to be sent must be added manually (limiting what can be sent, which makes it less suitable for NFTs), I feel that there is no real advantage to using this tool.

4 Likes
5 
Hi Leo, thanks for your reply.

During deployment a new account is generated and set as “authorized claimer” in global state. The creator’s address is also set. Only the creator can reclaim funds, and the authorized claimer can claim. The private key of the new account is part of the shareable URL - basically like a gift card code, anyone that has the full link can claim. When claiming, the private key is used to send the claim call to the App to release the funds to the user’s connected wallet.

I see, OK.

I believe that the conditions of xGov are that the project be fully built in complete. You state that its experimental and in beta.

Is it incomplete and still have bugs? You mentioned that sometimes the link can be lost for claiming, do you have a way to resolve this? Do you plan to spearhead this in any way to actually have people used it? Or is it moreso just an “I built this” kinda’ thing and the value is just in the work you put in and open-sourced?

Thank you.

1 Like
6

‘‘You state that its experimental and in beta.’’ It’s quite thoroughly tested over the past few months. Solana still has the beta tag:) it’s my way of saying there could be an edge case that I missed, which I plan to take off over time. I wouldn’t have launched on Mainnet if I didn’t believe it was solid enough.

“Is it incomplete and still have bugs?” It’s complete in the sense that it works well, but it could still have bugs like any application, sure.

‘‘You mentioned that sometimes the link can be lost for claiming, do you have a way to resolve this?’’ Yes, I created fallback mechanism where users can directly delete unfunded Apps of which the claim link went lost due to unmounting. This never puts a user’s money at risk as creators can always reclaim funds! It’s an edge case on mobile that happens sometimes when navigating between wallet and browser, when react unmounts the key used for the claim link is cleared as it’s not stored anywhere for safety. Funds are never at risk, and I created the fallback for smoother UX when it happens.

‘‘Do you plan to spearhead this in any way to actually have people used it?’’ I had a call two weeks ago with a project from the web3classess potentially interested in using it for their MVP to distribute rewards. Exploring this as a use-case, and so far two projects have expressed interest. Apart from that, I will be promoting this on the socials as community tool.

‘‘Or is it moreso just an “I built this” kinda’ thing and the value is just in the work you put in and open-sourced?’’ I mean, that’s a large part of scope of a retroactive grant, right? The requested amount is for the open-sourced repo and community impact - which I admit isn’t the largest yet. I wouldn’t call it a ‘kinda’ thing though.

I hear you though. Thanks for asking the questions.

2 Likes
7

Hi aper,

Thanks for providing the feedback and asking the questions

To clarify, my proposal is purely retroactive. For work done in the past. This includes the open-sourced repo and deploying the App to Mainnet.

‘‘I think the shift from the old system to this approach was intended to focus solely on products that actually produce results, because previously there were cases where something was developed but not used and eventually disappeared’’ correct me if I’m wrong, but the opensource requirement tackles this issue that the old grant program had, right? It’s payment for work done: the codebase. m. Maybe that’s where my misunderstanding arises as I thought the transaction is for 1. the open-source contribution, and/or 2. the previous community impact.

To your comparison with Pera Wallet’s inbox feature, BubbaPay is not restricted to a specific wallet provider and the whole idea is that you can send ASAs to recipients without knowing their public address.

‘‘honestly, the recipient ends up having more steps to follow.’’ I’m not sure I entirely agree with this. I’ve tested with multiple friends, send them a few USDC via BubbaPay, they set up their wallet without any questions asked and claimed the USDC. They would never have done this if I said, ‘‘download this wallet, send me your address, and I’ll send you some USDC later’’.

2 Likes
8

Regarding the document, the xGov Beta Architecture describes Retroactive as follows:

Retroactive

Claim: “I have done X, which has benefited the Algorand ecosystem because of Y metrics, I would like to receive Z as compensation for the work”.

Positive outcome: funding is immediately disbursed if the Proposal is approved by the xGov Committee vote, and the xGov Council does not apply a veto according to the terms and conditions.

From my personal interpretation, I believe this becomes a process in which the reward “Z” is determined based on the metric “Y”. Furthermore, I interpret that the metric “Y,” which determines the reward, must already have been achieved at the time of the proposal, compared with Proactive.

From the perspective of what kinds of activities should be rewarded, the purpose of the grant program is described in the xGov Proposer Terms & Conditions as follows:

The Program aims at making focused and strategic use of Foundation resources by funding high-quality initiatives that deliver demonstrable ecosystem value in the form of on-chain wallet growth, transaction volume, ASA (Algorand Standard Assets) value creation, and chain monitoring tools, amongst others, as approved by the xGovs via the application process available on the official xGov platform, supporting the growth and development of a vibrant Algorand ecosystem (each an “Initiative”).

From this, I interpreted that the proposal you submitted this time would fall under “on-chain wallet growth.” If the metric “Y” is set here, I personally feel that the value “11” may be small. If you have an opinion that the metric should not be here, it would be helpful if you could indicate it. (I am acting in accordance with the following statement in arc-0083, xGov Council - Application Process. That is, I aim to create opportunities for the community to engage in discussion.)

Evaluate proposals to check compliance with terms and conditions, provide general guidance, and outline benefits or issues to help kick off the proposal discussion.

Therefore, the xGov Councils have no authority whatsoever to cancel proposals submitted at the current discussion phase. We are merely extracting information to provide xGov members, who hold voting rights, with the basis for their decision-making. In other words, I hope that this content will serve as a trigger for various people to join the discussion.

I would greatly appreciate your understanding of this position.

3 Likes
9

Thanks for clarifying and sharing the definitions from the T&C.

In this case, at least how I interpreted it, that would indeed make metrics like “transaction volume”, “ASA value creation” and “on-chain wallet growth” - aka community impact - relevant, which as you pointed out are still quite weak since the App is only recently launched.

Within this definition I would also certainly regard the open-sourced code as ‘‘metric’’ for value to the ecosystem and that it’s a Mainnet deployed app to use ASAs in a way that wasn’t possible before (send to someone without recipient address)

I appreciate the input. My aim with creating this proposal was to request a modest amount because community impact hasn’t been substantial yet, but I personally saw the value in open-sourcing the repo, submitting to EC, and the value of having another tool available within the ecosystem to send ASAs around. Ultimately this is up for the xGovs to decided if this is value provided enough

3 Likes
10

Thanks for your contribution!

I’d be curious to hear why you decided to develop a new smart contract for this application, instead e.g. using/building on top of ARC-0059, which is used by Pera’s Inbox feature. What did you find it lacking?

I’d also be interested to know why you decided to develop the contracts directly in TEAL. While I do think it would be useful for the ecosystem to have more open-source projects that use pure TEAL (especially for educational purposes), it could make it less convenient for others to build on top of it.

Lastly, I think it’d be useful for others who would like to build on top of this project to have some additional info on how to run/deploy it.

3 Likes
11

Hi Uhudo,

I certainly knew about the Inbox Feature, but not about ARC-0059 specifically. I started building a contract from scratch back in April/May with the initial aim to learn more about App development on Algorand, so building upon existing ARCs wasn’t really on my mind. [updated] I also shared the progress on X back then which was met with a lot interest from the community and some design suggestions to improve the App I was creating, so naturally I continued with this. I also think using arc-0059 would’ve required quite some changes and challenges with the flow I had in mind, considering recipient address is unknown

‘‘I’d also be interested to know why you decided to develop the contracts directly in TEAL.’’ I initially started with TS since I had just started using it for Planeify (another app I was working on), but walked into some challenges and decided switch to JS and TEAL to give that a go since I could find more examples. Since then I played around a lot in this setup so just stuck to it as it worked well for me.

‘‘Lastly, I think it’d be useful for others who would like to build on top of this project to have some additional info on how to run/deploy it.’’ yes absolutely. I’ll definitely add more detailed documentation.Thanks for the feedback.

2 Likes
12

So that we’re all on the same page, neither is ARC59 Inbox.

It’s a singleton contract that can be referenced by any wallet (it was in Lute before Pera) or by any dApp (AlgoTools allows Defly users to manage their Inbox since it isn’t integrated into the wallet).

2 Likes
13

Hi all,

After some consideration the past days based on the discussion here + now having a little more context seeing the other proposals, I have decided to withdraw this proposal. I will not be putting this up to a vote at the end of the discussion phase.

I have been building on Algorand with a lot of pleasure and enthusiasm the past year. As a xGov myself, I certainly hear some of your concerns with the proposal in its current shape. Perhaps I’ll resubmit sometime in the future when the App has better adoption metrics to substantiate it.

Anyways, thanks for your input and feedback. I jumped the gun with this one. Let’s keep building

5 Likes
14

Hi @okido_123, thanks for trying out the process.

I hope you will get back with another proposal once you are ready.

Please withdraw your proposal from the xGov platform so that you can receive your anti-spam deposit refund.

Let me know if you have any questions.

15

Hi @Adri, I did this last week and thought that the UI lagged, but now see the delete txn is failing:

‘‘Received status 400 (): TransactionPool.Remember: transaction IGZGKOBMMZFKKLL6ZSQNLWIS76WP35Q4NYYTXGA5CH7K5HRTCUSA: logic eval error: assert failed pc=1060. Details: app=3244303791, pc=1060, opcodes=bnz label38; intc_1 // 1; label39:; assert’’ Error: Transaction failed at transaction(s) 0 in the group. transaction KZGETZPJLHHUR3H7LXSRRAYOB7BQYVHFH6ALPC44FFIGH5IEBFWA: logic eval error: assert failed pc=4209. Details: app=3147789458, pc=4209, opcodes=concat; box_get; assert

2 Likes
16

Hi @okido_123, thanks for posting the error. I’m discussing it with the dev team and will report back.

1 Like
17

Hi @okido_123 I investigated this & the error you posted is unrelated to dropping your proposal. The proposal actually was successfully dropped & you we’re refunded the 450 Algo you escrowed for it.

You can view it here AlgoKit - lora

As you can see the proposal still exists, there is a clean up process that never got kick started properly but is supposed to run in the background to complete the deletion once the proposer signals. I’ll get right on fixing that, Thanks for the report!

2 Likes
18

@krby.algo woops, totally missed that. Thanks for letting me know!

1 Like