EIP-5564 Implementation

This document details SIP Protocol’s implementation of EIP-5564 (Stealth Addresses) and ERC-6538 (Stealth Meta-Address Registry), including technical decisions, security considerations, and integration guides.

Overview

EIP-5564 defines a standardized approach to stealth addresses on Ethereum. SIP Protocol implements the secp256k1 scheme (scheme id 1) for full compatibility with the Ethereum ecosystem.

Key Properties

Property	SIP Implementation
Scheme	1 (secp256k1)
Curve	secp256k1
Key format	Compressed (33 bytes)
Hash function	SHA-256
View tag	First byte of shared secret hash
Address derivation	Keccak-256 of uncompressed public key

Stealth Meta-Address Format

A stealth meta-address encodes two public keys needed to generate stealth addresses:

sip:<chain>:<spendingKey>:<viewingKey>

Components

Component	Size	Description
chain	variable	Chain identifier (e.g., ethereum, polygon)
spendingKey	33 bytes	Compressed secp256k1 public key for spending
viewingKey	33 bytes	Compressed secp256k1 public key for scanning

Key Format

Compressed secp256k1 public keys are 33 bytes:

• First byte: 0x02 (y is even) or 0x03 (y is odd)
• Remaining 32 bytes: x-coordinate

// Valid compressed keys
'0x02' + 64 hex chars  // 33 bytes total, y even
'0x03' + 64 hex chars  // 33 bytes total, y odd

// Invalid formats
'0x04' + 128 hex chars // Uncompressed (65 bytes)
'0x' + 64 hex chars    // Missing prefix (32 bytes)

Generation

import { generateStealthMetaAddress } from '@sip-protocol/sdk'

const { metaAddress, spendingPrivateKey, viewingPrivateKey } =
  generateStealthMetaAddress('ethereum')

// metaAddress.spendingKey: 0x02abc...
// metaAddress.viewingKey: 0x03def...

Encoding/Decoding

import {
  encodeStealthMetaAddress,
  decodeStealthMetaAddress,
} from '@sip-protocol/sdk'

// Encode for sharing
const encoded = encodeStealthMetaAddress(metaAddress)
// "sip:ethereum:0x02abc...:0x03def..."

// Decode from string
const decoded = decodeStealthMetaAddress(encoded)

Stealth Address Generation

The protocol follows EIP-5564’s cryptographic scheme:

Mathematical Description

Given:

• Recipient spending public key: K
• Recipient viewing public key: V
• Ephemeral private key: r (randomly generated)
• Ephemeral public key: R = r * G

The stealth address is derived as (canonical EIP-5564 — shared secret from the VIEWING key, stealth public key offset from the SPENDING key):

1. Compute shared secret point: S = r * V
2. Hash the shared secret: h = SHA256(S)
3. Derive stealth public key: P = K + h * G
4. Derive Ethereum address: addr = keccak256(decompress(P))[12:32]
5. View tag: vt = h[0]

Implementation

import { generateStealthAddress } from '@sip-protocol/sdk'

const { stealthAddress, sharedSecret } = generateStealthAddress(recipientMetaAddress)

// stealthAddress.address: 0x02xyz... (compressed public key)
// stealthAddress.ephemeralPublicKey: 0x03abc... (must be published)
// stealthAddress.viewTag: 42 (0-255, first byte of hash)

Address Derivation

Converting the stealth public key to an Ethereum address:

import { publicKeyToEthAddress } from '@sip-protocol/sdk'

// Compressed public key → Ethereum address
const ethAddress = publicKeyToEthAddress(stealthAddress.address)
// "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"

Steps:

1. Decompress the public key (33 bytes → 65 bytes)
2. Remove the 04 prefix (65 → 64 bytes)
3. Keccak-256 hash (64 → 32 bytes)
4. Take last 20 bytes
5. Apply EIP-55 checksum

Ephemeral Key and Shared Secret

Ephemeral Key

The ephemeral key is generated per-payment and must be published for the recipient to claim funds:

// Sender generates ephemeral key
const { stealthAddress } = generateStealthAddress(recipientMetaAddress)

