Instant delivery

Lifetime updates

1 domain license

Addonv1.0.0

Wallet Connect for Bicrypto

Name: Wallet Connect for Bicrypto
Brand: MashDiv
SKU: wallet-connect
Price: 129.00 USD
Availability: InStock

Let customers sign in with a wallet they already own — one signature, the same session a password gives.

4.70208 sales

$129$149Save 13%

You'll also need Bicrypto

On its own, Wallet Connect for Bicrypto won't work — it only runs if you already own Bicrypto. Open the Requirements tab to see exactly what you need and add it to your order.

See it working Live demo Documentation View on CodeCanyon

Customers sign in by signing a message — no password to reset or to leak
The same session a password gives: cookies, expiry, logout, Active Sessions
A single-use server nonce makes a captured signature worthless the second time
The message must name your own host, so a look-alike site cannot farm a login
Contract wallets sign in too, through an on-chain signature check
Thirteen networks in the picker; seven carry a signature all the way in
Customers link and unlink their own addresses from the profile Wallet tab
More than one wallet per account, and any of them opens that account
An address is unique platform-wide — a second claimant is refused, not moved
The primary link is mirrored onto the user record for products that pay out
Every link, unlink and wallet sign-in lands in the customer's activity log
One extension toggle turns the whole feature on and off without a restart

Inside Wallet Connect

A wallet your customer already owns, used as a login

One button under the email form opens the wallet picker, one signature proves the address, and the platform issues exactly the session a password would have. Nothing is transferred, nothing is approved, and no key ever touches your server.

In detail

Your customers sign in by proving they hold an address, not by remembering a password. A wallet button sits under the email form on your own sign-in screen: one tap opens the wallet picker, one signature proves the address, and the platform issues exactly the session a password login would have issued — same cookies, same expiry, same entry in Active Sessions, same logout.

How it works

Your server issues a single-use value; the browser folds it into a plain-text Sign-In With Ethereum message and the customer's wallet signs it. Nothing is transferred and nothing is approved — the only thing a wallet is ever asked to do here is sign text. Your server then reads the whole message: the host it names, its URI, its version, its chain and its timestamps. It spends the single-use value so the same signature can never be sent twice, and only then recovers the address from the signature. Contract wallets are handled on chain, so a multi-signature wallet signs in like any other.

What you configure

Setting	Where	What it decides
Extension toggle	Admin, Extensions	Whether the wallet button appears at all
Project ID	.env, needs a rebuild	The wallet picker, and server-side verification
Site name and description	.env, needs a rebuild	What the customer reads in the approval sheet
Approval-sheet icon	your own `/img/logo/logo.png`	The logo the wallet shows beside it — a file, not a setting
Canonical host	.env, a restart is enough	The one hostname a signed message may claim
Signature to unlink	Settings row	Whether removing a link also needs a signature

What operators control

Sign-in and linking are one switch: turn the extension off and the button disappears and the endpoints refuse
Every link, unlink and wallet sign-in lands in that customer's activity log with the address on the row
Banned, suspended and unverified accounts are refused after the signature verifies, so the message is specific
An address belongs to one account platform-wide — a second claimant is refused rather than quietly moved
Customers link and unlink their own addresses; there is no admin screen, and that is deliberate

Wallet Connect is an addon for Bicrypto, and wallet sign-in does not create accounts. An address the platform has never seen is refused, so a new customer registers by email first, links a wallet from their profile, and signs in with it from then on. It is EVM-only, it needs your own free project ID and a frontend rebuild to take it, and a customer with two-factor authentication should keep using their password: the challenge is enforced, but the wallet form has no screen for the code.

The signature has to be for your site, and it works once

The whole message is parsed, not scraped: it must name your own host in both its domain and its URI line, be version 1, carry a numeric chain id, and sit inside its validity window — including an Issued At no more than ten minutes old. Only then is the nonce spent — a single-use value your server issued and deletes on first use — and only then is the signature recovered, against the eight chain ids your install will verify on. A pair captured from a network log is worthless on the second attempt, and a signature farmed by a look-alike site never verifies here at all.

Sign-in and nonce share one strict limiter: five requests per fifteen minutes per IP address, and a complete attempt costs two of them. Behind one office NAT that budget is shared.

A valid signature is not an account — the record still decides

