A transparent, four-step cryptographic protocol that proves wallet ownership without ever accessing your private key or seed phrase. No gas fees. No transaction approvals. No personal data required.
The entire verification flow from wallet selection to certificate issuance takes under 60 seconds in normal network conditions.
CryptoShield verification does not submit any on-chain transactions from your wallet. No ETH, BNB, or any token is spent during verification.
No email address, phone number, government ID, or any personally identifying information is required or collected during verification.
You will be asked to sign exactly one message in your wallet. This is a plain text message, not a transaction — no funds can be moved.
Here is exactly what happens at each stage of the CryptoShield verification process.
Begin by selecting the wallet application you wish to verify from our supported provider list. CryptoShield currently supports Trust Wallet, MetaMask, Coinbase Wallet, Phantom, Ledger Live, and any wallet that implements the WalletConnect v2 standard (listed under "Other Wallets").
Each wallet provider uses a slightly different connection standard. Trust Wallet and Coinbase Wallet connect via WalletConnect v2 with deep linking for mobile. MetaMask uses the EIP-1193 injected provider standard on desktop browsers. Phantom uses its own provider API. Our system automatically detects and applies the correct connection method for each selected wallet — no configuration required from you.
If you use a hardware wallet such as a Ledger Nano S, Nano X, or Stax, select Ledger Live. You will need your Ledger device connected and the Ethereum app open during verification. The hardware signing process is fully supported.
After selecting your wallet, CryptoShield generates a WalletConnect v2 session URI hosted through an encrypted relay server. On desktop, this URI is displayed as a QR code you can scan with your wallet app. On mobile, tapping "Open in Wallet App" triggers a deep-link that passes the session URI directly to your installed wallet application.
Your wallet app will display a connection approval screen showing the requesting domain (cryptoshield.io), the connection type (read-only), and the chains requested. You can safely approve this connection. WalletConnect v2 enforces permissions at the protocol level — the connection cannot be upgraded to include transaction permissions without your explicit approval of an entirely new session with different scope.
The session is secured by two layers: TLS 1.3 between your browser and WalletConnect's relay server, and an additional end-to-end encryption layer between the relay server and your wallet app using a session keypair generated locally. WalletConnect's relay infrastructure cannot read the session content.
Once connected, CryptoShield sends a "personal_sign" request to your wallet. This is the lowest-privilege action in the WalletConnect permission model — it is a plain text message signing operation with no on-chain effects whatsoever. No transaction is broadcast to any network.
The message follows the EIP-4361 (Sign-In With Ethereum) standard, which ensures the message is formatted in a human-readable way and displayed clearly in your wallet's UI. The message will include: the CryptoShield domain name, your wallet address, a unique nonce (random string), and a timestamp. These fields are included to protect against replay attacks.
Your wallet's private key is used locally on your device to produce the ECDSA signature. The private key is never transmitted; only the resulting signature is sent to CryptoShield's verification server. The signature is a mathematical proof that only someone controlling the private key corresponding to your wallet address could have produced.
Upon receiving your signature, CryptoShield's verification server performs the following checks in sequence: (1) validates that the nonce is unused and has not expired; (2) verifies the EIP-4361 message structure is intact and the domain is cryptoshield.io; (3) recovers the signer address from the signature using ECDSA ecrecover; (4) confirms the recovered address matches the address you provided in the wallet connection step.
If all checks pass, the server marks the signature as consumed (preventing replay), discards the raw signature, and generates a verification certificate. The certificate is assigned a unique certificate ID in the format TF-YYYY-XXXXXXXX, records the wallet type and verification timestamp, and sets the status to "Active".
A record of this certificate is written to CryptoShield's on-chain registry contract. This anchors the certificate to the blockchain permanently, making it independently verifiable by anyone querying the contract. The entire server-side process — from receiving the signature to issuing the on-chain record — takes between 5 and 15 seconds under normal conditions.
CryptoShield uses no proprietary technology. Every component is built on open, publicly documented, and independently audited standards from the Web3 and internet security ecosystems.
The industry-standard open protocol for connecting Web3 wallets to decentralized applications. WalletConnect v2 uses end-to-end encrypted relay servers, a permissions model based on namespaces and methods, and a topic-based subscription architecture. All session data is encrypted with a keypair generated locally — the relay server functions as an encrypted message ferry with no ability to read content.
Elliptic Curve Digital Signature Algorithm (secp256k1 curve) is the same cryptographic primitive used by Ethereum to validate every transaction on the network. ECDSA allows proving knowledge of a private key without revealing it — the mathematical foundation that makes public-key cryptography and blockchain ownership verification possible. CryptoShield's server uses the standard ecrecover function to recover the signer's address from the provided signature.
CryptoShield constructs all verification messages following the SIWE (Sign-In With Ethereum) standard defined in Ethereum Improvement Proposal 4361. SIWE defines a human-readable message format that wallet applications can display clearly to users before signing. The standard includes anti-phishing protections through domain binding and replay attack prevention through nonce fields.
Certificate records are anchored to a smart contract deployed on a public blockchain. The registry contract stores a mapping of wallet addresses to certificate metadata (issuance timestamp, wallet type, status). The contract is open-source, non-upgradeable (no proxy pattern), and owned by a time-locked multi-sig requiring 3-of-5 signatures for any administrative action. Revocation is callable only by the wallet address that holds the certificate.
All HTTP communication between your browser and CryptoShield's verification API is encrypted with TLS 1.3, the current industry standard for transport layer security. TLS 1.3 eliminates the vulnerable aspects of older TLS versions (1.0, 1.1, 1.2) including RSA key exchange, RC4 cipher suites, and weak MAC algorithms. All cipher suites used enforce Perfect Forward Secrecy (PFS), meaning historical traffic cannot be decrypted even if the server key is later compromised.
CryptoShield's backend operates without storing any private key material from users' wallets. The only key material that exists server-side is CryptoShield's own certificate signing key, which is stored in an HSM (Hardware Security Module) and never touches server memory in plaintext. User wallet signatures received during verification are verified and immediately discarded without being written to any persistent storage layer.
How CryptoShield's approach compares to common alternatives used for wallet ownership verification.
| Method | Private Key Exposed? | Gas Fee? | Personal Data? | On-Chain Proof? | Replay Protection? |
|---|---|---|---|---|---|
| CryptoShield (ECDSA + EIP-4361) | No | No | No | Yes | Yes — Nonce expiry |
| Send a small transaction | No | Yes | No | Yes | Partial |
| Email + wallet address submission | No | No | Yes | No | No |
| Custom smart contract interaction | No | Yes | No | Yes | Yes |
| Custodial exchange login | Partial | No | Yes | No | Varies |