External Liquidity Tools & Auto-Pricer for Makers

[dakshhhhh16]

Hello @KoalaSat ,

My name is Daksh, and I’m an Instrumentation & Control engineering student who’s been exploring RoboSats with the goal of contributing. I am an active open source contributor with more than 80k lines of code merged.

What I’ve noticed

While experimenting with the Maker experience on Testnet, I realized that staying competitive as a Maker often requires constant manual adjustments. When the market moves sharply, a fixed premium can quickly become unprofitable or uncompetitive, which sometimes forces Makers to pull liquidity altogether.

Idea

I’m thinking of building a standalone Liquidity Management Tool (in Python) that interacts with the RoboSats backend and helps Makers truly “set and forget” their offers.

Planned features

• Dynamic pricing
  Automatically adjust order premiums based on live price feeds
  (for example: “always maintain a +1.5% spread over Kraken”)

• Circuit breaker
  Automatically pause offers if BTC price volatility exceeds a defined threshold (e.g., X% within 1 hour)

• Inventory awareness (stretch goal)
  Adjust sell orders based on the Maker’s local Lightning node liquidity

Technical approach

Since there isn’t a public API specification yet, my plan is to:

• Reverse-engineer the required RoboSats API endpoints
• Wrap them in a clean Python client
• Handle Tor connectivity via SOCKS5 proxies to ensure privacy is preserved throughout

Some specific topics I'd like to have an opinion:

• Is there already an effort to build official Maker-side tools that I should collaborate on instead of starting something new?
• Would the community prefer this as:
  • a standalone CLI tool, or
  • something integrated directly into the main RoboSats repo?

I’m currently setting up my local development environment and would really appreciate any feedback on the feasibility, direction, or potential pitfalls of this approach.

Thanks for your time
Best,
Daksh

[KoalaSat]

That's a really cool idea @dakshhhhh16 , happy to support in anything you need.

Maybe something important you should be aware of: I'm starting to work on this #2342 , as you see, it requires 0 modifications on back-end but it's possible you'll become outdated if you don't keep it in mind. I am thinking you can just start working with a simple robot token but keeping in mind at some point you'll probably need to include the garage key management.

[dakshhhhh16]

I just went through the specs for #2342 .

The key takeaway for me is that the backend API remains unchanged (it still expects the final derived robot token), so my reverse-engineering of the endpoints remains valid.

To future-proof the tool, I’ll architect the authentication module in a way that can later accept a Garage Key (Bech32) and handle the client-side derivation locally (m/44'/88'/n'/0) to generate the required session token.

For the MVP, I’ll stick with raw token input to get the core logic working end-to-end, but I’ll keep the dependency chain structured so that Bech32 decoding and BIP-32 derivation can be added cleanly at a later stage.

Working on the first PoC now!

[dakshhhhh16]

@KoalaSat
I have opened a pull request related to this #2362.
I'll proceed further if it aligns with the needs of robosats