The signature proves who holds the key, and everything after it is the same gauntlet a password login walks. The address has to already belong to an account, and then that account's own status is read: BANNED, SUSPENDED and INACTIVE are each turned away with the same 403 the password form returns. Two-factor is checked in the same place and issued the same way — email code, SMS code or authenticator app — and only past all of it does the server mint a session. Every step of that order is narrated to the request log by name, so a refused sign-in tells you which check stopped it and in what order the checks ran.

Two limits sit here. A customer with two-factor switched on cannot complete a wallet sign-in — the challenge is issued exactly as it is for a password login, but the wallet form has no screen for the code, so those customers use the password form. And a refused attempt writes no row on the activity feed; only successful sign-ins do, so the refusal is in the request log and nowhere else.

Thirteen networks in the picker, seven that can carry a sign-in

The wallet picker is built from a static list of thirteen networks, with Ethereum as the default. The server keeps its own allow-list of eight EIP-155 chain ids and tests the id in the signed message against it before any outbound call is made, because that id is what a contract-wallet signature is verified against. Seven chains are on both lists: Ethereum, Optimism, BNB Smart Chain, Polygon, Arbitrum One, Avalanche and Base. A customer whose wallet is on one of the other five EVM chains — Linea, Celo, Cronos, Fantom or Rootstock — is refused, and switching the wallet's network to one of the seven is the whole fix. Solana is the thirteenth: it is not an EIP-155 chain at all, so it can be connected but never signed in with. The linking endpoint checks the same list, so an off-list chain cannot link an address either.

The refusal does not name the chain: an off-list id answers 401 “Signature verification failed”, the same message a bad signature gets. Both lists are compiled in — adding a chain is a source change and a frontend rebuild, not a setting.

One address, one account — and the customer holds the switch

A customer links an address from their profile with the same signature step, and can link more than one; every linked address signs the same account in. The first link becomes primary and is mirrored onto the user record, so the products that pay out to an address have one to read. Uniqueness is enforced at the database, so an address belongs to exactly one account platform-wide — a second claimant is refused, and unlinking releases it again.

There is no admin screen for wallet links. Linking and unlinking are the customer's own actions; an operator moving a link between accounts is a database change, and the documentation carries the statements for it.

Two screens here, and the wallet layer the rest of your stack plugs into

The wallet picker is created once for the whole application and mounted on eight screens. Two are this addon — the sign-in modal and the profile Wallet tab. The other six come with the NFT and swap products — four NFT flows, the swap terminal and the admin pool console — and they share the same project, the same modal and the same connection, which survives navigation between them. NFT Marketplace names this addon as a requirement for exactly that reason.

Those six screens need their own licences. This product covers the login and the linking; it does not include the marketplace or the swap terminal.

networks in the picker: 13
chains that sign in: 7
screens on one wallet layer: 8
life of a sign-in nonce: 300s

Everything included

61 capabilities, in 5 areas

Every item below exists in the source you receive. Nothing here is a roadmap.

Wallet sign-in

The button under the email form, and everything behind it.

Sign in with wallet on the login modal, beside email and Google
Shown only while the extension is enabled; the modal falls back to the password form
A single-use value your server issues, five-minute life, deleted on first use
Signature recovery for ordinary wallets, on-chain verification for contract wallets
An allow-list of eight chain ids, checked before any outbound call is made
The same session a password login issues — access token, session id, CSRF token
The same expiry, Active Sessions entry and logout as a password login
The same two-factor gate: email code, SMS code or authenticator app
Banned, suspended and unverified accounts refused after the signature verifies
A signed-in activity row naming the address, on the customer's own log
Five requests per fifteen minutes per IP, refusing rather than allowing on failure

What a signature has to satisfy

The message is read whole, line by line — not scraped for three fields.

A strict sign-in-message parser with a fixed grammar and a size ceiling
The message must name your own host in its opening line
Its URI line must resolve to the same host
Version 1 only
A numeric chain id is required — there is no silent fall back to mainnet
Expiration Time honoured, and Not Before honoured
Issued At capped at ten minutes old, whether or not an expiry is present
Validation runs before the single-use value is spent, so a bad message is retryable
One canonical host, named directly or derived from your site URL
The host expectation comes from your configuration, never from the request
Addresses normalised to one case on write and on read, at a single point

Linking and unlinking

The customer's own Wallet tab. There is no admin equivalent.

