Good to know, thanks! $2 per card is likely completely paid for by the CC fee savings. $100 paid in 10 x $10 increments is $5.90 in fees... so even with a $2 card, if a user is topping-up with $100, you could still even offer "$2 cash back on $100 or more" and be in the black.

What different payment schemes at different levels are you referring to?

Reply to this note

Please Login to reply.

Discussion

Basically, we shouldn’t need a case where we start with the simplest solution for small communities. Then realize the security is not enough for large deployments and come up with a new spec, then there’s a new ecash spec and so we make another and so on…

This would only cause more harm than good.

My proposed design is that we use LN for the base layer for payments.

These can tell the PoS “make API calls here” and then pay the invoice. A mint could implement a special API for these. Or a custodial wallet, or a self hosted wallet, or an NWC gateway…

Because these cards are in fact powerful microcontrollers. You will have to sign an NDA for anything useful though, ask me how I know

Here's the SINGLE hurdle I'm trying to get over: naive retail customers can't make lightning payments without a lightning wallet. I'm not going to take on the project of getting a new customer in the door to get a lightning wallet. I WILL try to get them to hand over a $100 bill in exchange for a simple tap-to-pay card that works just like their debit card at all the local stores and requires **precisely zero** new understanding beyond "this got me a good deal and everyone says it reinvests some money in my community".

Do you understand my narrow point here?

The system I described also would be able to work the way you want. Even could do top-ups.

Okay well then consider me very interested. I'm clearly not understanding your proposal (or maybe I just don't know what you're referencing and do already understand the thing, whatever it is)

Basically these cards are microprocessors.

So what if we moved a whole bunch of the payment logic into them. So the card just tells the PoS system “hey can you get this for me” (whether it be calling a mint, or a wallet provider, etc.)

With an ecash mint or custodial provider that supports this, you could create a dedicated wallet for each card that doesn’t need to be managed (but can be if the person cares)

Want stable $ balances? Use a provider or mint that uses USD-denominated balances.

Underneath it’s LN with only 0.5% fees max for the sender. Usually none if it is in the community (as the community mint and savvy providers that want to selfhost can open feeless channels)

Yea, I would likely run the mind and would keep it all internal for all merchants - with the option to out-ramp for savvy users, as you say.

Yeah. You can also support top-ups from any merchant. If they want to get off of this system they can talk to anyone that wants to get in and swap for free.

Congrats you built a P2P exchange economy.

A dedicated ecash protocol can be made for this too. Since only the payment cards care, it can be optimized, and they all speak LN.

Well how convenient, a P2P exchange economy is exactly what I'm trying to do :)

Can't you do all of that directly in lightning. lnbits+ntag424 chips? The nation currency backing would still have to be implemented somehow (e.g. open a future contract on lnmarkets?), and that middleware could do the necessary api calls for the card/chip/wallet.

Putting that aside for a moment ...

The problem I face here is mostly that onboarding merchant is difficult/expensive.

They need to provide tradfi terminals (so they still pay banks their cut) + now they need a specialized device for lightning (if they don't run something with android+good nfc reader; which is rare here) + the chips.

Unless merchant is bitcoiner, my experience is mostly good only if I say it won't cost you anything to provide this payment method.

When they see how it works, we can get into things like gift cards, spend only mints etc. But that almost never happens.

NTAG 424 is not secure enough for this purpose

might be enough for MVP

(assuming spoofing and clonning worries, right?)

it is more costly to change a spec later than to do it right at the start

I personally know the handful of merchants involved and would help with getting them cheap android phones for this purpose (or use their existing tradfi POS (which they all have) if its an iPad). they don't have to be bitcoiners (yet), they just need to want to save many thousands of dollars a year in credit card fee extortion.

they are using a worse, more expensive settlement layer just because I haven't finished this yet. I can't abide that.

Okay, so: are these cards currently available and how much of the system you're describing has existing solutions I could re-purpose vs building entirely from scratch myself?

1. Kind of. The cards exist but you’d need software. Building that requires NDAs but I am already working with a smart card company, so this could be possible to build.

2. You could build it on existing systems but they are not ideal, and certainly not designed for USD (sats only)

There exists no specification for this level of systems either.

If you want to be able to compatible with Boltcard based systems (which are insecure but they exist) then you’d want an account based model.

Otherwise you could use ecash.

Also, you can have card-to-card transactions as well.

this brings to mind another hurdle: this solution is "CARD ONLY" (no companion app needed), right?

Yes, except for the PoS which needs an app, but that is to be expected.

yep yep exactly.

when you said "card to card" I wondered if you meant "on the sidewalk, outside the shop", but I get what you mean now. just making sure, thanks.

card to card would require one person to have an app as an intermediary, but yes.

With iOS app clips you wouldn’t even need to install it! Just tap and it’ll load the app clip to transact

Android has a similar feature as well but you can’t read NFC tags

In the app clips feature, I mean. So you’d need to install

Note: Consider that you are now a money transmitter (account-based is clear cut on this, you are. mints are a gray area)

This is another reason to use a mint ;)

Possible, just forget backwards compatibility with Boltcard. But that is less secure and less capable as well and you don’t need it for a ground up system

yep, don't care about boltcards now. Goals are only:

0. avoid CC fees

1. customers don't need to understand anything, just use tap to pay

2. customers get $-stable, $-denominated prices

3. merchants will take on more infra work wrt PoS and slightly more understanding

Also if you want keyset rotation, you would need to have people tap and use cards every few months.

Otherwise they would expire due to inactivity

wait I spoke too soon: there is a secondary hurdle that is just as important: dollar-denominated for the customer and stable prices.