Greetings! I recently found this community, happy to be here. I’d like to share an open source regtest implementation built recently to explore the programmability of Ark. It has two main POCs:
ArkSwap - trustless atomic swaps between Ark and L1 Bitcoin. It uses Taproot HTLCs to show that ASPs can blindly mint VTXOs to any valid script hash, pretty much enabling permissionless smart contracts.
SatoshiKoi - an Ark Assets implementation that shows how we can cryptographically bind metadata to a VTXO using double key tweaking.
Happy to discuss or share any thoughts behind the decisions. I had started building a third piece but think I will move on to build a toll that integrates the Bark SDK.
Hey, welcome to the forum! You’ve got some interesting ideas that I’ll be sure to look into sometime this week. I’m particularly interested in trying out your ArkAdmin project. barkd is a project we have a lot of hopes for so any frontends for this are very much appreciated.
I’ll update the readme with a roadmap soon so it’s more clear where things stand and happy to incorporate any feedback. I added a walkthrough of the main features that are working currently. It’s been fun building on top of barkd on signet, nice work!
I made a quick Loom to walk through some of the features of ArkAdmin. I didn’t demo everything but it’s a solid overview. I will write up a dev experience audit in the coming days.
Sorry for the late response @jgmcalpine. The wrapper looks great, you’re honestly pioneering a bunch of things on wallet UX that even we haven’t had time to consider.
I only really have some nits on UX:
I increasingly think it’s better to frame “cooperative exits” as just on-chain/Lightning spends, rather than try to make potentially confusing distinctions between “cooperative” and “emergency exits” (which is probably a more user-friendly term than “unilateral exit”). Even just the term “exit” should probably be reserved for triggering the broadcast of a VTXO’s pre-signed transactions—that’s why we use “offboard” to refer to (cooperatively) spending all a wallet’s bitcoin over on-chain or Lightning.
Similarly, I would reframe “deposit/onboard” as just “board” and keep it in the coin management page. It’s relatively advanced operation of turning on-chain bitcoin into off-chain bitcoin that hopefully most users will never need to do, and they definitely shouldn’t conflate it with receiving of VTXOs (which they might consider “deposits”). “Boarding” might make it more clear it’s a pretty specific operation in the context of the Ark protocol.
Thanks for the feedback! I agree regarding the mental models and just pushed an update to align the UI with that language.
Your point about most users not needing to board actually fits perfectly with the rest of the suite I’ve been building since that last video. I’ve expanded the repo to include ArkPOS (a retail PWA) and ArkFetch (a self-hosted developer API) to show how we can skip the manual boarding step entirely via instant inbound liquidity.
I’ll record a new short walkthrough to demo the full stack and the updated UX and will drop it here soon.
That looks nice! Have you considered using a BIP-(3)21 URI to make the QR code universal?
Like bitcoin:?lightning=<bolt11-invoice>&ark=<ark-address>. We’re expecting Ark-enabled wallets will be able to handle these correctly and pick ark when possible.
About the DX report, it seems that most of the issue you encountered are things we are aware of or were aware of and have already been improved. We know there are a few more rough edges to work out, hopefully your experience improves with the new few releases!
That’s a great call on BIP-21. Merging them into a single URI and pushing the decision complexity to the wallet rather than the user is definitely the cleaner UX compared to the manual toggle I have now.
Glad to hear the DX friction points are already on the radar/resolved. Navigating the rough edges is part of the fun of building this early, and it’s great to see the velocity of the releases!
Love that change! It helps clear up the confusion between ‘leaving the layer’ vs ‘forcing the protocol’. I think it also more clearly signals there are tradeoffs between the two.