CIP proposal: Pending Transactions; a two-phase transaction protocol for safer crypto sends

Developers CIPs
,
1

CIP proposal: Pending Transactions - a two-phase transaction protocol for safer crypto sends

I think one of the biggest barriers for mainstream adoption of crypto is the unreasonably high baseline danger that is inherent in the way wallet-to-wallet transactions work. Every time I buy something with crypto or send money to someone, even when using a good quality wallet or service like coinbase, there’s always that panic moment: you paste a wallet address, double-check it, hold your breath, and click send; because if anything goes wrong, the money is just gone. No undo, no pre-commit feedback, no verification, no support phone number, nothing. This one thing turns lots of people away from crypto on day 1, and it’s been unsolved for over a decade.

I’d like to propose a CIP for Pending Transactions; a two-phase transaction protocol (2PT) that brings the familiar “pending” mechanic from traditional banking to cryptocurrency.

How it works

Instead of sending funds directly and irrevocably, a sender issues a PREPARE transaction that locks their funds and makes them visible to the recipient as “pending.” The recipient can verify the amount and address are correct, then the sender issues a CONFIRM to complete the transfer; or an ABORT to cancel and get their funds back immediately. And more advanced features building on top of this also enable more advanced & streamlined crypto payment processes.

Why Cardano

Cardano’s is more willing to explore advanced features than more conservative chains like Bitcoin, while also having an extended core feature set that should reduce the initial investment necessary to achieve a basic implementation, which could result in it becoming the reference implementation that influences other chains to adopt it.

The draft spec

I’ve written a full chain-agnostic specification covering three compliance tiers:

  • Tier 1 - Core protocol (PREPARE / CONFIRM / ABORT, timeout, observability)
  • Tier 2 - Authority delegation, recipient decline, capability tokens for automated systems
  • Tier 3 - Amendment and negotiation (counter-offers, multi-party escrow patterns)

The spec also covers use cases including lay-user barrier reduction, bilateral address verification, cryptographic proof of funds, and automated merchant payment flows.

The full draft is available here: Comparing cardano-foundation:master...yurelle:CIP-PendingTransactions · cardano-foundation/CIPs · GitHub

I’ve never done a proposal before, so I don’t know if I did it right.

1 Like
2

no worries @Yurelle — you’ve got it closer to editors’ and reviewers’ expecations than many people have so far! :smiling_face_with_sunglasses: You could also use these sources to anticipate issues that often come up in review & to get ready to follow the process once you’re ready to submit your CIP on GitHub:

In the meantime here on the Forum, I would look forward to what the community has to say about this idea. Editorially, you can prepare for your submission by fixing these things:

  • Elements in the YAML lists in the top header (“front matter”) are not double-quoted in their entirety: in fact, with those omitted, your name would appear usefully as a label in most contexts.
  • You have enough material in your Motivation that it would likely help the community if you would also write a CPS on the subject: see Wiki > The CPS (Cardano Problem Statement) and CIP-9999
  • Subtitles for the Motivation and Rationale, according to the updated CIP template (publication in progress: cc @ryun1) are now capitalised (Why, How)
  • Implementation notes (not an acceptable top-level heading) should be:
    • in the Specification if it’s essential to the implementation
    • in an Appendix (generally after the Path to Active) if it’s considered optional
  • Likewise Open Questions — a feature of the CPS format — should go into a CPS if you’re writing one, and maybe an Appendix if not.

Optionally, but essential for future-proofing: Your text-format diagrams would look better & be much more maintainable by using Mermaid:

(good examples for these types of documents)
https://gist.github.com/ChristopherA/bffddfdf7b1502215e44cec9fb766dfd

1 Like
3

OK. I think I fixed all your stuff, if I understood them correctly. I pushed the changes to my branch.

Commit Message:

--- Fix Initial Comment Suggestions ---
- Create corresponding CPS

CIS Fixes:
- Remove quotes from YAML
- Capitalize Motivation & Rationale Subtitles
- Move Implementation Notes & Open Questions to new Appendix section
2 Likes