Venmo/Cashapp product planning

The fact that Grin is so cheap helps it too. It doesn’t feel quite as serious as Bitcoin. Who in their right mind would sell or give away any Bitcoin for example?

Using Nostr addresses for Grin transactions seems to be a good choice, Ironbelly is doing a great job, looking forward to experience it soon.


Super cool to see! I see in the video that the choice is between Nostr and Slatepack.

Does that mean that the Nostr address is interactive? Or is it sending a slatepack via Nostr?

it has to be sending slatepack via nostr since in grin slatepack is data and tor, nostr, email etc are just different ways to transfer that data

1 Like

It seems to be sent and received directly with Nostr address, the specific design idea is only explained by the author, if he has time @i1skn

For now I’m just experimenting with Nostr, but an idea is to add it as a third payment method to the app. The end goal would be to make it asynchronous too, but in a way so the app can automatically accept transaction in background without the requirement for the app to be opened. The video was just a capture of heavy in-development version, so this would change I think.


Yeah! you should definitely encrypt it using one of the DM methods (i’m not sure which is the consensus at the moment) Issues · nostr-protocol/nips · GitHub

But i love this idea. of course you’re leaving a paper trail, but maybe you can let the user decide which nostr profile they are sending it from? there is such a thing as delegation as well nips/ at master · nostr-protocol/nips · GitHub

Ironbelly could absolutely become a Cash App/Venmo for grin! Or maybe eventually you’d want to have that be a separate app so that IronBelly could remain a more privacy focused wallet idk. A messenger focused app for Grin could be built on nostr and be awesome


Damus released “private zaps” today in Testflight

Theoretically Grin Slatepacks could be even more private because the slatepack would just be sent in a regular event rather than a special NIP zap event. So the relays wouldn’t have to know that you’re sending money at all.

This comment is cool though.

Relays are included from your config in the zap invoice so that the zapper knows where to send the zap to. Damus will add anti-fingerprinting techniques in the future such as randomly dropping relays, etc

Its the only thing that could be used to de-anonymize an anonymous or private zap, but its more of a theoretical concern. People looking at zaps can only guess that its you based on the relays, there’s no way to know for sure.


By the way, here is the NIP for “zaps” (Lightning Invoice events).

To follow this same kind of structure, I think you’d put the slatepack in a “grin” tag, like how they put the LN invoice in the tags.


We could actually follow the spec of NIP-57 almost exactly the same. So you could send a slatepack in reply to a specific note (like tipping someone for a good post) or just generally to their account. And you could also include a note in the content that says what the money is for (this is like the fun part of Venmo where you have emojis etc).

1 Like

Kollider added this functionality to their lightning wallet

1 Like

Since Python Mimblewimble has been released, someone can combine it with Python Nostr

Maybe even use Pyncone for a front end!


@trab Nice idea for a Community funded project once Python MimbleWimble has a working wallet and transactions and once the Bitcoin price is > 30k$. Once the Bitcoin price is a bit higher, there should also not be a problem with a funding request for finishing Python MimbleWimble’s main functionality @renzokuken

1 Like

Since Grinventions has been mentioned, I hope you guys don’t mind if I create a little offtop and as a founder of Grinventions I will add my three words.

Thank you for mentioning! I will be more than happy to officially include Nostr in the Grinventions roadmap.

Regarding Pyncone, this would require some investigation, but our roadmap includes also JavaScript implementation. This would take a bit longer as we would need secp256k1-zkp-mw library ported to JS.

I also want to clarify that the newly released Python SRS flow is (for now) just slate building. Transaction handling is yet to be implemented, but don’t worry, work doesn’t stop.

Unfortunately, creating requests for funding is against Grinventions philosophy and policy. We are happy to accept donations from both main fund and community fund, but we cannot apply for it, at least not by the common approach that was practiced here until this moment. Reason for that is independence. Grinventions committed to follow ツ standards and maintain compatibility, but if we start to apply for funding then someone external will be in position of managing us and creating guidelines of how we make the next ツ implementation. Grinventions gives trust to the community to donate after we do the work, but we also expect the community to trust Grinventions that the work will meet the RFC standards.

I am working on defining a funding scheme that will allow anyone (including ツ fund and community fund) to contribute. The scheme will be based on retroactive grants (opposite to apply for funding where you request money before you do the work, here work will be done first and then request will be made). I want it to be legal and safe, and that takes time and resources. If someone has legal or accounting knowledge or runs a business and has legal setup and wants to help create this scheme for Grinventions, feel free to DM me!


I would like such an approach :+1:.
Note that when it comes to freedom, such freedom is also available in any regular funding request, since the applicant can define the deliverables and specifics in a request and can simply deny modifying a funding request when changes are proposed which are against their vision.
I can however very much imagine that the regular funding request can feels restrictive and meddlesome. @davidtavarez also expressed similar sentiments in the past. Exploring other ways of funding such as retroactive grant is therefore a good idea, and I would not be surprised other developers would be interested in using such a funding scheme. Lets keep ‘grinventing’ ourselves and the way Grin as a project is governed :grin:


I want to add the Tox protocol and qTox client as candidates. Clients - Tox

1 Like

Mutiny (the bitcoin lightning wallet) just published a blog post about how they used Nostr to create a Venmo style UX! Much we can learn from this

How many payment app contact list silos are you currently embedded in? Venmo, Cash App, Apple Pay, PayPal, Meta Pay, Zelle… the walled gardens are many!

As a new and upcoming Bitcoin/Lightning wallet, we would like to build the sort of UX enabled by a traditional contact list. After all, users don’t care about invoices. They just want to send money to each other.


This is a ticket summarizing where all the efforts stand today Encrypted Chat Master Thread · Issue #717 · nostr-protocol/nips · GitHub

1 Like

Note that Pynecone is now called Reflex

Looks like it has really come along!

1 Like

new blog post about design updates that make the wallet more people-oriented. This is exactly what I am talking about! Super inspiring Mutiny's new design puts people first

1 Like

Absolutely! I would support any solution that is separate from Grin. I just don’t want something bundled with grin or grin-specific.

Farcaster is indeed tightly coupled with Ethereum. That’s fine, I’m not a hater. But the benefit of Nostr is that it is completely permissionless / payment agnostic, and we could eventually pay Nostr relays in Grin. I don’t think that would ever be possible on Farcaster just because the payment system is already coupled to ETH.

I made a farcaster account. I have my own opinions on the network itself. I suggest others try it too.