// Ephemeral public key must be published (announcer contract or off-chain)
console.log('Publish:', stealthAddress.ephemeralPublicKey)

Shared Secret Derivation

Sender computes:

S = r * V  (ephemeral private × viewing public)

Recipient computes:

S = v * R  (viewing private × ephemeral public)

Both arrive at the same point due to ECDH properties. Because the shared secret derives from the VIEWING key, the recipient can detect payments with only the viewing private key plus the spending PUBLIC key — the spending private key is needed solely to derive the spendable stealth key.

View Tag Optimization

The view tag enables efficient scanning by allowing quick rejection of non-matching payments.

How It Works

1. View tag = first byte of SHA256(shared_secret_point)
2. Range: 0-255
3. Expected false positive rate: ~1/256 (0.39%)

Scanning Process

checkStealthAddress performs the view-tag check internally (it returns early on a tag mismatch before doing the full elliptic-curve derivation), so scanning is a single call per candidate:

Scanning is view-only — it needs the recipient’s viewing PRIVATE key and their spending PUBLIC key (the meta-address spendingKey), never the spending private key (canonical EIP-5564):

import { checkStealthAddress } from '@sip-protocol/sdk'

// For each potential payment
for (const payment of potentialPayments) {
  // View tag is checked first inside checkStealthAddress; the
  // expensive derivation only runs when the tag matches (~0.4% of the time)
  const isMine = checkStealthAddress(
    payment.stealthAddress,
    myViewingPrivateKey,
    mySpendingPublicKey
  )

  if (isMine) {
    // This is our payment!
    console.log('Found payment:', payment)
  }
}

Note

The view tag itself is exposed on each StealthAddress (payment.stealthAddress.viewTag), but the SDK does not export a standalone view-tag matcher. The comparison against the recipient’s keys is performed internally by checkStealthAddress (and by deriveStealthPrivateKey when recovering the spending key).

Performance Impact

Without view tag: O(n × full_computation) With view tag: O(n × (cheap_check + 0.004 × full_computation))

For 1 million transactions, this reduces full computations from 1M to ~4K.

Announcer Contract Integration

EIP-5564 defines an announcer contract for publishing ephemeral keys on-chain.

Standard Interface

interface IERC5564Announcer {
  event Announcement(
    uint256 indexed schemeId,
    address indexed stealthAddress,
    address indexed caller,
    bytes ephemeralPubKey,
    bytes metadata
  );

  function announce(
    uint256 schemeId,
    address stealthAddress,
    bytes memory ephemeralPubKey,
    bytes memory metadata
  ) external;
}

SIP Integration

Planned

A high-level on-chain announcer client (createAnnouncerClient) is not yet part of the SDK. The snippets below illustrate the intended interface — until it ships, interact with the announcer contract directly through your own contract client (e.g. ethers/viem) using the IERC5564Announcer ABI above.

// Planned API — illustrative, not yet exported by @sip-protocol/sdk
const announcer = createAnnouncerClient({
  address: '0x...',  // EIP-5564 announcer contract
  provider: ethersProvider,
})

// After sending to stealth address
await announcer.announce({
  schemeId: 1,  // secp256k1
  stealthAddress: ethAddress,
  ephemeralPubKey: stealthAddress.ephemeralPublicKey,
  metadata: '0x',  // Optional: encrypted note
})

Scanning Announcements

// Planned API — illustrative, not yet exported by @sip-protocol/sdk
const announcements = await announcer.getAnnouncements({
  fromBlock: 19000000,
  schemeId: 1,
})

// Each candidate is then checked with checkStealthAddress (view tag handled
// internally; view-only — viewing PRIVATE key + spending PUBLIC key)
const myPayments = announcements.filter(a =>
  checkStealthAddress(a.stealthAddress, myViewingPrivateKey, mySpendingPublicKey)
)

Registry Contract (ERC-6538)

ERC-6538 defines a registry for storing stealth meta-addresses on-chain.

Standard Interface

