This site is being rebuilt and some pages are out of date. For current details, write to reach@inorbit.hr. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

← Back to Platform

RFC 0043open2026-10-04

Sign in with a wallet

An Ethereum wallet as one more way to sign in, through a small provider of our own that the sign-in trusts like Google or GitHub.

Problem

The people we build for, the ones who run blockchain infrastructure and write Solidity in the EVM lab, already carry an identity: their wallet. Today they sign in with an e-mail code, a passkey, Google or GitHub, and nothing connects that account to the address they deploy from. The owner asked for wallet sign-in.

The standard is settled. Sign-In with Ethereum, EIP-4361, is final: the wallet signs a plain-text message that names the site, the address, the chain, a one-time nonce and a time window, and the site checks the signature. Smart contract wallets answer through EIP-1271, not yet deployed ones through EIP-6492, and passkey wallets built on ERC-4337 sign the same way. Ordinary wallets that carry code since EIP-7702 still recover to their address.

What is missing is the place it plugs in. Our sign-in runs on and , and neither has a wallet method. webhooks run around an existing method and cannot add one, and the open-source admin API cannot start a session. A wallet has to enter the way Google and GitHub do: as an OpenID Connect provider trusts.

Proposal

A provider of our own

A small Rust service, siwe, is an OpenID Connect provider with one job: it shows the wallet a message to sign, checks the signature, and gives an ID token whose subject is the wallet. keeps everything else it already does: sessions, account linking, second factors, and handing the person to for the console and the API.

  • What it serves: discovery, its signing keys (ES256, because cannot read Ethereum's own key type), an authorize page that runs the wallet handshake, and a token endpoint with PKCE for one client only, the sign-in itself. No dynamic registration.
  • What it checks: the message names our sign-in domain and page exactly, a chain we allow, a nonce it issued and has not seen (single use, five minutes at most), and a time window that has not passed. A plain wallet is checked by recovering the signer; a contract or passkey wallet by asking the chain, through the EVM lab's node access, which already speaks to the networks we allow.
  • Who the wallet is: the subject is the chain and the address together, in the CAIP-10 form, because a contract wallet at one address can belong to different keys on different chains.
  • What it keeps: nonces, briefly. Nothing else.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

A signed-in person adds a wallet from the console's security page, beside their passkeys and linked providers. From then on "Sign in with a wallet" on the sign-in page finds their account. A wallet linked to nobody does not create one in this phase: the sign-in says so and offers the other ways in.

The sign-in page finds wallets the browser offers through EIP-6963 and builds the message with viem. We do not use Reown's AppKit: its licence ties every use to their hosted gateway.

Phase two: sign up with a wallet

A wallet can open an account, with no e-mail. Before that account counts as recoverable, the person adds a second way in (an e-mail address, a passkey or recovery codes), because nobody can bring back a lost wallet, us included. Other chains, through CAIP-122, come only if people ask.

Privacy

A wallet address is personal data, and every transaction it ever made is public and linkable to it (EDPB guidelines on blockchain). So the address never goes into a log line, a metric label, a URL or the tokens our services receive; audit lines name the account, never the wallet. Deleting an account removes the wallet link with everything else. The sign-in page says plainly that a wallet is a way to sign in, not a check of who someone is.

Checking a contract wallet sends its address to the node provider the EVM lab already uses; that provider goes into our vendor register for this purpose too.

Security

The wallet signature is checked once, by this provider; from there on the person holds a normal session and the platform's own tokens, so our edge stays the only place a token is verified. The nonce endpoint is reachable by anyone, so it is rate-limited at the edge. The provider's signing key and its client secret live where every other secret does, never in a file. A new way to sign in changes our access-control control, and the compliance record says so when it ships.

Screening wallets against sanctions lists is not planned: a sign-in moves no value. If the platform ever moves value, that becomes a question for counsel first.

Alternatives considered

  • The existing SIWE OpenID Connect bridge. It is maintained and supports contract wallets, but it is a new Node service with its own , one maintainer, open registration by default and logs in a shape we would have to change. Our provider is about a thousand lines of Rust in our own patterns, on the libraries that bridge uses.
  • Waiting for . No issue, release or roadmap item proposes it.
  • A hosted wallet sign-in. Puts every sign-in through a third party and, for the common kits, a licence that binds us to their gateway.

Decision

Open. Proposed: phase one first (link, then sign in), our own provider, Ethereum and the networks the EVM lab already allows; phase two once phase one has run for a while.

Publication

The sign-in page gains "Sign in with a wallet"; the console's security page gains "Link a wallet". The developer docs say how an account gets a wallet and what is kept. Nothing changes for anyone who does not use it.

Status log

  • 2026-10-04: opened, after a survey of the standards and of how the sign-in could take a wallet.
  • 2026-10-07: Checked: no code PR names it (#219 is the text). Open.

← Back to Platform