Answer first: If one required participant does not confirm a P2P crypto release, the normal release cannot proceed. The funds remain in on-chain escrow while the trade is pending. One confirmation—or a payment screenshot on its own—is not enough to release the funds.
This is the core idea behind Elexa’s shared-control model: the exchange-side participant and the trading counterparty both remain involved in the release decision. The design reduces the risk of a single party releasing funds too early, but it does not remove every risk from P2P trading. Users still need to verify payment carefully, protect their wallets, and follow the trade process.
Why does Elexa require two confirmations?
In a conventional custodial flow, a platform may hold funds and make the final release decision inside its own system. A decentralized P2P flow works differently. The trade is tied to an on-chain escrow, and the normal release path depends on the confirmations defined for that trade.
For Elexa’s current shared-control flow, both required participants must approve the release. If only one side confirms, the release condition is incomplete. The escrow therefore does not move the funds through the normal release path.
This creates a deliberate checkpoint between “payment appears to be complete” and “crypto is released.” That checkpoint gives each side time to check the trade state before the transaction moves forward.
How the shared-control release flow works
- The trade is opened. The participants agree to the offer terms, amount, payment method, and instructions shown in the trade.
- Funds enter on-chain escrow. The crypto allocated to the trade is held by the escrow logic rather than being released immediately to the receiving side.
- The payment step is completed. The paying participant follows the agreed payment instructions. The receiving participant checks the actual receiving account—not only a receipt or screenshot.
- The first confirmation is recorded. One required participant signals that their side of the release condition is satisfied.
- The second confirmation completes the normal release condition. Only after both required approvals are present can the normal escrow release move forward.
If the flow stops after step four, the trade is still waiting. The presence of one signature does not substitute for the missing second signature.
What does a pending confirmation mean?
A pending confirmation is a clear state: the normal release condition has not yet been completed. It does not mean the crypto has already been transferred to the counterparty, and it should not be treated as proof that the trade is finished.
The exact next action depends on the trade status and the reason for the delay. A participant may still be checking payment, waiting for a bank or payment provider to update, reviewing the trade instructions, or responding to a problem. Users should rely on the visible trade state and the official support or dispute path when needed.
Why this reduces single-party release risk
Shared confirmation is designed to reduce several common P2P failure modes:
- Premature release: one participant cannot complete the normal release alone.
- Screenshot pressure: a screenshot does not replace confirmation from the required parties.
- Accidental approval: the second checkpoint creates another opportunity to notice a mismatch.
- Unclear responsibility: the trade state shows whether the required approvals are complete or still pending.
- Concentrated control: release authority is shared rather than resting with only one participant.
These controls can reduce risk, but they are not a promise of 100% security. Blockchain transactions, payment providers, wallets, user devices, and human decisions can all introduce risk.
What should you do if the other side has not confirmed?
1. Do not confirm just to speed up the trade
Never approve a release simply because the other participant is rushing you. Confirm only after the conditions shown in the trade have been satisfied and independently checked.
2. Verify payment in the actual receiving account
Open the bank, mobile-money, or payment-provider account that should receive the funds. Check the sender details, amount, currency, status, and any restrictions. Do not rely only on an image, email, or message saying the payment was sent.
Use Elexa’s detailed payment verification checklist before co-signing for a practical review process.
3. Keep communication inside the trade
Use the official trade conversation and keep the instructions, confirmations, and relevant evidence together. Moving the discussion to an unrelated channel can make the sequence of events harder to review.
4. Check the on-screen trade state
Look for the current escrow and confirmation status. A visible “pending” state is a reason to pause and understand what is missing, not a reason to assume release has happened.
5. Use the official support or dispute path
If the parties disagree, payment cannot be verified, or the trade remains unresolved, follow the support or dispute options presented by Elexa. Do not attempt to bypass the escrow flow or arrange an off-platform release.
What shared confirmation does not guarantee
Two confirmations improve shared control, but they do not eliminate every possible problem. Traders still need to consider:
- payment reversals, holds, delays, or provider-specific restrictions;
- incorrect wallet or network selections;
- network fees and the native asset required to submit an on-chain transaction;
- phishing, compromised devices, or fake support accounts;
- incorrect amounts, currencies, sender names, or trade references;
- the finality of an on-chain transaction after it is validly submitted.
Shared control works best when both participants combine the escrow rules with careful payment verification and wallet security.
A practical checklist before you confirm
- Confirm that the trade amount and payment amount match.
- Check the payment in the real receiving account.
- Verify that the payment status is complete and usable.
- Review the sender information and trade instructions.
- Make sure you are connected to the intended wallet and network.
- Keep enough native network asset available for any required transaction fee.
- Read the current escrow status before approving.
- Stop and use the official dispute path if anything is inconsistent.
Frequently asked questions
Can one participant release the funds alone?
No. In Elexa’s shared-control flow, one confirmation does not complete the normal release condition. Both required confirmations must be present before the release can proceed.
Does a payment receipt count as the second confirmation?
No. A receipt can be useful evidence, but it is not the same as independently verifying the payment and completing the required confirmation in the trade flow.
Are the funds automatically released after a timeout?
A missing required confirmation does not itself authorize the normal release. Users should follow the status and instructions displayed for the specific trade and use the official support or dispute process if it remains unresolved.
Does two-confirmation escrow make P2P trading completely risk-free?
No. It reduces single-party release risk and improves shared control, but no technical or operational system can remove every risk. Payment verification, wallet security, network awareness, and careful trade behavior still matter.
Shared control makes the release decision clearer
The purpose of Elexa’s two-confirmation model is simple: one side should not be able to complete the normal release alone. If one required confirmation is missing, the funds do not move through the normal release path. Both sides stay involved, the escrow state remains visible, and users have a clearer point at which to verify the trade or raise a problem.
For a deeper overview, read how Elexa’s two-signature release works. When you are ready to trade, explore current P2P offers on Elexa.
