Laravel Evm Laravel Package

Product Decisions This Supports

• Build vs. buy on the "chain plumbing" layer. The package is not a wallet product; it is the unglamorous 20% of an Ethereum feature that eats 60% of the timeline: nonce tracking, EIP-1559 fee derivation from baseFee + priority fee, receipt polling, reorg/replacement races, and queue-safe broadcast. A PM can frame adoption as buying back roughly 2–6 engineer-weeks and, more importantly, buying back the class of bugs that are silently wrong rather than loudly broken.
• Roadmap sequencing for a crypto/token feature. It cleanly splits the roadmap into a read track (contract call(), EvmLogs querying and ABI event decoding → balances, token holdings, transfer history, reconciliation) and a write track (sendAsync() → transfers, mints, approvals). The read track is low-risk and can ship first; the write track is where custody, treasury, and compliance decisions land. That split is a useful milestone boundary and a natural go/no-go gate.
• Feature feasibility and scope sizing. Concrete use cases this makes a one-sprint story rather than a research project: ERC-20 balance displays, on-chain payment acceptance for a checkout flow, token-gated content, NFT mint/claim endpoints, on-chain attestations, treasury payout batches, and internal admin dashboards that decode Transfer logs. Anything requiring sub-second finality, high transaction volume, or fiat on-ramp is out of its scope and belongs to a provider decision, not this package.
• Custody and key-management decisions. EVM_PRIVATE_KEY in .env is a hot wallet in your application's secret store. The Signer contract (v0.4.0 moved signing behind it, and PrivateKeySigner no longer exposes the key) means "we can swap in a KMS/HSM signer later without rewriting the transaction path" is a legitimate architectural option — a real decision point for whether this is acceptable for your value at risk.
• Operational model decisions. Async-by-default via EVM_QUEUE forces an explicit choice: which queue, which worker pool, what timeout, what dead-letter path. The v0.4.0 addition of a per-signing-address cache lock (one in-flight transaction per address) sets a throughput ceiling you should size against your roadmap now rather than discover at launch.
• Vendor and dependency risk register entries. 4 GitHub stars, 0 dependents, single maintainer at a German agency, current version 0.x. That is a real line item for a build-vs-buy review, and it is defensible only if paired with a stated mitigation (see below).
• Multi-chain scope. EVM_CHAIN_ID + per-chain RPC config makes "Ethereum mainnet, Polygon, an L2" a configuration exercise, not a rewrite. Chains without EIP-1559 semantics are a different conversation, and non-EVM chains are explicitly out of scope.

When to Consider This Package

Consider it when most of these are true:

• You are on Laravel 11, 12, or 13 with PHP ≥ 8.4, and you can install and enable ext-gmp (plus bcmath for arithmetic — v0.4.0 returns all integers as decimal strings, so any balance math needs bcmath/GMP).
• You already run Laravel Queues and Events in production and are comfortable with the operational model of a worker that polls for receipts. The event-driven design (TxQueued → TxBroadcasted → TxMined → TxFailed/TxReverted) maps onto existing listeners and logging rather than requiring new infrastructure.
• Your transaction volume is modest and human- or cron-paced — payouts, claims, mints, approvals — not a market-maker or exchange hot path.
• Hot-wallet risk is acceptable for the value in flight, or you are prepared to implement a Signer backed by KMS/HSM before going live with meaningful amounts.
• You need read-side chain data inside the app: token balances, event log filtering/decoding for reconciliation, or contract reads — and you would rather not build an ABI decoder and log filter builder yourself.
• You are building back-office, internal, or B2B tooling where a bug is costly but not a public incident, and where a small dependency footprint is preferable to a custodial SaaS contract.
• You want an MIT-licensed, forkable dependency with no per-transaction pricing and no vendor account provisioning in the critical path.

Look elsewhere when any of these are true:

