Security and trust on SMProud — three independent layers

What we mean by security on a marketplace like this

Security on SMProud splits into three independent layers, each with its own failure mode. Account security is about who can log in to the platform itself — buyers and sellers protecting their own SMProud accounts from credential theft. Transaction security is about what happens to the funds and the assets during a deal — escrow custody, dispute handling, recovery-chain verification. Asset security is about what happens to a transferred social media account after the deal closes — whether the buyer can keep operational control without losing it to a platform action or a seller reclamation. Most marketplaces talk about one of these and pretend the other two are solved. This page covers all three honestly.

How buyer and seller account credentials are protected

SMProud accounts use email + password authentication with optional two-factor authentication via an authenticator app. Passwords are hashed with a modern key-derivation function (Argon2id) and never stored in plain text or recoverable form. The session cookie uses HttpOnly, Secure, and SameSite=Lax flags, with rotation on every privilege escalation. We do not store payment instruments — card details flow directly to the payment processor and never touch our database. Email verification is required before listing or opening escrow.

We strongly recommend enabling two-factor authentication, particularly for sellers. The most common SMProud-side compromise pattern in this category isn't a platform breach — it's a seller's personal email getting phished, and the attacker using the email to reset the SMProud login. Two-factor blocks that path entirely.

How funds are held during a transaction

Funds deposited into escrow sit in a segregated operating account, separate from SMProud's general operating account and separate from any other buyer's deposit. The segregation is structural, not just a bookkeeping promise — if SMProud were to disappear tomorrow, escrow balances would be returnable to depositors through the banking relationship that holds the segregated account, not through a creditor claim against SMProud's operations. The escrow page walks through the release conditions in detail; the short version is funds release only when the buyer confirms three things: credentials work, recovery details are transferred, and the seller is no longer in any recovery position.

How we vet sellers before they list

Sellers complete a three-step verification before their first listing publishes: government-ID match against a video selfie via a third-party KYC vendor, behavioral-history check against an internal database of previously-flagged sellers, and account-ownership proof via a screen-recorded walkthrough of the asset they intend to list. New sellers carry a visible "new seller" flag for their first listings; the flag drops after a small number of clean transactions. The full methodology is documented on the seller verification page. We are explicit about what this catches (identity-fraud onboarding, repeat bad actors, sellers without provable account control) and what it does not (first-time bad actors with clean identity records, sellers fronting for someone else).

What happens after a transferred account leaves the marketplace

The most common asset-security failure in this category happens after the deal closes — platform suspends the account, original owner reclaims via a residual recovery vector, or an algorithmic ban hits because the platform detected ownership change. SMProud's escrow flow is designed to prevent the second one (the recovery-chain verification before release exists specifically to close that path). The first and third are not preventable by any marketplace, because they originate at the platform layer, not the marketplace layer. We are honest about that on the buyer protection page — escrow protects the deal, not the long-term operability of the asset under the new owner.

Site-level security headers and what they do

Every page on SMProud ships a strict set of HTTP security headers:

• Strict-Transport-Security with a 2-year max-age and the HSTS preload list submission, so browsers refuse to downgrade to HTTP even on first visit.
• Content-Security-Policy restricts script execution to first-party sources plus Google Tag Manager, blocks inline scripts beyond what Next.js requires for hydration, and prevents any third-party iframe or font load.
• X-Content-Type-Options: nosniff stops MIME-sniffing exploits.
• X-Frame-Options: SAMEORIGIN blocks the site from being embedded in a third-party iframe, which is the foundation of clickjacking defense.
• Referrer-Policy: strict-origin-when-cross-origin prevents the site from leaking specific URL paths to third-party links.
• Permissions-Policy disables camera, microphone, and geolocation access across the entire surface — features SMProud doesn't use, so they can't be exploited.

Disclosure: what we do not do

SMProud does not run a bug-bounty program at this stage of the company; instead, security researchers can email security@smproud.com directly and we'll respond within two business days. We do not publish a third-party security audit report because we have not commissioned one yet — when we do, the report will be linked here. We do not currently store sensitive seller documents (ID images, payout details) on our own infrastructure beyond the verification window; KYC artifacts live with our vendor, payout details live with our payment processor.

Where to read more

• How escrow works — the financial-custody layer
• Listing verification — the data-quality layer
• How we vet sellers — the identity layer
• Buyer protection policy — what happens after release