Ethereum Util Laravel Package

Product Decisions This Supports

• Feature delivery in PHP/Laravel backends: supplies the low-level Ethereum primitives most crypto-adjacent features need — hex ↔ binary conversion, keccak-256 hashing, EIP-55 address checksum validation, private-key → address derivation, signature verification/recovery, unit conversion (wei/gwei/ether), and function-selector computation.
• Roadmap items it de-risks: deposit-address validation and storage, on-chain payment reconciliation, token/NFT metadata display, webhook signature verification for wallet providers, EIP-712 typed-data signing, and custodial withdrawal flows — all without standing up a polyglot Node/Go service or writing crypto primitives in-house.
• Build vs. buy: clearly buy. One composer require replaces hand-rolled hashing/checksum/unit math, which is exactly the kind of code where subtle bugs (bad checksum comparison, wrong decimals, off-by-one on gwei) become user-facing incidents. Cost of adoption is near zero; cost of a homegrown version is maintenance plus audit.
• Architecture decision: keeps the stack pure PHP with no C extension (ext-secp256k1, GMP quirks) and no sidecar service. That simplifies CI, Docker images, and shared-hosting/legacy deployment targets.
• Scope decision: it is a utility layer, not a client. Choosing it signals we will compose our own RPC/ABI layer (web3p/web3.php or internal code) rather than adopt a full SDK.
• Display and validation decisions: makes it cheap to validate user-entered wallet addresses at the edge, store canonical checksummed addresses, and render human-readable token amounts — small features that quietly prevent support tickets and lost funds.

When to Consider This Package

Adopt when:

• The product is PHP/Laravel and needs primitives, not a full Ethereum client: checksums, hashing, key/address derivation, unit math, selectors.
• Deployment constraints make C extensions or a separate Node/Go service unattractive (shared hosting, minimal containers, small team).
• You want a small, composable dependency behind your own internal EthereumUtils interface, so the vendor can be swapped later.
• You need something maintained recently (last release 2025-11-15) with a permissive MIT license and simple version pinning.

Look elsewhere when:

• You need RPC calls, ABI encoding/decoding, transaction building/signing, or contract interaction — use web3p/web3.php or an equivalent full SDK.
• Security posture demands widely audited, heavily depended-on crypto code. Eight stars, zero dependents, and effectively a single maintainer is a genuine bus-factor and review risk for anything touching private keys.
• You require HSM/hardware-wallet signing, or high-throughput signing where pure-PHP performance becomes a bottleneck.
• Node/Go/Python is already in the stack and better-supported libraries exist there; a sidecar may be the lower-risk path.

Mitigations if adopted: pin the exact version, wrap it behind an internal interface, add our own regression tests against known Ethereum test vectors, and keep a documented fallback (kornrunner/keccak, simplito/elliptic-php, or a managed key service) for the signing paths.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed, pure-PHP library that gives our Laravel stack the Ethereum plumbing we would otherwise hand-write or buy through a vendor. Adoption cost is one Composer dependency and no infrastructure change. It reduces the risk of the quiet, expensive bugs — mis-validated addresses, wrong decimal handling, broken signature checks — that turn into lost funds or support escalations. The trade-off is maturity: it is a low-adoption, single-maintainer project, so we pin the version, wrap it in our own interface, and keep an exit path. Net: low cost, contained risk, faster delivery of any feature that touches wallets, tokens, or on-chain payments.

For engineering: Narrow, composable, MIT-licensed, actively released. It handles the tedious correctness-critical bits — EIP-55 checksums, keccak-256, unit conversion, selectors — so we don't reimplement them. No extensions, no sidecar, easy to containerize. It is not an RPC or ABI client: we still own the transport and contract layer. Recommended integration: pin the version, hide it behind an internal service/interface, cover it with known-vector tests, and treat key-handling paths as requiring additional review or an external signer before we ship them.