Frequently asked questions
Mechanism-first answers for careful DeTrust Protocol/Pay users.
Top questions
Fast answers before you open a payment instance.
A trust-minimized payment protocol on Solana using the DeTrustPay Protocol, which bridges off-chain delivery with on-chain enforcement.
Not by default; Acceptance to payer's proposal is the protocol-defined exception.
No. You control keys and signing authority.
No. Finalized on-chain transactions are irreversible.
Basics before your first payment
What DeTrust Pay is, what you need, and what the web app adds.
What is DeTrust Pay?
Short answer: A trust-minimized payment protocol on Solana using the DeTrustPay Protocol to bridge off-chain delivery and on-chain enforcement.
Why this is true: DeTrustPay Protocol enforces outcomes through on-chain state transitions and economic incentives, not reputation or arbitration.
What you should do: Read the mechanism overview before using significant funds.
Do I need an account to use DeTrust Pay?
Short answer: No for protocol usage; yes only for optional convenience features on the official web app.
Why this is true: Smart contracts are permissionless, but account features such as notifications and history indexing are app-level services.
What you should do: If you only need protocol interaction, a wallet is enough. If you want web dashboard features, create an account.
Do I need a wallet?
Short answer: Yes. A Solana wallet is required to sign protocol actions.
Why this is true: All critical actions are cryptographic signatures made by your wallet, not by DeTrust Pay.
What you should do: Use a wallet you control and verify every transaction before signing.
What does off-chain promise and on-chain enforcement mean?
Short answer: The fulfillment of a transaction occurs off-chain, while the settlement path is enforced on-chain.
Why this is true: Protocol logic strictly controls when funds can move and how final outcomes are determined.
What you should do: Clear confirmation criteria should be defined in the promise before creating a DeTrust Pay setup.
Mechanism and settlement flow
How DeTrustPay setup, payment instance, proposal, and settlement actually work.
How does DeTrustPay Protocol settlement happen?
Short answer: Settlement follows deterministic contract rules from the current on-chain state.
Why this is true: Roles, deposits, accepted amount, proposal flags, and time-based conditions all feed the final settlement path.
What you should do: Check the current state and role labels before taking final actions.
What is double deposit in DeTrust Protocol?
Short answer: Double deposit means both parties lock deposits on-chain before protected settlement.
Why this is true: Symmetric deposits remove one-sided free options and apply economic pressure to complete honestly under protocol rules.
What you should do: Set deposit sizes that are meaningful relative to the transaction amount and agreed risk.
Can funds settle without payer confirmation?
Short answer: Not by default. Payer confirmation is the normal settlement path.
Why this is true: Alternative completion only happens when a valid proposal is accepted under protocol rules.
What you should do: As payer, confirm only after promised fulfillment is verified. As payee, use proposals when partial fulfillment occurs.
What is the proposal path?
Short answer: Proposal path is a controlled way to adjust settlement when perfect completion is not possible.
Why this is true: Both sides can propose adjustments, but only protocol-valid acceptance transitions the state.
What you should do: Use proposals to reduce expected loss and move to a fair terminal outcome.
Is there arbitration in DeTrust Pay?
Short answer: No. DeTrust Pay does not include subjective third-party arbitration.
Why this is true: Dispute convergence is handled by contract-defined economic logic instead of off-chain judgment.
What you should do: Write specific, objective terms in advance so verification is clear.
Why incentives converge in DeTrustPay
How DeTrust Protocol redesigns payoffs so cooperative completion is the rational path.
Why does DeTrustPay say trust is not required?
Short answer: Because DeTrust Protocol makes dishonest paths predictably loss-bearing under protocol rules.
Why this is true: Both parties pre-commit deposits on-chain, and settlement paths are deterministic and role-constrained.
What you should do: Define objective off-chain fulfillment criteria before creating the transaction.
Why can reputation and arbitration still fail for off-chain delivery?
Short answer: They usually apply after conflict starts, so enforcement is delayed and uncertain.
Why this is true: When penalties are probabilistic and delayed, expected betrayal utility can remain positive in one-off or cross-border interactions.
What you should do: Use protocol-level incentive constraints rather than relying on social trust alone.
Why are dual deposits required from both sides?
Short answer: Symmetric deposits remove unilateral free-option behavior and align incentives before settlement.
Why this is true: If only one side is collateralized, the other side can retain strategic upside from refusal or manipulation.
What you should do: Choose deposit levels that are meaningful relative to transaction value.
What does "cooperation is the stable strategy" mean here?
Short answer: It means honest completion is typically the lowest-loss path for both parties under the protocol state machine.
Why this is true: Defection paths are designed to be economically inferior through deterministic loss pressure and constrained transitions.
What you should do: If fulfillment becomes partial or delayed, use proposal paths early to reduce deadlock.
Does DeTrustPay need to prove off-chain truth perfectly?
Short answer: No. It does not need perfect truth inference to enforce strategic discipline.
Why this is true: The protocol focuses on making dishonest behavior unprofitable under on-chain rules, even when off-chain evidence is imperfect.
What you should do: Write clear acceptance conditions and keep verifiable records for your counterparty.
Why does this mechanism scale better than trust-heavy systems?
Short answer: Because protocol rules stay constant as volume grows, while trust-based monitoring overhead compounds.
Why this is true: Deterministic automation reduces marginal enforcement effort compared with manual dispute handling and reputation checks.
What you should do: For repeated usage, standardize terms and operational playbooks around protocol states.
Role responsibilities
What each side is expected to do for fair and successful transactions.
What should a payer do before confirmation?
Short answer: Confirm only after the promised delivery has been verified.
Why this is true: Confirmation is a high-impact state change and may finalize funds flow.
What you should do: Use objective checks and avoid confirming based on pressure or assumptions.
What should a payee do before entering a transaction?
Short answer: Commit only to deliverables you can fulfill reliably.
Why this is true: Over-promising increases proposal/dispute pressure and can produce worse economic outcomes.
What you should do: Define realistic scope, timeline, and proof of fulfillment before entering a transaction.
When should either side make a proposal?
Short answer: When delivery is partial, delayed, or otherwise deviates from original terms.
Why this is true: Proposal path exists to reduce deadlock and expected loss while preserving fairness constraints.
What you should do: Propose early with concrete adjusted terms instead of waiting for escalation.
When should I accept a counterparty proposal?
Short answer: Accept when the proposal improves expected outcome versus continued conflict.
Why this is true: Prolonged standoff can increase costs and uncertainty for both sides.
What you should do: Evaluate proposal economics, role impact, and terminal outcomes before accepting.
Cost model and terminal states
What fees apply, who pays them, and what outcomes mean economically.
What fees exist in DeTrust Pay?
Short answer: There are protocol fees and Solana network fees.
Why this is true: Protocol fees follow on-chain formulas; network fees are paid to Solana validators.
What you should do: Review fee math before creating a setup with large amounts.
Who pays network fees?
Short answer: The signing wallet for each transaction pays the network fee.
Why this is true: Network fees are independent of protocol fee distribution.
What you should do: Keep enough SOL balance for transaction execution on your selected cluster.
Can fees change over time?
Short answer: Yes. Network and some settlement-related values can vary with timing and state.
Why this is true: Elapsed time, proposal activity, and network conditions can influence final costs.
What you should do: Use current values from the app and on-chain records before confirming.
What happens in honest vs dishonest outcomes?
Short answer: Honest completion tends toward normal settlement; dishonest behavior tends toward direct economic loss.
Why this is true: Deposits are designed to make manipulation or unreasonable refusal costly.
What you should do: Focus on objective verification and fair proposals to keep outcomes efficient.
Wallet control and authentication
How signatures work and what DeTrust Pay can never do with your keys.
Does DeTrust Pay control my wallet or funds?
Short answer: No. You keep custody of keys and must sign your own actions.
Why this is true: DeTrust Pay cannot spend from your wallet without your signature.
What you should do: Reject unknown signing prompts and verify destination accounts.
Are authentication signatures on-chain?
Short answer: No. Login signatures are off-chain authentication proofs.
Why this is true: They prove wallet ownership for app sessions and do not execute fund transfers by themselves.
What you should do: Treat signing prompts carefully and confirm the requested action type.
What happens if I lose wallet access?
Short answer: You may permanently lose access to associated on-chain assets and actions.
Why this is true: No centralized recovery exists for private-key loss in non-custodial systems.
What you should do: Use secure backup and key-management practices before transacting.
Can I use multiple wallets?
Short answer: Yes, on the web app you can link multiple wallets for convenience.
Why this is true: Account-level tooling can aggregate visibility, while each wallet remains independently controlled.
What you should do: Label wallets clearly to avoid signing from the wrong account.
Policies, availability, and support boundaries
Where to find policies and what support can and cannot do.
Is DeTrust Pay available in every country?
Short answer: Availability can vary by jurisdiction and user obligations.
Why this is true: Users remain responsible for local legal compliance when using blockchain tools.
What you should do: Review local rules before participating in real-value transactions.
Is DeTrust Pay a bank, custodian, or advisor?
Short answer: No. It is not a bank, custodian, or provider of financial, tax, or legal advice.
Why this is true: Protocol and app tooling provide mechanism and transparency, not regulated advisory services.
What you should do: Consult qualified professionals for legal or tax decisions.
Can support reverse transactions or resolve delivery disputes?
Short answer: No. Support cannot reverse finalized transactions or arbitrate off-chain delivery disputes.
Why this is true: Final outcomes are controlled by on-chain program rules and blockchain finality.
What you should do: Use support for platform, indexing, or account tooling issues only.
Where are official policies and risk docs?
Short answer: Terms, privacy, cookie, security, and risk disclosures are publicly available.
Why this is true: Policy pages define boundaries, responsibilities, and current disclosure language.
What you should do: Read these documents before using high-value setups.
Contact support
Support can help with platform and indexing issues, not off-chain dispute arbitration.