FACE4663 RESEARCH
An open research lab exploring contract identity on-chain — how addresses are generated, how rarity is measured, and how recognizability can become verifiable identity.
Understand the address. Measure the rarity. Verify the identity.
VANITY PATTERN CALCULATOR
Estimate difficulty, time, and probability for mining a vanity contract address with specific prefix/suffix patterns. Now with EIP-55 checksum casing analysis.
Mining is probabilistic — actual time may vary. These are statistical estimates, not guarantees. Effective bits include EIP-55 checksum casing constraints when enabled.
ADDRESS INSPECTOR
Analyze an address structure, verify EIP-55 checksum casing, and compare against an explicit prefix or suffix target.
⚠ Visually interesting ≠ authentic identity. Always verify origin on-chain independently.
EDUCATIONAL REFERENCE
A vanity contract address is a smart contract address that contains a recognizable prefix or suffix — like 0xface...4663 or 0x...face4663.
The address is generated by searching through many possible deployment parameters (typically CREATE2 salts) until one produces an address matching the desired pattern.
Important: A vanity address does not change the contract's functionality, security, or behavior. The contract code is identical regardless of the address. It is purely cosmetic — but cosmetics can become identity.
Prefix pattern: The address starts with specific characters after 0x. Example: 0xFACE4663...
Suffix pattern: The address ends with specific characters. Example: 0x...face4663
Key difference: Each additional hex character you lock adds 4 bits of difficulty, making the search 16× harder per character.
| Chars | Difficulty (16^n) | Avg Attempts |
|---|---|---|
| 4 | 65,536 | 65,536 |
| 6 | 16,777,216 | 16,777,216 |
| 8 | 4,294,967,296 | ~4.3 billion |
Prefix and suffix patterns have the same statistical difficulty when they lock the same number of hexadecimal characters. Suffixes are often chosen for branding because they appear like a signature at the end of an address.
Ethereum addresses use hexadecimal encoding. Valid characters after 0x are:
01234567 89abcdef
That's 16 possible values per character position. Hex addresses are case-insensitive on EVM chains — 0xABCD and 0xabcd refer to the same address.
Characters like g, h, x, y, z are invalid in hex strings and will be rejected by this lab's tools.
An Ethereum address is a 20-byte (160-bit) value. At the protocol level, the address is just raw bytes — case does not matter. 0xABC... and 0xabc... are the same address.
EIP-55 (Ethereum Improvement Proposal 55) introduced a mixed-case checksum encoding for human-readable display. It works by:
0x)This creates a deterministic casing pattern derived from the address itself. If a single character's case is wrong, it means either the address was mistyped or the display is not EIP-55 compliant.
EIP-55: capitalize(hex[i]) iff keccak256(hex.toLowerCase())[i] >= 8
FACE4663 targets the suffix face4663 — all lowercase. For the EIP-55 checksum to produce an address that displays as lowercase in these positions, the Keccak-256 hash nibbles at those positions must all be < 8.
This adds extra entropy constraints beyond just matching the raw hex pattern. Each alphabetic hex character (a-f) in the target adds 1 bit of checksum difficulty because there's a ~50% chance the hash nibble will be ≥ 8 (forcing uppercase).
| Constraint | Pattern: face4663 | Explanation |
|---|---|---|
| Locked hex chars | 8 | 8 characters fixed in address |
| Raw difficulty | 2^32 | 4 bits × 8 chars |
| Alphabetic chars (a-f) | 4 (f, a, c, e) | Numeric chars (4, 6, 6, 3) have no case constraint |
| Checksum bits | +4 | Each alpha char adds ~1 bit |
| Effective difficulty | 2^36 | 32 + 4 = 36 bits total |
A vanity miner can find addresses that match the raw hex pattern (case-insensitive) relatively easily. But to match the exact EIP-55 display casing, you need the Keccak-256 checksum nibbles to cooperate — which is ~16× harder for each alphabetic character in the pattern.
The two badges reflect this distinction:
The CREATE2 opcode allows deterministic address generation. The deployed address is calculated from three inputs:
address = keccak256(0xff ++ factory ++ salt ++ keccak256(initCode))[12:]
This means you can compute the address before deploying, and search for a salt value that produces a desired pattern.
The mining process:
The speed of this search depends on hashing throughput — Optimized GPU miners can test hundreds of millions to billions of candidate salts per second, depending on hardware and implementation.
CREATE2 enables vanity address mining because the salt parameter can be any 32-byte value, giving 2^256 possible addresses to search through.
Each hex character has 16 possible values. Adding one more character multiplies difficulty by 16. This exponential growth means:
| Chars | Difficulty (2^(4n)) | Avg Attempts | ~Time @ 500M salts/s |
|---|---|---|---|
| 4 | 2^16 = 65,536 | 65,536 | Instant |
| 6 | 2^24 = 16,777,216 | ~16.8M | ~0.03s |
| 8 | 2^32 = 4,294,967,296 | ~4.3B | ~8.6s |
| 10 | 2^40 ≈ 1.1 × 10^12 | ~1.1 trillion | ~36 min |
| 12 | 2^48 ≈ 2.8 × 10^14 | ~281 trillion | ~6.5 days |
At 12+ characters, mining requires specialized hardware running for days or weeks. This is why truly long vanity patterns are considered rare and valuable as identity markers.
PUBLIC PROOF
Transparent, verifiable proof of the mining process. Every parameter will be published for independent verification.
Every benchmark must be reproducible. All parameters will be published for independent verification.
PUBLIC MILESTONES
Each milestone represents an increasing level of difficulty and a new public benchmark.
8-char suffix
Target: face4663 — the foundational identity suffix.
9–10 char suffix
Extending the identity suffix beyond 8 characters.
Dual prefix–suffix feasibility research
Matching both beginning and ending of the address simultaneously.
Faster mining, longer patterns
Pushing the boundary of what's computationally feasible for vanity identity.
Every milestone will be benchmarked publicly with full reproducibility.
⚠ SECURITY
The salt used in CREATE2 deployment is not a private key. It is a public parameter that determines the contract address. Exposing a salt does not compromise wallet security.
CREATE2 address = f(factory, salt, init-code). Changing any of these three inputs produces a completely different address. There is no partial match.
Never trust a claimed address without verifying it on-chain yourself. Compute the CREATE2 address from the published factory, salt, and init-code hash, then compare with the deployed contract.
If you plan to deploy a vanity contract, do not publish a discovered salt or complete executable deployment configuration before deployment unless the factory prevents unauthorized deployment or front-running.
No legitimate tool, lab, or project will ever ask for your private keys, seed phrases, or wallet recovery information. Never submit these to any interface.
FACE4663 Contract Identity Lab is entirely client-side. All calculator and inspection operations run locally in your browser. No keys are requested and no wallets are connected.
0xd014645812df8e52c6083285ff6b09d0e02b24a4ae38238bc02b7caf779b38c9267675332026-08-03 12:37:14 UTC72338890xd64EfA7476B345934248Cb8Bc9eC22A0FAcE46630xd64efa7476b345934248cb8bc9ec22a0face46630x88291f1e104ba3612de9fbbdf984c7a088062327d84da4fe6e07f34451c79d1e0x3917436f1660e4203163ceb0090f76cdbb06c4460859757998ca096b4b1d63cfcff1c875375e75c417af8c471f984fb26db80557512a6bf6919c42ee23cca9360xA5aAb3F0c6EeadF30Ef1D3Eb997108E976351feB0xe1071F450ca0f461f9Fe51ae6753D7bc158F6B691,000,000,000 tokens0.2 ETHPENDING