Exploring decentralized, post-blockchain financial transactions on ATProtocol. Built on DIDs, signed attestations, and mutual revocation - no tokens, no chains. Technical outline below. 🧵 #ATProtocol #atdev
Comments
Log in with your Bluesky account to leave a comment
I'd like to push back on this idea because it recreates what is dangerous about public blockchains for payments. Why would we want so much of our purchase history published to world?
I'm not advocating that all transactions be made public this way. I'm saying that I believe there are use cases that offer benefits in some situations.
It also creates an interesting trust dynamic. For you to "own" a digital copy of your receipt that you can use to prove a transaction, it gives you incredible power in holding sellers accountable.
I'm a fan of this idea of owning a digital proof receipt of purchase so long as I have full control over how data is disclosed. (eg. being able to show proof of payment to access a service without needing to disclose additional identity information.)
Could be. If I wanted to prove that I purchased a collectable from you, I could create the invoice, give you cash, have you sign the record, and then publish the update.
Yeah the signature that comes from the seller is generated after payment, and the buyer updates their invoice record with it. The signed record in aggregate is the "proof of payment".
A buyer creates an invoice record with metadata (e.g., SKU) and a random nonce. This record is published to their PDS and announced via relay for intent discovery.
The buyer shares the AT-URI (e.g. at://did:plc:xyzbuyer/community.lexicon.transactions.invoice/1b758b2d2799) out-of-band. This acts as a verifiable purchase request that any seller or app can observe and respond to.
Upon payment, the seller signs the invoice recording -- this includes fields like nonce, product, and status. Buyer can inspect and consent to the signature. If everything matches, the resulting signature is appended to the original invoice record.
The seller can publish a separate revocation record tied to the signature. This creates an auditable revocation trail for refunds, disputes, etc., without mutating prior records.
Consumers of the record (AppViews, APIs) validate seller signatures using DID Document keys. Status checks are cryptographic, portable, and infrastructure-agnostic.
Yeah, and I said something to this effect in another thread, but I don't think that it's reasonable to expect *all* transactions to be on-protocol in this way.
Comments
1. How does the buyer deleting the invoice record work? It seems like (a) tracking firehose events and (b) replay?
I suppose this is also managed by the payment processor + stripe webhooks.
The payment processor is almost irrelevant.
Or would the seller always sign to close the transaction and after receipt?
* invoice = intent
* signature = proof
* revocation = status change
All events propagate without polling or global consensus.