Wallet-native authentication
A CIP-8 / CIP-30 / CIP-93 demo: sign in with a Cardano wallet instead of a password.
1. Wallet
Looking for CIP-30 wallets…
Works with any CIP-30 wallet. Each wallet renders its own signing prompt, it will show a clean description of what you're signing, if it recognizes this demo's structured payload. If it doesn't it will fall back to a generic raw-data warning. Either way, verification below works the same: the protocol degrades gracefully.
Connected wallet
2. Sign up or log in
3. Signed in
Signed in as
4. Demo scenarios
These use the same real wallet connection and the real verification
pipeline — the failure is genuine, not staged. Sign up and log in
first so an account exists; otherwise these fail one stage earlier, at
address, instead of demonstrating the
specific check named on the button.
What you're about to sign
Verification pipeline
Every attempt runs the same six stages, in this order, and stops at the
first failure —
parse → address → nonce → timestamp → uri → action → signature.
Nothing signed yet. Connect a wallet and try a flow.
Every step below runs the real verification pipeline — nothing here is a canned result.
Quick guide
- Connect a wallet.
- Sign up. Your wallet will prompt you to sign a small JSON message. The pipeline log on the right shows all six verification stages passing.
- Log in. Same idea, a fresh nonce each time.
- Try the “wrong” one on purpose. Sign up again with the same address, or log in before ever signing up. Both buttons are always clickable — the demo deliberately doesn’t pre-check which one applies and disable the other, because that check is the `address` pipeline stage: a duplicate signup or an account-less login gets rejected live, in the log, based on the signed message itself. Hiding that behind a pre-flight check would defeat the point of watching it happen.
- Prove ownership. Available once you’re signed in — this is the “prove it’s still you” re-authentication for a sensitive action or proving ownership of specific assets inside an address you control.
- Demo scenarios — do these after signing up, so the account exists
and the failure you see is the one the button names, not an earlier
“no account” rejection:
- Attempt login with a forged origin — builds a real, validly-signed message whose `uri` field doesn’t match this page’s real origin, and shows the backend rejecting it specifically at the `uri` stage.
- Replay the last signed message — resubmits the exact same signed bytes without asking the wallet to sign again, and shows the backend rejecting it at the `nonce` stage (single-use nonces stop replay).
Disconnect (in the wallet panel) drops the connection and ends the current session, so you can connect a different wallet or address and try the whole flow again from a clean state.
Feedback?
Have some feedback about this project? Provide your feedback by sending an email to [email protected]