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.

3 Likes
Rootstock Collective Governance-at-a-Glance 26-02-27
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.

2 Likes
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?

1 Like
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.

1 Like
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!

2 Likes
7

Hi @DAOstar_gov thanks for your questions. I’m happy to share some observations from operating the machine and my research in this sector.

From an operator perspective, the limitations of a Lightning-only model have been mostly practical rather than ideological:

1. Liquidity & centralization realities

In practice, many Lightning ATM deployments operate as part of centralized chains to ensure channel liquidity and reliability. This makes sense operationally, but it reduces per-machine autonomy. Running a single self-managed Lightning ATM with stable liquidity is not an option for most small businesses.

2. Channel management overhead

Even when abstracted through software, inbound/outbound capacity constraints and rebalancing introduce operational complexity. It’s manageable - but not trivial.

3. UX variability

The user experience depends heavily on the wallet being used. Invoice generation, expiry, and wallet compatibility can create friction, especially for first-time users who expect a simple address-based interaction.

Overall adoption has been steady but niche - mostly Bitcoin enthusiasts and business owners seeking to offer a cash on-ramp. Lightning works, but relying on a single transaction layer limits flexibility.

This is where my interest in Rootstock comes in - not as a replacement for Lightning, but as a parallel layer.

If rBTC were used, it could potentially allow each ATM to operate with greater autonomy, holding and managing its own liquidity directly on-chain.

I’m particularly interested in whether Rootstock smart contract architecture could support self-managed machines, with the aim of reducing reliance on centralized liquidity hubs while still maintaining operator control and treasury logic.

The ATM is a practical testbed for this broader question:

Does Bitcoin infrastructure in physical environments benefit from multi-layer optionality and greater per-device sovereignty?

In other words, could rBTC as a payment layer, both for onboarding via ATM and in P2P transactions generally, become the preferred way to transact?

Its early days, but @wesatoshis card seems to indicate this could be the case.

Looking forward to thoughts from those more experienced with Rootstock smart contract design.

1 Like
8

This is an interesting question that I think the @wesatoshis team is best positioned to answer. Let me try to get a hold of them!

2 Likes
9

It’s great to see explorations that bridge Rootstock with physical infrastructure, @blankworker1 . Exploring a multi-layer approach where rBTC acts as the sovereign settlement layer for these ATMs is a highly worthwhile thought experiment. Additionally, to maintain that “simple address-based interaction” you mentioned, how do you foresee handling rBTC gas fees for first-time users?

2 Likes
10

Thanks @Eren_DAOplomats that’s an important question.

For a cash-to-rBTC ATM targeting first-time users, I wouldn’t expect the user to manage gas directly. The most practical approach, at least initially, would be for the ATM to abstract gas entirely and price it into the spread , similar to how network fees are handled in many on-chain Bitcoin ATMs today.

From the user’s perspective:

  • They insert cash
  • They receive rBTC at a quoted rate
  • Gas is embedded in the transaction cost

Longer term, there are more interesting possibilities:

Operator-paid gas model : the ATM funds the transaction directly and internalizes gas costs.

Pre-funded wallet model : the machine could send slightly more rBTC than purchased to cover immediate usability.

Smart contract-based abstraction : potentially using a contract architecture that centralizes certain gas logic while preserving per-machine autonomy.

The guiding principle for me is that first-time users shouldn’t need to understand gas mechanics at all. If rBTC is to function as a practical parallel layer in physical environments, the complexity must remain invisible at the interface level.

I’d be very interested in hearing whether there are any existing Rootstock-native patterns or tooling that make this possible from a smart contract design perspective.

1 Like
11

Hi @blankworker1. Thanks for sharing the operator insights. The Lightning limitations you described are helpful context.

We still think the key question hasn’t been answered: who is the target user, and what are they onboarding into?

You mention “onboarding,” but onboarding to what, specifically?

  • Holding rBTC as savings?
  • Using Rootstock DeFi?
  • Paying merchants?
  • Remittances?
  • Something else?

Right now the exploration feels architecture-first. For this to move forward meaningfully, it needs to be user-first.

