At a recent OfferZen Investec meet-up with the Programmable Banking Community, Luno co-founder Carel van Wyk shared details of his latest passion project, which takes Bitcoin closer to the holy grail of peer-to-peer payments.
His newly launched app Watts4Sats, now in alpha testing, allows users to buy electricity with Bitcoin. He also offers insights into working on the Lightning Network and what it means for crypto payments in the future.
Carel built the alpha solution using Go, Vue and SQLite for the front-end. Running on AWS, on an EC2 instance. And Bitcoin and LND were the interfaces to the Bitcoin and Lightning networks.
Transcript of the demo
Carel van Wyk 0:01
Thanks for the invite. I feel like I'm new to the OfferZen community because I don't recognise a lot of faces. But actually, while I was still working in Cape Town for Luno, I attended a lot of the early make meet-ups. The only person I recognise here is Ben and, of course, Gabby. I got to do some work with Gabby this year, as well.
Carel 0:29
Tonight, I'm going to talk about something I've been working on for the past couple of months that's related to Bitcoin payment technology. And I really love talking about this stuff. I love talking about Bitcoin and Lightning. And I actually launched the alpha version of this app on Sunday.
So, this is the first time that I get to actually present it to a bit of an audience. I'm very excited about this. Thanks for this opportunity. So, this is me. I'm on Twitter, @carelvwyk. And the project is called Watts4Sats.
And it's part of a bigger thing that I'm working on called Crypto Convert. And Crypto Convert has a dual meaning: it's either you can say well, [I'm] converting crypto or you can say that you convert yourself and you become a crypto convert. That's why I have that little guy sitting there meditating on Bitcoin. The app demo that I'm presenting, it's related to the problem of Bitcoin payments.
When Bitcoin first came out, the paper was titled "Bitcoin: A peer-to-peer payment system", or peer-to-peer cash system. And it turned out that it wasn't really achievable, until fairly recently. I think the technology's been developing, and there've been new systems that have been developed around Bitcoin. And I feel like today, maybe we can start saying that it can be a peer-to-peer payment system.
But I'll discuss the problems that we faced in the past. And the solution now and how it overcomes them. So, these slides are templates, and I had to specify a goal. I couldn't really think of a goal. My goal is just to play with this technology. Like I say, I really love it. I think it's really interesting.
But if I have to pick something, then it would be disintermediation. In other words, peer-to-peer payments. So, similar in the way that the world built peer-to peer-file sharing back in the day, and it overcame censorship and a whole bunch of other things and the industry had to adapt, we can now start doing peer-to-peer payments. And I'm very interested in seeing how that impacts the industry. And how the world moves on from that now that it forces people away from legacy systems.
Just for interest's sake, the stack that I use is: Golang … I really like working with Go especially if you're doing concurrent stuff; Vue, which is a very nice front-end framework; sqlite, because I'm lazy, and didn't want to spend the time spinning up a Docker instance on MySQL. This is running on AWS on an EC2 instance. And, of course, Bitcoin and LND are my interfaces to the Bitcoin and Lightning networks.
Carel 3:32
After each slide, I'll just give like a couple of seconds, if there's a term or something that I forgot to explain, just unmute and say "hey, quickly explain that one term". And if I move on too quickly, then just stop me.
The next slide on the template was a quote. So, I had to include a clip quote and I decided to pick the very first quote in the history of Bitcoin, which is embedded in the Genesis block.
["The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" - Bitcoin Block 0].
The Genesis block is the first block that was mined. And since software developers count from zero, it's Bitcoin Block 0. And the quote relates to the context at the time that Bitcoin was launched.
And it kind of probably says a little bit about what the designers and makers of Bitcoin felt at the time. They felt that the existing financial system maybe was not quite sustainable. And I think today as well, there's a lot of people talking about inflation and billionaires just amassing infinite wealth. So, I feel that it's a relevant topic even today. Especially today.
The problem
Carel 3:23
Okay, so the problem of Bitcoin payments.
To me, the gold standard of a Bitcoin payment is if you can walk into a coffee shop and buy a coffee. And what that means is it's a payment that's relatively small. It needs to happen relatively quickly. You don't want to hold up other customers, and it needs to be fairly reliable. In the past, this wasn't really easily achievable. There's a couple of problems with Bitcoin payments. If you talk about Bitcoin layer one, or the base layer, or the blockchain layer of Bitcoin.
I'm just going to [...] for those who are not super familiar with the Bitcoin network, the way it works is there's a specific capacity. The network has a specific capacity or transaction throughput. And what happens is that if that throughput is exceeded, if there's more transactions coming in than can be processed, then some transactions are bumped to the next block or to the next blocks, and they're delayed. What you can do to expedite your transaction is you can attach a little network fee to it.
But one problem is that the sender controls the transaction fee. In other words, if you're a merchant, and there's some congestion on the network, and somebody pays you in Bitcoin, then if they pick a very, very low fee, there's a chance that transaction taking a very long time to confirm on the network. What a confirmation, or verification, is it's surety or a guarantee that you have received that transaction. Up until that point, there is always a chance that the transaction could be double spent.
And what that means is basically, somebody can send the same Bitcoin to you and to somebody else, I could send it to Nick and [Gabby] at the same time. I can do that because it's just a private key and I can generate two transactions. Only one of those transactions will ever be verified. So, there's that risk. With a low fee, you've got to wait a long time until that risk is eliminated.
Then, another problem with Bitcoin payments is that if I give you my Bitcoin address as a destination, then you can essentially send any amount. The receiver has very little control over the amount that is sent, as well as the time that it takes to send the transaction. I can provide you with the address now and you can pay me tomorrow, even next week. And then I [now] have to do something with that payment, [but] there's no way to stop you from making [the] payment tomorrow. The sender controls those parameters as well, [and] it's outside the hands of the receiver or the merchant, and it's difficult to manage.
So, in the real world […] I bought a merchant interface at Luno that PayFast integrated. And at the end of the day, when the network became quite busy, only two out of three payments succeeded. And that meant that one out of those three payments failed, and we had to return the funds. Because there was network congestion, the refunds were expensive because we had to attach our network fee. And at one point, we also did a proof of concept for Pick n Pay. They've got a little store at their head office. And the person from Pick n Pay testing it, tried to pay for his R100 basket and his wallet paid R200 in network fees.
So, he said, well, that's not a very good payment experience, and we cut the proof of concept short there.
In a nutshell, the problem with Bitcoin payments is that the sender can easily send too little, too much, or too late. And then it's a problem for the receiver.
The solution
Carel 5:21
So possible solutions. We addressed some of these problems with a couple of [...] techniques. The one was to accept slow transactions; we will accept the zero-confirmation transaction.
Like I said, there's some risk associated if the transaction has not been verified. But you can accept the payment if you can see it. And you can generate some risk models. You can look at whether you've detected a conflicting payment, you can look at the network fee and estimate how long it will take to confirm or be verified by the network. And based on the risk model, you can make a decision and say, okay, I'll accept the payment. Another way to resolve this slow Bitcoin transaction problem is you can just scale the block size. A lot of people that say let's just scale the block size.
That's why we've got tokens like Bitcoin Cash and Bitcoin Satoshi Vision. There are groups of people that said, well, we'll just scale the block size. In fact, this is Satoshi's idea.
There are postings of Satoshi on the Bitcointalk forum saying that probably what will happen is that there'll be super nodes and everyone will connect to the super nodes and the super nodes will have very large hard drives, so we can just scale the block size. And then, in terms of time window and exact amounts, the core developers actually implemented this thing called BIP or Bitcoin Improvement Protocol 70, or payment protocol. It's like a URL where the wallet would retrieve payment information from it.
So, it will retrieve an exact amount and add an expiry time. But this protocol has since been discontinued. It's been deprecated, so we can't rely on it anymore. Okay, so on the scaling solution, the question is, well, why don't we just scale the block size, but then the Bitcoin Core protocol decided not to scale the block size.
Carel 8:55
I'm wondering if there's anybody listening in that knows what this is. Any takers? Has anybody seen this?
Carel 11:13
It looks like a switch, but it predates a switch. It's like the prototype.
Renaldo Meere 11:21
It's basically a very dumb switch.
Carel 11:24
Exactly. It's a very dumb switch.
How it works is, when the computer connected to port one sends a packet, then it gets duplicated to all the other ports. That's why it's called a dumb switch.
Whereas a switch is a little bit more intelligent, it knows the addresses of each computer connected to it. If one sends a packet that is destined for port two, then only port two will receive it, and the other ports won't be bothered by it.
The reason I use this analogy is because the Bitcoin network, the blockchain, works like a hub, it's a dumb hub. Each transaction that gets sent to the network gets duplicated to all the nodes on the network. So, that's also why the network gets congested so easily, because if there's a lot of packets, or a lot of transactions being sent, there's a lot of noise on the network. And it gets saturated quickly. And this has this little COL button.
COL stands for collision. That thing starts flashing like crazy when everybody starts sending packets. And basically, people saying we should scale the block size are saying we should scale the CPU or the RAM of this hub. And I don't think that's a good solution, because you're basically just going to kick the can down the road; you're just going to reach saturation point later on, then. But it's a debate we could have if anybody's interested.
Then the question was, well, do we have any other solutions? And then somebody came up with this concept of well, okay, if we can't optimise Bitcoin transactions when we need to make a payment, what if we kind of set up payment channels ahead of time.
So, it doesn't matter how congested the network is, two nodes in the network can set up a channel between themselves with a Bitcoin transaction, and they can wait until that transaction is verified.
But then once it is verified, that channel can batch or bundle hundreds or even thousands of transactions on it. And if you've got these channels, [which] are links between a whole lot of nodes, then it starts to look a little bit like something like the internet. This is a render of the Lightning Network superimposed on the geo-locations of the IP addresses of the nodes on the Lightning Network. And this to me seems like a better way to scale because it starts becoming something like a switch or a router.
There's a reason we don't use hubs to connect the internet together, we use routers and switches that have channels set up between nodes. And I like to call Lightning "activated Bitcoin" because you have to lock up some funds, you have to send the transaction, which takes some Bitcoin.
You lock it up, but then it's activated, then you can send transactions over that channel very rapidly and for very cheap. So, how does Lightning solve all these problems? Low-fee Bitcoin transactions are slow while we establish pre-hoc channels and they can batch-job hundreds of transactions and we can settle things instantly over these channels. It's just [...] on the two nodes that there's a ledger update, not the whole network. And there's some cool technology to do that in a secure way. I'll mention it in the follow-up slide.
And then in terms of the exact-amount requirement and time-expiration requirement, all Lightning payments are invoice based by default. It specifies the exact amount and expiry time. So, that's great for the receiver. And then there's some very cool features that's baked into Lightning, like this one thing called the hold or HODL invoice.
And that's why I built the app, to make a proof of concept of this whole invoice mechanism. And I'll explain what that is in a little bit.
Devina Maharaj 15:33
So Carel, there's a question in the chat from Malan.
Carel 15:39
Yeah, so we've got Malan Joubert. Hey Malan. What is the current typical Bitcoin cost to open a channel? Is that a consideration at all? [...] Like I said, the sender can define the fee. So, the cost is up to the person establishing the channel? It depends on how quickly you want to open the channel.
Malan Joubert 16:06
Just typically at the moment [...]
Carel 16:09
I actually don't know.
When I open channels, then I pick the lowest fee. And then that's, let's say, typically in the order of, let's say, R10. [...]
There's some consideration when you close the channel, then you typically want to do things quickly, but I'm not going to go into that now. So, then the fees might become a little bit more. But keep in mind that once the channel established, you can split those fees among the expected number of transactions that you're going to send.
So, you can divide it by a hundred, a thousand whatever for each thing sent over it. Just on the topic: if you use a provider, like Luno, Luno picks the fee, and they typically try to optimise for speed. So, if you use your own wallet, you can pick a low fee, you can pay one rand, if you go with the [provider] they're going optimise it. If the network's busy, it can go up to R50, up to R100. It's very relative, the sender decides.
Right, I'm not going to spend too much time on this, I don't think I've got a lot of time. Lightning uses this innovation called Hashed Timelock Contract.
Basically, the hops between nodes that secure a channel, there is a time lock. So, if one of the nodes disappears, then the other one can get its claim or share of the funds back; [it] just [has to] wait a bit of time. Or it's secret based.
So, if there's a secret that's being shared between the two nodes on the network, then they can use that secret to update the balance on either side, it's a really cool thing. Well worth reading up on.
Carel 17:53
Okay, challenges encountered?
This is another template slide. Lightning is always on. It's not like Bitcoin, where you can receive a transaction even if your wallet is offline. There is an order of magnitude, more complexity, in processing Lightning transactions.
So, it took me a bit of extra time to just wire that up. Incoming channel capacity: you can imagine now you've launched an online store, but nobody has established a channel to you yet, so there's no way for you to receive funds. You need to somehow get incoming channel capacity; somebody needs to establish a channel to you. And there's markets for that. I purchased incoming channel capacity on a site called Bitrefill.
It's not too difficult, but you need to manage it. And then not many people have Lightning wallets. If you instal MuunWallet, I recommend that because it's non-custodial. I'm not going to explain what that means. But if you're interested, you can ask me later. Instal it tonight and then you can try out the app. I'll send you some Lightning Bitcoin to test and then of course – probably I should have mentioned this first, at the initial slides – my app is like if you mined Bitcoin, then you need to use electricity.
This does the exact opposite: if you have Bitcoin, then you can buy electricity. And it uses Lightning payments to issue electricity meter batch numbers. So okay, but I'll show you when I demo the app, so one problem is that not all electricity meter numbers are supported, especially in the Eastern Cape.
And I recently became a dad, and it's quite tricky finding time, working on a side project, working full-time, with a four-month-old baby in the picture, I can tell you that. Maintaining a balance at the provider; that's another challenge. Obviously, I need to monitor the amount of rands that I have to buy electricity vouchers for people.
Maybe that's something we can talk about a little bit later.
Carel 20:06
Okay, next steps?
For some reason, the slides sometimes get stuck a little bit; I don't know what's happening there. Step one, but basically, I launched alpha. Next, launching public beta. Lighting Maps is another app I want to work on. And then actually, what I want to aim for is payment provider integration, find some payment provider with merchants that are interested in accepting Lightning payments, and help them get up and running so that they can accept it, and then they can decide they can keep the Bitcoin, or I'll convert it for them into rand. How can you get involved?
Maybe, we can discuss some of the problems I'm having with keeping that provider balance topped up? Want to get in touch? Here's my details.
How he did it
Carel 20:56
I'm going to switch to the app now. And then after that, I'm going to give some opportunity for questions. The app is Mobile Web. Like I said, it's Vue based. I'm trying to optimise it for mobile. And it's very simple.
You provide your electricity meter number, you provide a rand amount between R25 and R100 , and then you say, "Get payment details", and it gives you a Lightning invoice. So, Lightning invoices are like complex QR codes because it needs to embed this long code. The reason it's so long there's a lot of information. I'll show you now. This is just the details.
And as you can see, I've done an on-the-fly conversion, we've got 3 767 satoshis. That's about R25 . And this thing, like I said, there's an expiration date built in; [it's still] valid for the next 15 minutes approximately. I'm going to stop sharing my computer screen, and then I'm going to share my phone screen.
Carel 22:09
I'm switching to my Lightning Wallet. So, this is MuunWallet. It's pretty straightforward.
If you send funds, you can just scan a Bitcoin off a Lightning QR code. If you receive funds, you can decide whether it's a Bitcoin receipt or a Lightning receipt. So, in this case, I'm going to scan the QR code that's been generated. Okay, and I hope you can see this, but there is a message embedded in the invoice that [shows I'm] purchasing R25 of Watts for meter number; my meter number; it gives the amount; and it's to cryptoconvert.co.za. I'm going to switch back before I click Send so you can see what's happening on the app side. Sorry, I know this is a little bit, getting seasick.
Too [much] switching. All right, we're back in the app. So, the status will reflect the payment status, I'm going to press Send now. Okay, [it's] sent. It should … So, you can see it's pretty instant. The payment was received, and the system is generating an electricity voucher for me. Today is Thursday 30 September, generating voucher.
The voucher generation actually takes a bit of time because the provider is a bit slow. But again, there's my [inaudible], there's my number of units received. And so, something interesting I wanted to demo here is if I do another transaction, that's [inaudible] another transaction for R25, get the payment details.
And I scan it, send, payment received, generate voucher. Something interesting happened: it says payment refunded, could not generate voucher. So, there's a limitation on the provider side, if you submit two transactions within five minutes for the same amount, they assume it's a duplicate and they return an error. With a Bitcoin payment, the problem I would have faced as a merchant is the sender or the buyer has sent me their funds. And I've failed to generate the voucher, so now I have their funds and I'm not able to give them their PIN. And so now what I need to do is I need to return their funds and typically with a Bitcoin payment, I would have had to make a new payment; again, attach network fee. I'd have to ask them, what's your refund address. I'd have to contact them somehow.
There's a support overhead to that, and it gets quite expensive to manage. Whereas with Lightning ... I'm not going to switch back to my phone; it's too much switching. But what happens is that … this is the power of the Hold invoice. So, the Hold invoice is a two-step process.
The sender sends the funds; the receiver receives it; but then the receiver has the option of either settling it, or confirming it, or taking it, or they can cancel the payment and then the funds are returned to the sender immediately. So, it's not a separate refund transaction. It [says]payment that was cancelled and so on the wallet side, I'm just seeing Failed. [I can] see the description but it says failed, so it couldn't go through. And that's powerful for a merchant because refunds are now trivially easy whereas in the past, it was this massive process with us and PayFast to get these things sorted out.
So, that's the app demo. Pretty straightforward. And now I'm going to stop talking. I think it's time to hand over to the audience.
Devina 26:16
Thank you very much it was very cool. Yeah, I think you guys really enjoyed it. Anyone have any specific questions ...
Questions from the community
Carel 26:24
I see some questions in the channel. I'll maybe cover those.
Robin is saying, have you looked at ways to automatically rebalance your channels or is that still a manual process?
At the moment it's manual. I haven't built in a lot of say disaster recovery and automatic managing of channels and stuff like that. But I've got enough capacity for the alpha and the beta; not a lot of people are using this yet. For now, it's fine, but I will need to take some steps to automatically get some incoming capacity or just rebalancing entails sending funds back out. So, I still need to look at that. Ben has as a question. Just unmute yourself, Ben.
Ben Blaine 26:24
Sorry, I'm driving, so I can't put my video on otherwise you're going to probably freak out. But I'm hands-free driving. As far as I understand with Lightning payments, you kind of open up a channel and then you can do back and forward payments for like no fee, […] I've got my user-experience or like my I don't know what hat on, but I've got a hat on and it's making me think, can you do loyalty payments?
So, I go to a coffee shop, and then the coffee shop says if you put aside – it's R10 a coffee – like R100 upfront or R100 in Bitcoin in a channel and then move over R10 every time you get a coffee, then we will move back R10.
So, you kind of show the money upfront. And then you can also like let's say, this is a bit of a schlep, so maybe we'll give you a cookie if you do this, but it kind of commits you. It's like almost a loyalty programme in a way. Is that like silly or is that possible with these Hold receipts as well? Or is a Hold receipt only, you pass like a set amount across and then you get that same amount back? Or is it the same as a Lightning channel basically?
Carel 28:34
So, the Hold invoice, it's a normal Lightning invoice, or not normal, but it's basically a Lightning invoice and so there'll be an expiry time attached to it. So, you can't really; it's not realistic for long term. And as far as I understand, you can correct me if I'm wrong, but as far as I understand, it's for the same amount, you can't send a different amount back.
But I mean, Lightning itself is still being developed and so there might be potential if you can give them your… Okay, so one of the things that's still being developed is like a static code or a static address where you don't have to generate an invoice each time, and then maybe if you can provide that to them somehow. If they've got that, then sending you something to that address will be trivially easy
Ben 29:23
Okay, cool. That's just an idea that I had of like managing loyalty programmes using Lightning, because I mean obviously there's this thing of like, yeah, I can pay instantly with Lightning but all my Bitcoin is on the Bitcoin network. So why would I move it to the Lightning network? Basically, it's like a bit of a problem.
Carel 29:41
You want to get Lightning when you buy a coffee and then they give you a little extra loyalty or something like that.
Ben 29:46
You want to incentivise users to move some Bitcoin to the Lightning network, for future. Otherwise, to begin to start paying in Lightning every time, I first have to move to the Lightning network.
I have Bitcoin which is currently sitting on the Bitcoin network, as far as I understand. So, I was just thinking of ways to incentivise people to move like funds. The other idea I had is you have an automatic bot, which keeps your Lightning wallet topped up at a certain level. So, it's like, if it goes below, like R1 000 in Bitcoin, it just automatically moves money across, so you've money in your Lightning wallet?
Carel 30:26
Yeah. Yeah, there's this whole discussion around that as well. I'm going to move on. Malan ask something. Do you think there's use case non-money-laundering?
Non-money-laundering. [Laughter] Or plugging it into a cash-send API, get cash at an ATM from a code. So, you mean, you'll send Lightning somewhere and then you can withdraw …?
Malan 30:53
Instead of purchasing electricity. You can sort of like basically push cash? I don't know if that's completely dumb or cool?
Carel 31:04
Yeah, I guess if there's […] depends on what ATMs you want to use? I know Standard Bank had that you could actually issue ATM voucher pins …
Malan 31:17
Yeah, I mean. One of those API's. Like just, do you think there's a [inaudible] assuming you have those voucher PIN API things? And you could just …
Carel 31:26
Yeah, I'm kind of afraid of that. I feel like it's going to open up a can of worms because people, they might abuse it. Like you say, money laundering, tax evasion, that kind of stuff. I'm not pro tax evasion. I think if you're a service provider, offering that service, you're just going to have to be careful. But, I mean, there's no reason you can't do it.
Devina 31:50
Couldn't you use the same sort of static, that static address the same sort of way that you do it as rewards, you can use that same sort of mechanism, or a kind of a card-redemption cash thing.
Carel 32:11
Again, if you have a static address, but I think that stuff is still being worked on; it's not so easy. There are some ways, but it's not so easy. And then somebody asked, is similar to a credit-card fund reservation. […]
From my simplistic understanding, it's similar in the sense that the merchant has the option of … The funds are reserved, which means the merchant has some guarantee that they'll get it, but they can cancel it or they can receive.
So, it's very similar to that in terms of the flow. How has privacy increased in Lightening versus normal Bitcoin transactions? There's a long discussion around this. I'm still reading up on this myself. So, one thing is that it's not necessarily increased, because it's online, and node-to-node interactions. People use Tor to run their [inaudible] nodes, and to connect to other nodes to hide their IP addresses so they can try to remain private. In terms of public ledger visibility, obviously, the visibility of that transaction over the Lightning channel is no longer available to the rest of the Bitcoin network. So, there's some privacy there.
So, I think there's, in terms of privacy, some pros and cons. But I'm still reading up on that myself. And do you plan on monetising this beyond channel costs? Or is that built into the on-the- fly pricing bill? I did build in a little, a little variable to set the profit margin. But right now, it's basically 0.1%, which is the Luno market maker trade fee.
Even though I'm not converting it to rands, if I wanted to convert it to rands, without paying any fees myself, basically not losing any money, I can do that. I can bump the margin up to 1%, 10%.
But then I doubt anybody's going to buy electricity at a 10% mark-up. Right now, this is more like a business card. It's like, hey, I've built this technology; it's working; it's really cool. If I take it further, then I'll use this as a demo or a proof of concept and show like the usage on it to say, well, it can work for any merchant integration.
And then, if I do that, then I can add, you can generate revenue, either by literally just invoicing the merchant on each transaction. Or you can play around a little bit with the exchange rate – there's always variability in the exchange rate – and maybe generate revenue like that. There's two options [inaudible] [not saying I've] decided on anything yet. Huh?
Meeting is being recorded ... Yes. [Laughter] I'm not pro tax evasion. I mentioned in the initial slides that disintermediation is the goal. There is some regulations that I definitely do not agree with, in particular, exchange-control regulations. I've done a lot of reading and thinking about it. And if anybody's interested in chatting about that, we can talk for hours.
Devina Maharaj 35:26
Because you are all on the Slack group, so everyone can hit you up there. So, it's all good.
Carel 35:32
How much time do we still have? Still time for more questions?
Devina 35:36
Yeah, we can take one more, if there is any. Did we cover everything? The legislation, any questions? Is there anything else?
Carel 35:43
There are two.
How long does the receiver have to commit the transaction and does the merchant have the ability to refund the transaction later, say three months later?
You can set an expiry time of three months, but it probably won't be a good idea. Typically, let's say typically 15 minutes, the merchant defines that expiry window. We can make it an hour; we can make it a day. But there's some trade-offs in making it longer, specifically, volatility.
We've calculated the Bitcoin amount on the fly, but if we wait a day, then that amount would very much likely changed. And somebody is taking a risk there, in terms of currency risk or exchange risk. So, it's not really good idea. And then in terms of refunding later, if it's beyond the expiry window of the invoice then it needs to be a separate interaction.
What are the legalities of shaping fiat for crypto in this instance? Basically, are you currently the exchange? Or is your provider doing the accepting? Well, like I said, I'm not exchanging the coin at the moment. I've got a rand balance. For me, this is a way to earn some Bitcoin. I'm not sure if there's any problem in … Okay, there's some subtleties around where the Bitcoin comes from. But I'm not going to get into that. That's a very long discussion.
So, Byron, if you're interested, we can definitely talk about this later. There are some interesting things around it. But basically, at this point, I don't really give a fuck, because it's so small, and the regulators need to catch up. This is the future. So, whatever. And Malan says, […] for something like internet access [inaudible] for day makes sense and margins high? Yeah, like, what you can do there is …There's some things there you can do …But I don't know if you'll use Hold invoice mechanism for it. I think, yeah.
There's some people that are working on streaming Lightning payments, so that it's this interaction that we saw now is being done in very small increments, and continuously, but there's still work being done on the client side implement. So, payment streaming might become a thing and that might be nice for internet access, where you stream while you're using the internet.
But it's not available yet. I've also got questions for the Investec guys. I don't know if there's time for that
Devina 38:34
Yeah, please […] what do you need?
Carel 38:40
So, like I said, one of the problems is I want to keep the provider balance topped up, otherwise, I need to monitor it constantly and manually top it up.
So, I started working on the Investec API. And I got to the point where I can check my balance. But I see it stops there. So, is there any way to actually to use the Investec API to make payments to beneficiary?
And then there's another problem, if that's possible, and that is if you have a lot of Bitcoin and you want to deplete my rand balance, my bank balance, you can just buy a ton of electricity vouchers. I mean it's going to cost you money to bankrupt me, but you could theoretically do it. Is there a way to manage the limits and stuff like that? I don't know if there is an intelligent way of managing that kind of risk.
Devina 39:41
If Hennie or Johan would like to step in?
Hennie Spies 39:48
Cool. I'll jump in in terms of the first section. On the cards, obviously what the community has been asking for, is payment endpoint, like being able to do beneficiary payments, make transfers etc. I'll get to that and where that's on our roadmap.
And then from limiting that account, you probably could set up limits for that account or use a separate account and transfer spend limits into that account once the transfer APIs are online. So, I think there is definitely ways in which to manage your risk, manage the exposure.
Devina 40:46
I just wanted to ask, for limiting the amounts that get transferred out, is it more out of your account that you are looking, than from the Investec account? Because I guess I'm trying to understand ... We currently have different spend limits that you can put onto your card manually.
Or we can think about, like from a backlog perspective, adding things specifically to the programmable bank account that could potentially help. I'm just trying to understand where ... is it specifically on your personal account that you would want to limit the transactions? Or like, is it rand volume? Or like value transactions? What is the ask?
Carel 41:33
Okay, so the first question, my personal account, ideally, the next steps are opening an Investec account for this app, or for Crypto Convert. And then enabling programmable banking for that.
And then maybe having like a separate account, like Hennie suggested, for the app, so that the app has as its own Investec account, maybe? That makes a lot of sense to me. That's a good solution. Otherwise, I mean, the business account. It's a good way to keep the funds separate as well. And then it would be ... I guess, I would have to set up some rate limits in terms of the amount of volume being done on the app.
So, the [number] of transactions going through the app, and how quickly I can respond to the balance running out.
Devina 42:25
What's interesting, and I think we've had a lot of clients, especially from a business perspective, talk about a similar type of set-up, where they don't want to keep all of their funds in the account that is used for the day-to-day transactional running, and Hennie will speak to the Transfer API that we currently are staging or then hopefully, he'll talk a little bit more about it.
But I think the idea is, is that where you need to manage the cash flow within different accounts, either for risk reasons or for other business reasons, the idea is you use the Transfer API and set up rules that says once it gets to a certain limit, or below a certain limit, you transfer funds in between, so that you kind of manage that cash-flow mechanism. I think there could be some cool things that you could do with the stuff that's coming soon.
That Hennie will speak about. I don't want to steal his thunder here. But that's next on the agenda.
Yeah, I think there could definitely be stuff. I'm happy to take it offline. If you want to talk through what the business account like can and cannot do, and see if it meets those needs, just pop Nick or myself [an email] and we can chat offline.
Carel 43:41
Thanks a lot. Cool. That sounds like it's good timing as well.
Nick 43:49
Carel, thank you very much for the demo. Really cool.
Get involved in the Programmable Banking Community
If you have questions or just want to say hi to the Programmable Banking Community core team, you can pop us a mail and we will get back to you.
If you want to see more from what the community has been up to, you can: