ERC-4361 — Sign-In with Ethereum

Back to Account & Authentication

ERC-4361: Sign-In with Ethereum

ERC-4361 standardises the off-chain message format that lets a user "log in" to a web app using their Ethereum wallet. The wallet signs a structured plaintext message; the server verifies the signature against the claimed address. It's the de-facto authentication flow for every modern dApp — Snapshot, Etherscan, OpenSea, etc. — and one of the few ERCs whose adoption is essentially universal.

Required Message Format

example.com wants you to sign in with your Ethereum account:
0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

I agree to the rules of example.com.

URI: https://example.com/login
Version: 1
Chain ID: 1
Nonce: 32891756
Issued At: 2025-01-15T13:14:15Z
Expiration Time: 2025-01-15T14:14:15Z
Not Before: 2025-01-15T13:14:15Z
Request ID: 81bb...3acf
Resources:
- ipfs://Qm…
- https://example.com/my-web2-claim.json

The server (not a contract) verifies the signature with ecrecover, checks the domain, nonce uniqueness, and time window, then issues a session token. ERC-4361 is a format spec for off-chain auth — no on-chain contracts are required.

Neo Equivalent: Native Witness over a Domain-Bound Message

Neo's witness model already provides the same "user signs a message, server verifies" primitive — at the protocol level, with no need for a domain-separator hack. Two viable patterns:

A. Sign-a-transaction-stub — the wallet signs an empty Neo invocation script that includes the domain, nonce, and timestamps as Notify payloads or PUSH literals. The server verifies the witness via Crypto.VerifyWithECDsa (or by simulating the script) and reads the embedded fields.

B. Sign-arbitrary-message — the wallet signs an arbitrary byte string prefixed with a Neo-Express-style magic header (010001f0 + payload + 00) using its private key. The server verifies via Crypto.VerifyWithECDsa(payload, pubKey, signature). This is what NeoLine, O3, and OneGate already implement under the brand "Neo Sign-In".

ERC-4361 Field	Neo Equivalent
domain line	Application-defined prefix in the signed message; verified server-side
address (claim)	Neo address derived from pubKey via Helper.ToScriptHash(pubKey)
EIP-191 prefix (\x19Ethereum Signed Message:\n)	Neo wallet message prefix (010001f0 + length + payload + 00)
Chain ID	Neo network magic (894710606 TestNet) baked into the signed payload
Nonce	Application-supplied random nonce; server tracks consumed nonces
Issued At / Expiration Time / Not Before	Timestamps in the payload; server enforces window
ecrecover (server)	Crypto.VerifyWithECDsa(payload, pubKey, sig, NamedCurveHash.secp256r1SHA256) (server)
Resources (URIs the user is authorising)	Free-form payload; convention only
Wallet UX (sign typed/personal message)	NeoLine signMessage, O3 signPersonal, OneGate signMessage

Migration Notes

The most useful "neo-side" SIWE adoption is a JS-SDK convention, not an on-chain contract. The mirror page exists because:

1. dApp authors migrating from Ethereum keep asking "where's SIWE on Neo?".
2. The wallet-side message format is already standard (Neo dApp API signMessage); a thin server library that mirrors siwe-js's API would close the migration gap for most dApps.

Recommended: publish a neo-siwe server library with the same shape as siwe — prepareMessage(), verify(), generateNonce() — wrapping the wallet's signMessage payload format. No contract required; any backend can adopt SIWE-on-Neo with one helper.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// SIWE is an off-chain spec — there's no canonical on-chain contract.
// The Solidity verifier is only useful when you want a contract to validate
// SIWE messages (e.g. a permissioned vault that gates access on a SIWE proof).

contract SiweVerifier {
    using ECDSA for bytes32;

    struct Claim {
        string  domain;
        address account;
        uint256 chainId;
        uint256 issuedAt;
        uint256 expirationTime;
        bytes32 nonce;
    }

    mapping(bytes32 => bool) public consumedNonce;

    function verify(Claim calldata c, bytes calldata signature) external returns (bool) {
        require(c.chainId == block.chainid,         "wrong chain");
        require(block.timestamp >= c.issuedAt,      "issued in future");
        require(block.timestamp <= c.expirationTime, "expired");
        require(!consumedNonce[c.nonce],            "nonce reused");

        bytes32 digest = keccak256(abi.encodePacked(
            "\x19Ethereum Signed Message:\n", _formatMessage(c)
        ));
        address recovered = digest.recover(signature);
        require(recovered == c.account, "bad signature");

        consumedNonce[c.nonce] = true;
        return true;
    }

    function _formatMessage(Claim calldata c) internal pure returns (string memory) {
        // ERC-4361 message reconstruction — elided for brevity.
        return "";
    }
}

using System;
using System.ComponentModel;
using System.Numerics;
using Neo;
using Neo.Cryptography.ECC;
using Neo.SmartContract.Framework;
using Neo.SmartContract.Framework.Attributes;
using Neo.SmartContract.Framework.Native;
using Neo.SmartContract.Framework.Services;

namespace R3E.Examples;

// SIWE-on-Neo verifier — useful when an on-chain action must validate a
// signed-off-chain auth claim (e.g. a vault that admits anyone holding a
// valid signed access token from an off-chain identity provider).

[DisplayName("SiweVerifier")]
[ContractPermission("*", "*")]
public class SiweVerifier : SmartContract
{
    private const byte Prefix_ConsumedNonce = 0x01;

    [DisplayName("Verified")]
    public static event Action<UInt160, ByteString> OnVerified;

    public static bool Verify(
        ByteString domain,
        ECPoint pubKey,
        BigInteger chainId,
        BigInteger issuedAt,
        BigInteger expirationTime,
        ByteString nonce,
        ByteString signature)
    {
        if (chainId != Runtime.GetNetwork()) throw new Exception("wrong network");
        if (Runtime.Time < issuedAt)         throw new Exception("issued in future");
        if (Runtime.Time > expirationTime)   throw new Exception("expired");

        var key = NonceKey(pubKey, nonce);
        if (Storage.Get(Storage.CurrentContext, key) is not null)
            throw new Exception("nonce reused");

        var payload = FormatPayload(domain, pubKey, chainId, issuedAt, expirationTime, nonce);
        var ok = (bool)CryptoLib.VerifyWithECDsa(payload, pubKey, signature, NamedCurveHash.secp256r1SHA256);
        if (!ok) throw new Exception("bad signature");

        Storage.Put(Storage.CurrentContext, key, 1);
        OnVerified(Contract.CreateStandardAccount(pubKey), nonce);
        return true;
    }

    private static byte[] NonceKey(ECPoint pubKey, ByteString nonce)
        => new byte[] { Prefix_ConsumedNonce }.Concat(pubKey.EncodePoint(true)).Concat(nonce);

    private static ByteString FormatPayload(
        ByteString domain, ECPoint pubKey, BigInteger chainId,
        BigInteger issuedAt, BigInteger expirationTime, ByteString nonce)
    {
        // SIWE-style canonical payload reconstruction; bytes match what the
        // wallet's signMessage emitted. The protocol-level wallet prefix
        // (010001f0…) is added by the wallet SDK at sign time.
        return domain
            .Concat((ByteString)pubKey.EncodePoint(true))
            .Concat((ByteString)(byte[])chainId.ToByteArray())
            .Concat((ByteString)(byte[])issuedAt.ToByteArray())
            .Concat((ByteString)(byte[])expirationTime.ToByteArray())
            .Concat(nonce);
    }
}

When To Use This vs Native Witness

If the auth check happens on-chain (e.g. "this signed proof admits you to the vault"), use this verifier or a thin variant. If the auth is purely off-chain (server admits user → issues session cookie), don't deploy any contract — verify the signature in the server using Crypto.VerifyWithECDsa and treat it as a JWT-equivalent.

The on-chain path is the rare case. Most SIWE-on-Neo deployments are all-server: the wallet's signMessage produces a Neo signature, the server verifies it, and no GAS is spent at all.