Rootstock ATM : Cash to rBTC integration

General
1

I’ve recently joined the Rootstock community and wanted to introduce a project I’m exploring.

I’m looking at ways to integrate Bitcoin into the physical world, specifically through cash-to-bitcoin ATM–style machines. The current concept builds on an existing Android tablet based ATM that exchanges Lightning sats for cash.

I now want to explore how rBTC on Rootstock could be used instead or alongside LN.

I’ve created a ROOTSTOCK ATM repo with a README outlining the motivation and high-level goals, and a software/requirements document describing the system at a conceptual level (non-code).

At this stage, the project is exploratory and architectural, rather than a finished implementation. I’m especially interested in:

  • Feedback on the overall approach
  • Rootstock-specific considerations I may be missing
  • Pointers to best practices for rBTC handling in physical infrastructure

I have been following @wesatoshis project WESATOSHIS card with interest, and believe that there could be ways for the ATM and Card to work together.

Keen to learn and engage with the ecosystem, so any comments or suggestions are welcome.

2 Likes
Rootstock Collective Governance-at-a-Glance 26-02-13
2

This is a fresh and interesting project @blankworker1

First of all, I encourage everyone to first read the README file in the linked repo, as I had a totally different impression just from the forum post, which paints just an ethereal idea. The documentation is actually developed and paints a clear picture of the project.

K1’s track record operating 150 ATMs in El Salvador is respectable, and the non-custodial architecture with local key management on each device shows thoughtful design and a nice decentralization ethos.

I’ll start by saying I’m confused about your relationship with K1. Are you the owner, an employee, a partner, or proposing to build this independently? If you’re not the owner, does K1 acknowledge and support this project?

A few questions I’d like to point, and ask if they were thought about:

Due to the transaction flow and decentralization if I’m not misaaken, the ATM needs to have rBTC to sell, but there’s no mention regarging liquidity providing.
The PowPeg process for converting BTC to rBTC isn’t trivial. Is K1 providing liquidity? Is there a treasury management strategy for keeping ATMs funded across 150+ units to start with, plus expansion?

The README mentions a “lightweight Rootstock node or SDK” but running full nodes is hardware intensive, and I imagine the 150+ ATM hardware is very lean/streamlined. Has this been though about?

Operating cash-to-crypto infrastructure across multiple jurisdictions must be compliance intensive. El Salvador has bitcoin as legal tender, other juristictions dont. Has this been thought about?

And lastly, I imagine El Salvador usage of cash for day-to-day transactions is still high?
Other juristictions like Brazil, cash usage has been reduced to almost zero. I don’t know how are the other countries in Latam handling day-to-day payments these days. Curious to know your thoughts on this regard.

1 Like
3

Thanks @ChronoTrigger for the thoughtful reply. I really appreciate you taking the time to read the README and engage seriously with the project.

To clarify my relationship with K1: I’m not an employee or owner of the company, but I own and have run limited trials with the first K1 ATM shipped outside of El Salvador / the US.

Through operating the machine, I’ve explored its functionality in practice and become familiar with some of the limitations of a Lightning only model, which is what motivated this post. Although I am in contact with the K1 team , this project is independent and exploratory, and does not represent an official K1 roadmap.

On your questions:

Liquidity & rBTC availability

You’re absolutely right that the ATM would need rBTC available to sell. Liquidity provisioning and treasury management are intentionally not fully specified yet . This is one of the core open questions I’m hoping to explore with the Rootstock community. The PowPeg process adds real operational complexity, and whether that tradeoff makes sense in a physical ATM context is part of what I’m trying to understand.

Node / SDK considerations

Agreed that running full Rootstock nodes on ATM hardware is unrealistic. The README compresses several possibilities here - more likely options would involve lightweight clients, trusted RPC providers, or backend services. This is an area where Rootstock best practices would be very valuable.

Compliance & geography

El Salvador is clearly a special case. Any real deployment outside it would need to adapt to local regulatory environments. The document doesn’t attempt to solve compliance, but assumes jurisdiction-specific handling.

Cash usage trends

Cash usage remains significant in El Salvador, while countries like Brazil (and others in Europe) are rapidly moving toward digital payments. That contrast is part of the question for me: where do physical on-ramps still make sense, and for how long?

Overall, this is an attempt to map the problem clearly rather than claim finished answers. Your feedback is very helpful in shaping that exploration . Thank you.

1 Like
4

Hi @blankworker1, thank you for sharing this early-stage project idea. Before addressing your feedback ask — on approach, Rootstock-specific considerations, and best practices — I’m curious whether you’ve done any market research on Bitcoin ATMs. Specifically: What is the size of the market today? How does it compare to prior years? And which geographies have the highest concentration of Bitcoin ATMs?

5

Hi @Axia thanks for raising that.

From the publicly available ATM trackers, the market today appears concentrated mainly in the US and Canada, with smaller clusters in Europe and parts of Latin America. Growth was strong in earlier years and has moderated more recently, especially as exchange-based and mobile on-ramps expanded.

That said, the core aim of this project isn’t to optimize the Bitcoin ATM business model itself. I’m more interested in exploring whether rBTC on Rootstock could operate in parallel with Lightning as a secondary transaction layer for Bitcoin infrastructure.

The ATM is simply a practical, real-world hardware device to test that idea using a physical onboarding point. Longer term, the concept could extend beyond ATMs to POS terminals and other cash-facing infrastructure.

So for me, the key question isn’t just “How big is the ATM market?” but rather:

Where does a parallel Bitcoin transaction layer (alongside Lightning) make architectural sense in physical environments?

Would be very interested in your thoughts from that angle.

6

Hi @blankworker1,
I’ve read through the initial post, the README, and the discussion thread. Thank you to @ChronoTrigger and @Axia for their questions - they’ve helped clarify some aspects, but I still have questions that might advance the conversation.
You’ve reframed this as exploring:

Your hands-on real-world experience is super valuable and could really help us understand the opportunity here,

Are you able to share a bit more about what you’ve learned?
What specific limitations did you as an operator and your users run into with Lightning?
How’s the ATM performing for you? in terms of user adoption and profitability for you? Is it meeting expectations? (Not asking for specifics, of course - just broadly)
What’s the user experience been like? Who’s actually using it in your location?
What are they using it for? Any patterns or surprises in how people interact with it?
Are you seeing any unmet needs that Rootstock features might address?

Looking forward to hearing more about your experience!