Branta's Approach To Bitcoin Payment Address Verification: Triangulated Security \ stacker news ~AGORA

pull down to refresh

Branta's Approach To Bitcoin Payment Address Verification: Triangulated Security

258 sats \ 9 comments \ @BrantaPro 13 Nov AGORA

Disclosure: An earlier version of this post was published two days ago. It was withdrawn for revisions to improve clarity and accuracy.

We've been building something at Branta called Guardrail…. Address verification for Bitcoin. The goal is simple: remove doubt from Bitcoin payments.

Guardrail lets a payer verify that a Bitcoin address on their screen belongs to the intended recipient. We’re using zero-knowledge verification for on-chain, so the payer can confirm authenticity without exposing the plaintext address (or invoice).

Businesses using Guardrail automatically send the encrypted address to the Branta API (which expires after TTL seconds) when they generate a new invoice. Users can verify the address from any device.

Here are 2 demos: Demo 1 Demo 2

Why? Because compromised screens, swapped addresses, man-in-the-middle-attacks, and bad browser extensions are currently undetectable . Guardrail aims to make “is this address legit?” a question anyone can answer deterministically.

Branta is already live as an API for merchants (e.g., BTCPay, Zaprite, others).

Wallet developers can integrate Branta into payment flows so users can verify any QR code or pasted address and display the result ("Verified" or "No verification available") before sending.

Integration for wallets is seamless. No coordination or permission from Branta is necessary.

We would love feedback, critique, skepticism, or to answer any questions. Some things we're curious to hear your thoughts on:

How useful would address verification be to you personally or for your users?
Any red flags or attack surfaces you think a ZK-based approach might introduce?
How could this integrate naturally into wallet UX without adding friction?

Thanks in advance.

view all related items

0 sats \ 4 replies \ @k00b 13 Nov

For a receiver, having a verified address means associating the address (with some kind of zk stuff) and metadata through Branta, and for the sender, verifying an address means asking Branta if such metadata exists, right?

How are you vetting the receivers when they register? ie what's stopping someone from pretending to be Satoshi Coffee Co by registering metadata and addresses with Branta?

50 sats \ 2 replies \ @keith_gardner 13 Nov

Hi k00b! Good seeing you at tab

Keith, founder here.

yep! metadata optional. address can be blinded (so branta never sees them, we recommend this). All addresses are purged after a TTL (usually 1 hour, sometimes 1 day - receiver decides.)
Funniest outcome would be for North Korea to signup as Coinbase. Welcome folks to try. Few things I'll share:

Onboarding is high touch.
Email verification
DNS / Domain ownership. We manually approve businesses, its not full self serve to register.

50 sats \ 0 replies \ @Scroogey 13 Nov

It seems easy to prevent for Coinbase.

But what if you get a sign-up from a small local business in Uruguay, from domain xcoffee.com.uy for string "XCoffee" with logo "XCoffee"? You check DNS ownership automatically, email, external SSO, etc. Great.

You even have an employee check their web site and check the string and logo. Fine.

But what you don't know is that there is a real local business called XCoffee with that logo operating, but on domain x-cafe.com.uy, and the request is coming from someone targeting their customers.

How will you prevent that, without hiring hundreds of human investigators as you scale?

DNS registrars have the same problem (if they even try), it's not easily solved.

0 sats \ 0 replies \ @k00b 13 Nov

Thanks for clarifying!

0 sats \ 0 replies \ @keith_gardner 13 Nov

test response w Github SSO

0 sats \ 0 replies \ @AGORA 13 Nov

Are you planning to offer it as a paid service in the future? I mean, building, maintaining and running infrastructure has a cost, how you'll make this business sustainable?

What's your goal and how you see BrantaOps in 5 years?

How useful would address verification be to you personally or for your users?

It will be definitely useful for building trust, not only in B2C relations but also with bitcoin payments in general

How could this integrate naturally into wallet UX without adding friction?

From a user perspective, a simple notification saying "receiving address verified successfully" would probably enough. Merchants could also display a trust badge in websites and stores saying Branta-verified commerce.

0 sats \ 0 replies \ @AG0RA 13 Nov

🤙 crossposted to nostr𓅦: https://njump.to/note13ef4d6v0nqrs5zywhd5kewkmxvkfuaypne5t5g3yydyes6uut3aq4pp7tc

... and 𝕏: https://x.com/AGORA_SN/status/1989022799256748272

0 sats \ 1 reply \ @AG 13 Nov

This is interesting, thank you for sharing.

So how merchants can benefit from BRANTA? Do you have any guide on how to set it up in BTCPay, Zaprite, and others or a developer is needed for the implementation?

Businesses using Guardrail automatically send the encrypted address to the Branta API (which expires after TTL seconds)

Why should a business put a tag with their business name on (tinting?) each generated address? Isn't this like auto AMLing somehow?

Does verification for on-chain addresses, mean you do NOT keep any data received via API? or it's stored somehow somewhere? And even if so, how do you possibly know if a vendor is authentic or an imposer?

0 sats \ 0 replies \ @keith_gardner 13 Nov

Hello! I'm the founder.

Here are docs for BTCPay: https://developer.branta.pro/guardrail-tech/btcpayserver-plugin-setup

We need to make Zaprite docs. It's a no-code Connection within Zaprite; turn it on, drop in an API key.

Developers are needed for custom integration, but its pretty straightforward.

Re AML; With ZK, Only sender/receiver know the receiving and sending address, Branta doesn't. Branta is not queryable in the sense that other parties can do lookups.

Answer below on Imposters