P2P Deal: Listing Locks, Frozen Funds and Release
Crypto / FinTech · P2P Engine
What happens between clicking “Open deal” and crediting crypto to the buyer? This Laravel platform illustrates listing limits, frozen funds and controlled state transitions.
One listing, two buyers at the same time
If both participants see 100 units and each requests 80, a browser-side check provides no guarantee. The P2P controller reads the listing again inside a MySQL transaction using lockForUpdate(), validates its status and limits, reduces the available volume and only then creates a draft deal. The second request sees the balance left by the first. The listing closes when its remainder falls below the minimum deal size.
A draft cannot reserve liquidity forever. A delayed job cancels an unconfirmed start, and cancellation restores the listing volume.
A fiat payment mark is a claim, not a chain transaction
The buyer marks the payment, the seller checks their own payment account and only then releases the crypto. Release is allowed only to the crypto seller and only when the deal is paid. One database transaction moves the deal to completed, deducts the seller's frozen funds and credits the buyer. The history records the rate and counterparty.
Disagreement follows a separate dispute state, chat and administrative review. A “I paid” click is not proof of a bank transfer; it is a participant's statement that starts the next step of the process.
The design rule
For each P2P transition, define who may perform it and which balances must change together. Then wrap those changes in a transaction and close the race with a row lock. The interface may retry a request; the money state must remain coherent.