A Wallet tab in the user profile, with the connect modal on it
An explicit Link this wallet button — no signature is ever requested by itself
Copy the address, open it on an explorer, and read the connected chain id
The same message and signature gauntlet as sign-in, on the linking endpoint
More than one address per account, and any of them signs that account in
One address, one account platform-wide, enforced by a database index
A second claimant refused with a message that names the collision
Re-linking an address the account already holds writes nothing
Unlink from the same tab; the address is released and can be claimed again
The unlinked row survives as a record while the address itself is freed
Unlinking still works with the addon switched off or the licence lapsed
An optional setting requiring a fresh signature before a link can be removed
Wallet connected and Wallet disconnected activity rows, with the address and chain

One address on the user record

The primary link, mirrored where the rest of the platform reads it.

The first linked address becomes the primary one
At most one primary link per customer, enforced by a database index
The primary address mirrored onto the user record for products that pay out
The next-oldest link promoted automatically when a primary is unlinked
The mirror cleared when the last link goes
The signature flow is the only writer — every other path is refused by the model
Absent from the admin edit schema, so no operator can type an address in
The cached profile invalidated on every mirror write
The chain and the verification time recorded on each link
Linked addresses returned by the profile API as the multi-address truth
A dry-run migration that adopts an existing database and quarantines unproven addresses

The wallet layer, and switching it on

One project, one modal, eight screens, one toggle.

One wallet picker built once for the whole application
Thirteen networks in the picker, with Ethereum as the default
EVM networks and Solana served by the same modal through two adapters
Eight mount points: the login modal, the Wallet tab, four NFT screens, the swap terminal and the admin pool console
A connection that survives navigation between them and a page reload
Your own site name, description and logo on the wallet's approval sheet
An optional embedded email and social wallet, off unless you ask for it
The picker's own buy and swap panels switched off
Signing through the connected wallet, so a phone paired by QR can sign
Loaded only on the screens that need it, and never on the server
One extension toggle governing sign-in and linking together
Enforced inside every handler: the toggle and the licence file, on every call
The toggle takes effect without a restart
Every attempt narrated step by step to the request log
Wallet events on the admin user's Activity tab, with the full address

Licence: Regular licence — full source, activated in the extension manager
Requires: Bicrypto core. Nothing else in this catalog.
Runs on: Your existing install. No extra process, no extra service, no table of its own — one row per link in the table Google sign-in already uses.
Outside account: A free WalletConnect project id of your own. The wallet picker and server-side signature verification both use it.
Outbound network: Your backend needs HTTPS out to the signature-verification service. A locked-down egress refuses every sign-in.
Configuration: Two environment variables and one toggle. Neither variable is in the example file, and the project id is compiled into the frontend — changing it needs a rebuild as well as a restart.
Surface: 4 endpoints, 2 customer screens, 8 wallet mount points
Chains: 13 networks in the picker, 8 chain ids accepted, 7 that do both
Access control: No permission keys of its own. Enabling it needs view.extension and edit.extension.
Shares its wallet layer: NFT Marketplace requires this addon and mounts four of the eight screens; the swap terminal and the admin pool console mount two more. Each is licensed separately.
It does not create accounts: An address the platform has never seen is refused. A customer registers by email or Google first, links a wallet from their profile, and signs in with it from then on.
It never touches funds: The only thing a wallet is ever asked to do is sign a line of text. No transaction is proposed, no allowance is requested, no balance is read, and no key reaches your server.
EVM only: Solana is in the picker and cannot carry a sign-in; neither can Bitcoin, Tron, TON or Monero wallets, even on an install that takes deposits on those chains.
No admin screen: Nothing lists who has linked an address, and no operator can link, unlink or move one on a customer's behalf. Those are database operations, and the documentation carries the statements.
One hostname: A signed message may claim exactly one host. Customers who reach the site on an alias, a bare IP or a staging name cannot sign in — redirect the aliases rather than serving on them.
Two-factor customers should use their password: The challenge is issued and delivered exactly as it is for a password login, but the wallet form has no screen for entering the code.
The rate limit is fixed: Five requests per fifteen minutes, keyed by IP rather than by account, and a complete attempt costs two. An office behind one address shares that budget, and no screen raises it.
It is a second credential, not a recovery route: There is no self-service recovery for a lost seed phrase. Password reset by email remains the fallback for every account.