It would help to clearly define:

  1. Primary target user segment and geography
  2. The concrete job-to-be-done
  3. Why cash → rBTC is better for them than Lightning or exchange-based on-ramps
  4. What drives repeat usage rather than a one-time transaction

Without a defined user journey from cash insertion to final outcome, it’s hard to evaluate whether rBTC as a parallel layer solves a real problem or just adds optionality.

2 Likes
12

Hi @Tane

I agree that user experience is the ultimate test. Infrastructure only matters if it improves the reliability, predictability, and simplicity of the user journey.

So the question isn’t whether rBTC is interesting architecturally, but whether it meaningfully improves the experience from cash insertion to completed transaction.

The fundamental technical distinction I’m exploring is this:

Lightning requires channel relationships and active liquidity coordination. An ATM must be properly connected, funded, and routable for a transaction to succeed.

So today the user journey looks like:

1. Insert cash

2. Generate Lightning invoice

3. Transaction depends on routing + liquidity condition

If those conditions aren’t met, the transaction fails — for reasons the user cannot see or understand.

The user doesn’t care about channel topology. They care about predictable execution.

If rBTC is used instead, the journey becomes:

1. Insert cash

2. Provide address

3. ATM signs and broadcasts transaction

No channel coordination. No routing dependency. Only local balance required.

So the core question becomes:

> Does removing channel coordination from the transaction path meaningfully improve reliability and autonomy in physical Bitcoin infrastructure?

If it does, then rBTC isn’t just optionality — it represents a structurally different operating model.

That’s the hypothesis I’m trying to test.

The users would likely be the same ones currently using Lightning payments — Bitcoin holders seeking a fast, practical way to convert cash into a self-custodied digital asset.

The difference isn’t who they are, or what they use the platform for, but how reliably the transaction infrastructure serves them. If the underlying mechanism becomes simpler and less dependent on channel coordination, the experience may become more predictable — without requiring the user to understand any of the mechanics behind it.

1 Like
13

Hey @blankworker1! I’ve been following the thread and I like seeing conversations like this. These ideas can become strategically useful for the Collective.

I prepared a deep research, focusing on the real constraints: liquidity/refill, bridge mechanics (PowPeg vs Flyover), operational dependencies, and compliance risk. Here it is: [LINK]

TLDR:

  • Removing channel coordination can make transactions more predictable at the ATM. Instead of depending on Lightning routing, the machine mainly depends on having enough balance and being able to broadcast a transaction.

  • But autonomy doesn’t magically increase, the dependency just shifts. Instead of channels, you now depend on liquidity refills, bridge reliability, RPC uptime, pricing feeds, and regulation.

  • The real bottleneck isn’t gas abstraction. It’s liquidity strategy and legal feasibility in the target country.

  • A hybrid model (Lightning + rBTC) is probably stronger than choosing only one rail.

So yes, the key question raised here is the right one:

Does removing channel coordination actually improve reliability in physical Bitcoin infrastructure?

And I’d add one more:

Which concrete actors need to be involved to make this work in practice?

Because this only moves from idea to pilot if the right players are at the table, liquidity providers, ATM operators, infra providers, and compliance-aware operators.

Happy to keep the discussion going.

1 Like
14

Hi @Kaf_Anode I have read your review and really appreciate the depth of your analysis - especially the framing around hybrid architecture and the liquidity constraints.

The point about the Cash → rBTC → Lightning invoice loop stood out to me. That feels like a more complete ecosystem narrative than positioning rBTC as a standalone alternative rail.

If a hybrid ATM offered:

  • Lightning for instant small payments
  • rBTC as an address-based, sovereign settlement option

And integration with Wesatoshis card (or something similar) for spending via Lightning , then the ATM becomes more than a cash-in device - it becomes an entry point into a flexible multi-rail Bitcoin stack.

This raises a practical design question I’d be interested in exploring further:

What would an integrated user journey look like if the ATM and a Wesatoshis-style card were intentionally designed together from day one?

For example: Cash → rBTC at ATM → immediately usable via card for LN payments

Or

Cash → Lightning directly (depending on amount or user preference)

I’m curious whether this kind of alignment would make the hybrid model not just operationally safer, but strategically stronger for the ecosystem.

Happy to explore this angle further if others think it’s worth digging into.

1 Like