Every design decision in Portexa's architecture prioritizes a single outcome: your digital assets remain entirely under your control at every step — before, during, and after verification.
Portexa was designed from scratch with a non-custodial security model as its core constraint. Unlike traditional identity verification systems that require you to upload documents or give access to accounts, Portexa proves wallet ownership using the same cryptographic primitives that secure the blockchain networks themselves.
The protocol is deliberately minimal. We only request the data necessary to prove ownership of a wallet address, and we discard the cryptographic proof immediately after verification. No sensitive information is ever stored on our servers.
Every component — from the client-side JavaScript to the on-chain smart contracts — has been reviewed by independent security firms and is available for public inspection. Security through transparency, not obscurity.
Portexa has never recorded a security incident resulting in unauthorized wallet access or data exposure since the protocol launched.
Every wallet connection established through Portexa is end-to-end encrypted via WalletConnect v2 — no plaintext data ever transits the relay layer.
Portexa's architecture never requests, reads, or stores private key material at any point. Only your public wallet address is accessed.
These are not aspirational goals. They are hard technical constraints baked into how the protocol works.
Portexa never holds, stores, or transmits your private keys, seed phrase, or any sensitive wallet credential. Our connection protocol is architecturally incapable of requesting transaction permissions — only a message signature can be requested, and this signature is used for a one-time ownership check then discarded immediately. No employee of Portexa at any level can access your wallet or assets.
All communication between your browser and our verification servers is encrypted using TLS 1.3 with AES-128 — the current standard used by major financial institutions and governments. The WalletConnect v2 relay layer that connects your wallet app applies an additional layer of end-to-end encryption, meaning even WalletConnect's relay infrastructure cannot read the content of the session. Data is encrypted at origin and only decrypted at destination.
Verification certificates are anchored to a public blockchain, creating a tamper-proof, permanent audit trail that anyone can query without needing to trust Portexa. The on-chain record includes a cryptographic hash of the certificate ID, the issuance timestamp, and the verification status. The chain of custody from signature to on-chain record is fully verifiable by third parties with no special permissions required.
Portexa's smart contracts are open-source and deployed to a publicly accessible blockchain address. All verification logic, the certificate schema, the revocation mechanism, and the registry data structure are readable in plain Solidity by any developer worldwide. We do not use upgradeable proxy patterns that could silently change the contract behavior after deployment. What you see in the audit report is what runs on-chain.
WalletConnect v2 requires an explicit, distinct authorization for every class of action. Portexa only requests a "personal_sign" method call — the lowest-privilege wallet action available — which creates a plain message signature with no transaction implications. Your wallet will never show a gas fee prompt, a spending approval, or a token transfer request during the Portexa verification session. The protocol structure makes fund movement technically impossible, not just contractually prohibited.
The Portexa client-side JavaScript uses only well-established libraries: ethers.js v5 for BNB Chain interaction and WalletConnect v2 for secure wallet sessions. No obscure dependencies are used. The connection flow requests only personal_sign — the lowest-privilege wallet action available. No token approvals, no transactions, no spending permissions are ever requested.
Here is an explicit breakdown of the attack vectors Portexa's design addresses and how each is mitigated.
| Attack Vector | Risk Without Verification | Portexa Mitigation |
|---|---|---|
| Signature Replay Attack | A stolen signature could be reused to impersonate wallet ownership | Each verification message is unique per session with a 10-minute expiry. Replayed signatures are rejected at the server level. |
| Man-in-the-Middle (MITM) | An attacker intercepts the connection and injects malicious data | TLS 1.3 + WalletConnect E2E encryption make MITM mathematically infeasible with current hardware. |
| Phishing Site Impersonation | Fake Portexa sites trick users into connecting wallets to malicious sessions | Portexa's WalletConnect metadata is pinned to the official domain. Wallet apps display the requesting domain; any mismatch is visible to the user. |
| Sybil Attack | One entity creates thousands of verified wallet addresses to game systems | On-chain certificate records are linked to real wallet addresses with on-chain history, making mass Sybil attacks economically prohibitive. |
| Certificate Forgery | An attacker creates a fake Portexa certificate for a wallet they don't control | Certificates are signed by Portexa's server keypair and anchored on-chain. Forgery would require breaking ECDSA — infeasible with any known technology. |
| Social Engineering | Support scammers trick users into revealing seed phrases | Portexa never contacts users via DM, telegram, or discord. Verification requires zero personal communication — the entire flow is automated and in-browser. |
Three full audits completed by the most respected security firms in the Web3 ecosystem. Every finding was addressed before the next protocol version shipped.
Role: BNB Chain RPC interaction, BEP-20 token balance reading, ECDSA message signing, and wallet address recovery. Used as the primary blockchain interface library.
Why it's safe: ethers.js is MIT-licensed, open-source, and one of the most widely deployed Web3 libraries with millions of weekly downloads.
Role: Establishes an encrypted, read-only session bridge between this website and your mobile wallet app. Required for QR-code based wallet connection on desktop.
Why it's safe: WalletConnect is the industry standard for dApp-to-wallet connectivity. Sessions are end-to-end encrypted; the relay server cannot read session content.
Role: Each verification session uses a unique nonce that expires after 10 minutes. This prevents signature replay attacks where an old signature could be reused to impersonate wallet ownership.
Scope: Connection, signature collection, balance reading, and session teardown are all handled client-side with no sensitive data written to any server database.
If you discover a potential security vulnerability in Portexa — including on our website, protocol, or client-side code — please report it to security@portexa.in before public disclosure. We commit to acknowledge all valid reports and work with researchers on coordinated disclosure.