Loading ToolBench
CREATE2 vanity address grinder: search salts in your browser for a deterministic contract address, check it is free on every EVM chain, deploy the same address on Ethereum, Base, Arbitrum and Robinhood Chain, and verify the derivation on chain. No private keys involved.
Five tools with complete input schemas and strong descriptions (avg 180 chars). Tool names follow verb_noun pattern (create2_derive, create2_quote, create2_grind, create2_availability, create2_verify_attestation). All parameters are typed and described. Output schemas are not explicitly documented in the visible code, which is a gap. Error handling is minimal, no recovery guidance or actionable error messages visible. Tool annotations (readOnlyHint, idempotentHint, openWorldHint) are present and correct, which is excellent. Composition is clean: each tool has one responsibility. Parameter naming is consistent (deployer, initCodeHash, initCode, salt, prefix, suffix). No secrets exposed as parameters.
Ask each EVM chain whether a predicted address already holds code, and whether the deployer exists there. A CREATE2 address is portable but not automatically available: it can be occupied on one chain and free on the rest, and finding that out after sending a deployment is expensive.
Derive a CREATE2 address from a deployer, a salt and an init-code hash, or a plain CREATE address from a sender and a nonce. Pure arithmetic and completely verifiable: this is the check that makes every other claim about a CREATE2 address falsifiable.
Search salts for an address matching a pattern, using every core of the machine running this server. No key material is involved: the result is a public salt, and the caller confirms it with create2_derive in one keccak.
Difficulty for a CREATE2 vanity pattern: probability, expected salts, p50/p90/p99, rarity tier and the EIP-55 case multiplier. Every nibble of an address is uniform, so a prefix costs the same as a suffix; the only free variable is casing, at 2x per letter.
Verify a CREATE2 grind attestation: re-derive the address from the attested deployer, salt and init-code hash, check the pattern and the difficulty, then recover the EIP-712 signer and check it against the published issuer list. The derivation check needs no issuer at all.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing what each tool returns. create2_derive, create2_quote, create2_grind, create2_availability, and create2_verify_attestation all lack explicit return type documentation.
No error handling guidance. Handlers throw generic Error() with minimal context (e.g., 'give a salt, or a sender and a nonce'). LLMs cannot determine if errors are retryable, user-fixable, or fatal. No recovery suggestions provided.
create2_grind accepts 'cores' and 'timeBudgetMs' parameters but no dry-run or confirmation step. This is a WRITE tool (per Risk classification) that performs CPU-intensive grinding. Agents should be able to preview cost before committing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
create2_availability parameter 'chainIds' is optional array but no description of what happens if omitted (does it check all chains? a default subset?). Undocumented defaults invite misuse.
create2_verify_attestation 'attestation' parameter is typed as object but no schema or structure documented. LLMs cannot construct valid attestation objects without seeing the expected shape (fields, types, required vs optional).