Read this before using DeTrust Pay
DeTrustPay Protocol(enhanced Dual Deposit Escrow, eDDE) improves transaction safety through incentive design and deterministic enforcement, but it does not remove all risk.
What the DeTrustPay Protocol Protects
- Symmetric incentives that drive transactions toward successful settlement.
- No party can profit from dishonest or non-cooperative behavior.
What the DeTrustPay Protocol Does Not Protect
- Incentive alignment does not guarantee that every transaction will succeed.
- Private key compromise or incorrect transaction signing.
Who Should Avoid Using It
- Users unwilling to accept the rules enforced by the DeTrustPay Protocol.
- Users unable to securely self-custody a wallet.
Severity and likelihood with mitigations
Each risk includes concrete controls that users can apply before and during transactions.
On-chain finality risk
Confirmed transactions on Solana are irreversible. Incorrect approvals cannot be rolled back by DeTrust Pay.
- Verify addresses and amounts before signing.
- Use small-value test transactions for new counterparties.
Counterparty Fulfillment Risk
The DeTrustPay Protocol (enhanced Dual Deposit Enforcement, eDDE) enforces economic consequences on-chain, but it does not verify or guarantee real-world delivery quality.
- Carefully review transaction details, including the promised delivery conditions.
- Assess the risk of delayed, partial, or failed fulfillment before entering a transaction.
Wallet key loss or compromise
Loss of private keys or seed phrase can lead to permanent asset loss. DeTrust Pay cannot recover wallet custody.
- Use hardware wallet or secure key storage.
- Never share seed phrases or signing requests from unknown sources.
Indexer or RPC delay risk
UI state may temporarily lag behind chain state during network congestion or infrastructure incidents.
- Treat explorer data as final source when status is unclear.
- Retry after confirmation windows rather than duplicating actions.
Risk of Data Inconsistency
DeTrust Pay uses a distributed data architecture with strong integration and security guarantees. Each user maintains an independent data snapshot synchronized from the server. In rare scenarios user data may become inconsistent with the on-chain state.
- Use on-chain DeTrust Pay setup data, transaction IDs, or signatures to deterministically reconstruct records.
- Trigger a recovery process by re-indexing data from a trusted chain indexer.
Asset and fee volatility risk
Token values and network fees may change between setup and settlement windows.
- Use stable-value assets when possible for commercial payments.
- Account for fee and volatility buffer in transaction planning.
Buyer/Payer
- Confirming too early can lock in loss on incomplete delivery.
- Ignoring a fair proposal can increase expected downside.
- Confirm only after objective fulfillment checks are complete.
- Evaluate proposals by expected loss, not emotion.
Seller/Payee
- Over-promising raises probability of disputed or reduced settlement.
- Delay can increase proposal and settlement pressure over time.
- Commit only to verifiable deliverables and realistic timelines.
- Use proactive proposals when partial fulfillment occurs.
Guarantees vs limits
Review before launch
- Read security controls and known operational boundaries.
- Review on-chain fee behavior before setting terms.
- Contact support for platform questions, not dispute arbitration.