KNOWLEDGE BASE // FAQ

Access requires a Tor-compatible browser routed through the onion network to resolve .onion Top Level Domains (TLDs). Standard clearnet browsers cannot resolve these addresses. JavaScript should theoretically be disabled for maximum security, though the modern interface may require limited JS execution for captcha validation.

The infrastructure employs a rotating mirror system and End-of-Network (EoN) guard nodes to filter traffic. During high-load events or Distributed Denial of Service (DDoS) attacks, users are required to utilize alternative mirrors signed by the platform's PGP key. Latency (200ms+) is expected behavior within the Tor network.

Onion services are subject to network volatility. Inaccessibility is usually due to 1) Planned server maintenance (check /status endpoints), 2) DDoS remediation in progress, or 3) Client-side Tor circuit failure. Users should rotate circuits using 'New Identity' or try a verifiable mirror from the list.

PGP 2FA presents an encrypted challenge string upon login. This string can only be decrypted using the user's private key (stored locally on their device). The decrypted token must be entered to verify identity. This ensures that even if a password is compromised via phishing, the account remains inaccessible without the private key.

The primary defense mechanism is cryptographic verification. The market signs its active mirrors with a root PGP key. Users must verify the signature of any link against their local keyring before entering credentials. Without verifying the signature, there is no way to distinguish a legitimate mirror from a proxy attack.

Upon account creation, the system generates a 12-word mnemonic seed. This seed is the sole cryptographic method for resetting credentials. Because the database hashes passwords using advanced algorithms (e.g., Argon2), administrators cannot recover lost passwords. Without the seed, account recovery is mathematically impossible.

Escrow acts as a neutral smart-contract state where cryptocurrency funds are locked. Funds are deducted from the user's wallet but are not credited to the counterparty immediately. They remain in the escrow state until the transaction logic is finalized by the receiver or the auto-finalize timer expires.

The platform generates unique sub-addresses for every deposit (Monero/Bitcoin). These are monitored by the backend daemon. Users typically require 2-3 network confirmations before the balance is reflected in the internal ledger. Re-using old deposit addresses is not supported by the architecture.

Auto-Finalize (AF) is a timer mechanism ensuring funds do not remain in escrow indefinitely. If a receiving party does not dispute an order within the set timeframe (typically 7-14 days depending on the item class), the funds are automatically released to the counterparty.

Captcha failures often result from 1) Tor circuit latency causing session timeouts, 2) Clock desynchronization on the client device, or 3) Aggressive 'Security Slider' settings in the browser disabling necessary canvas elements. Refreshing the Tor identity usually resolves the session mismatch.

Users should check the blockchain explorer for the transaction ID (TXID). If the transaction has over 10 confirmations but does not appear in the dashboard, it is likely a synchronization delay in the market's XMR/BTC node. Ticketing systems are typically used to manually rescan the block height.