interface IERC6538Registry {
  event StealthMetaAddressSet(
    address indexed registrant,
    uint256 indexed schemeId,
    bytes stealthMetaAddress
  );

  function registerKeys(
    uint256 schemeId,
    bytes memory stealthMetaAddress
  ) external;

  function registerKeysOnBehalf(
    address registrant,
    uint256 schemeId,
    bytes memory signature,
    bytes memory stealthMetaAddress
  ) external;

  function stealthMetaAddressOf(
    address registrant,
    uint256 schemeId
  ) external view returns (bytes memory);
}

Planned

ERC-6538 registry support is planned (see the comparison table below). A registry client is not yet part of the public SDK surface, and the snippets in this section are illustrative of the intended API. Until it ships, read/write the ERC-6538 registry directly through your own contract client using the IERC6538Registry ABI above.

Registration

// Planned API — illustrative, not yet exported by @sip-protocol/sdk
const registry = createRegistryClient({
  address: '0x...',  // ERC-6538 registry
  signer: ethers.signer,
})

// Register your meta-address
await registry.registerKeys({
  schemeId: 1,  // secp256k1
  stealthMetaAddress: encodedMetaAddress,
})

Lookup

// Planned API — illustrative, not yet exported by @sip-protocol/sdk
const recipientMeta = await registry.stealthMetaAddressOf(
  recipientEthAddress,
  1  // schemeId
)

if (!recipientMeta) {
  throw new Error('Recipient has no registered stealth meta-address')
}

Security Considerations

Private Key Protection

Key	Sensitivity	Storage Recommendation
Spending private	Critical	Hardware wallet, encrypted vault
Viewing private	High	Secure storage, may share with auditors
Ephemeral private	Temporary	Securely wipe after use

Threat Model

Threat	Mitigation
Spending key compromise	Full loss of funds - treat as seed phrase
Viewing key compromise	Privacy loss only - can regenerate
Ephemeral key reuse	Never reuse - always generate fresh
View tag collision	~0.4% false positives, full derivation required

Best Practices

1. Key generation: Use cryptographically secure random number generator
2. Key storage: Encrypt at rest, never log or transmit unencrypted
3. Ephemeral keys: Generate fresh for each payment, securely wipe after
4. View tags: Always check before full computation
5. Registry: Verify on-chain meta-address matches expected format

Secure Memory

SIP SDK uses secure memory practices:

import { secureWipe } from '@sip-protocol/sdk'

const privateKey = generatePrivateKey()
try {
  // Use key
} finally {
  secureWipe(privateKey)  // Overwrite memory
}

Comparison with Other Implementations

Feature	SIP Protocol	Umbra	Fluidkey
Scheme	secp256k1	secp256k1	secp256k1
View tag	Yes (1 byte)	Yes (1 byte)	Yes (1 byte)
Multi-chain	Yes	Ethereum only	Ethereum L2s
ERC-6538	Planned	No	Partial
Compliance	Viewing keys	No	No
Cross-chain	NEAR Intents	No	No

SIP Advantages

1. Cross-chain: Works across 15+ chains via NEAR Intents
2. Compliance: Viewing keys for selective disclosure
3. Multi-curve: secp256k1 (EVM) and ed25519 (Solana/NEAR)
4. SDK: Comprehensive TypeScript SDK with React hooks

Deviations from Standard

SIP Protocol is fully compatible with EIP-5564 scheme 1, with these extensions:

Extension	Description
Ed25519 support	Additional scheme for Solana/NEAR (not on-chain)
Cross-chain	Settlement via NEAR Intents
Viewing keys	Additional layer for compliance
SIP encoding	sip:chain:spending:viewing format

Audit Checklist

Before deploying to production:

• Private keys never logged or transmitted
• Ephemeral keys generated fresh per payment
• Secure random number generator used
• Keys wiped from memory after use
• View tag checked before full derivation
• Registry contract address verified
• Announcer contract address verified
• Chain IDs validated
• Input validation on all parameters

See Also

• EIP-5564 Specification
• ERC-6538 Specification
• Ethereum Privacy Guide
• Stealth Address Concepts
• Viewing Key Concepts