• You need indexed, queryable, historical chain data at scale. This package polls. For transfer history, portfolio views, or "show me all activity" screens, use an indexer (Alchemy/QuickNode webhooks, The Graph, a subgraph, or a dedicated data provider). Do not build an indexer out of EvmLogs::chunked().
• Value at risk is high enough to require real custody. A custodial provider with policy engines, approval workflows, and insurance is a different product category; so is a Fireblocks/Coinbase-grade setup. Do not treat .env private keys as an acceptable end state for treasury.
• You need throughput beyond one in-flight transaction per signing address, or you are operating across many addresses concurrently and want a dedicated nonce/signing service.
• You are on PHP < 8.4 or cannot enable ext-gmp. The requirement is hard.
• You need a 1.x API guarantee or a support contract. This is 0.x, pre-1.0, and behavior has changed across minor versions by design.
• You need non-EVM chains, fiat on/off-ramp, or compliance tooling (sanctions screening, travel rule) — all out of scope.
• Your organization requires a vendor with SOC 2 / audited code / a support SLA. No third-party security audit is evidenced; v0.4.0 was an internal full audit that fixed several silently wrong value defects and a credential-logging issue.

If you adopt: pin the exact version, treat composer.lock as load-bearing, read UPGRADING.md before every minor bump, and budget for the real possibility of owning a fork — the codebase is small enough that forking is a viable mitigation, which is itself part of the argument.

How to Pitch It (Stakeholders)

To executives — one paragraph: "We can ship on-chain functionality — token payments, balances, transfer reconciliation, minting — as a normal Laravel feature instead of a blockchain project. This MIT-licensed package supplies the parts that are expensive and easy to get wrong: transaction queuing on our existing workers, fee calculation, nonce management, and step-by-step events we can log and alert on. It is a library, not a service: no per-transaction fees, no vendor account, no data leaving our infrastructure beyond the RPC provider we choose. The trade-off is maturity — it has a small user base and is pre-1.0 — so we pin the version and keep the integration thin enough to replace or fork. Recommended as a scoped pilot on a read-first, low-value write path, not as the foundation of a treasury system."

To engineering — the honest version:

• What you get for free: EIP-1559 fee derivation from baseFee and priority fee; automatic nonce tracking with an invalidation path; queue-safe async broadcast with timeout, retry guard, and multi-hash polling across fee bumps; typed RPC errors (RpcErrorException::isRevert() vs. RpcTransportException); ABI encode/decode including log topic filtering and event decoding; Receipt::isSuccessful() so a mined-but-reverted transaction is never credited; optional evm_transactions tracking table; a Signer contract so KMS/HSM is a swap, not a rewrite.
• What it costs you: ext-gmp and PHP 8.4; integers come back as decimal strings, so all amounts go through bcmath/GMP — no int casts, ever; a queue worker dedicated to EVM_QUEUE with correct $timeout; one transaction at a time per signing address, enforced by a cache lock; you own RPC provider selection, key storage, and alerting.
• Why the version history is a plus, not a minus: v0.4.0 is a full audit that added 151 tests (14 → 165, no skips) and CI across Laravel 11/12/13 in both prefer-lowest and prefer-stable. The defects it fixed — amounts clamped above PHP_INT_MAX, reverted transactions reported as mined, provider API keys written to laravel.log, ltrim($x, '0x') corrupting roughly 1 in 16 inputs — are exactly the failure modes you would hit building this yourself, and they are now covered by tests.
• Why it is a minus too: those bugs shipped in a released version, there are no external dependents, and there is one maintainer. Treat the dependency as a small, readable, forkable codebase you are prepared to own — not as a black box with a support line.
• Proposed guardrails: pin the version; read UPGRADING.md on every bump; start with read-only (call(), EvmLogs) to validate the ABI and provider path; ship the first write path with a value cap and an explicit Signer interface; add a reconciliation job that compares evm_transactions against chain state before trusting any ledger entry.