Wallet login requires a signed challenge from the browser wallet. Address-only dashboard access remains read-only. Install the browser wallet

Chipcoin

Signed Wallet Login

Login with Chipcoin Wallet.

Chipcoin Signed Login v1 will let users prove control of a CHC or CHCQ address by signing a domain-bound challenge. The backend auth foundation is available; address-only dashboard access remains a read-only public-chain preview.

Install Browser Wallet Get Testnet CHC Open Explorer

Chipcoin Signed Login v1

The real login flow should be challenge-based and multi-signature-scheme from day one.

Wallet login proves control of a private key, not real-world identity. The account model should start as user = wallet address, with optional email, nickname, Telegram, or GitHub metadata added later.

Provider API

window.chipcoin.request({
  method: "chipcoin_signMessage",
  params: {
    message: "...",
    domain: "chipcoinprotocol.com"
  }
})

The wallet must read the real requesting origin from the browser context and compare it with the message domain.

Provider architecture

Use the standard extension pattern: page context provider, content-script bridge, and background or service worker signer. Privileged signing code must not run directly in the page context.

Auth endpoints

  • POST /auth/challenge
  • POST /auth/verify
  • POST /auth/logout
  • GET /auth/session

Canonical message

Chipcoin Signed Login v1
Domain: chipcoinprotocol.com
Origin: https://chipcoinprotocol.com
Network: testnet
Address: CHCC...
Scheme: 0
Nonce: ...
Issued At: ...
Expires At: ...
Statement: Sign in to chipcoinprotocol.com

The message format should be rigid. Free-form statements must not allow newline injection into protocol fields.

Signing domain

Message signing must use a cryptographic domain distinct from transaction sighash. A signed login payload must be impossible to reinterpret as a transaction signature, independent of whether the scheme is ECDSA or ML-DSA.

Signature schemes

0 = secp256k1 / ECDSA legacy for CHC addresses.

10 = ML-DSA-44 experimental path for CHCQ addresses, specified but not accepted by the public login backend yet.

The address prefix and version must constrain the accepted signature_scheme.

Server verification

The backend must verify nonce, expiry, domain, origin, public key to address binding, signature, and one-time challenge use.

Security rule

Never authenticate only by address. Never sign generic reusable text. Never let login signatures be confused with transactions.

Challenge hardening

Rate-limit challenge and verify requests by IP and address. Bound JSON body size, public key size, signature size, nonce length, statement length, and verify attempts per challenge.

Session model

Use an opaque server-side session ID with HttpOnly, Secure, and strict SameSite behavior where possible. Avoid stateless JWTs for this flow.

Clock and CSRF

Use short challenge expiry with small clock skew tolerance. Protect logout and future state-changing endpoints with CSRF controls.

Permission model

Connected origins should be stored in extension storage, shown to the user, and revocable. A page should not read an address without approval.

Approval safety

Reject origin/domain mismatch by default, render IDN domains safely, and cancel pending requests if the wallet auto-locks.

Verification Contract

The backend should reject anything ambiguous before signature verification.

This keeps the login flow close to SIWE while preserving Chipcoin-specific address formats and the signature scheme registry already used by the protocol.

Verify request

{
  "challenge_id": "abc123",
  "address": "CHCC...",
  "signature_scheme": 0,
  "public_key": "...",
  "signature": "...",
  "message": "Chipcoin Signed Login v1\n..."
}

Reject conditions

  • Challenge missing, expired, reused, or over attempt limit.
  • Origin or domain mismatch.
  • Provider request origin differs from the domain or origin encoded in the canonical message.
  • CHC address submitted with ML-DSA scheme, or CHCQ with ECDSA.
  • Public key or signature size outside exact scheme limits.
  • Nonce or statement exceeds configured length bounds.
  • Public key does not derive or commit to the submitted address.
  • Signature does not verify over the canonical login message.