Web3 Laravel Package

Product Decisions This Supports

• Feature viability spikes for on-chain capabilities. This package lets a Laravel/PHP team read balances, call contracts, and broadcast signed transactions without standing up a Node/TypeScript service. That makes it a cheap instrument for answering "can we ship this in the monolith?" before committing roadmap or headcount.
• Token gating and membership. ERC-20/ERC-721 balance checks at login or checkout. Informs whether gating is a v1 differentiator or a v2 integration.
• Crypto payment reconciliation. Watch addresses, match on-chain transfers to orders, mark invoices paid — the evaluation path for stablecoin/ETH checkout.
• Wallet-based auth (Sign-In with Ethereum). Signature verification for passwordless login; helps decide if wallet auth matters to our audience.
• Build vs. buy input. Produces concrete numbers — latency, error handling, ops burden — to benchmark against hosted providers (Alchemy, Infura, Moralis) and against writing raw JSON-RPC by hand.
• Internal tooling. Treasury dashboards, contract admin panels, allowlist/airdrop management: low-traffic surfaces where a thin RPC client is genuinely sufficient.
• Explicitly not a decision driver for: high-throughput indexing, custodial key management, L2 bridging, or anything requiring audit-grade signing guarantees. Those are buy-and-integrate decisions.

When to Consider This Package

Consider it when:

• You're on PHP/Laravel and need Ethereum JSON-RPC inside the existing request lifecycle — no new runtime, no sidecar, no new deploy target.
• The workloadis low-volume and read-heavy (balance lookups, contract reads, occasional sends).
• You want a time-boxed spike to estimate effort before a roadmap commitment.
• You're willing to vendor or fork — MIT makes that legally trivial.

Look elsewhere when:

• Maintenance risk is unacceptable. This repository is archived: no security patches, no new chain/RPC support, no response to breaking changes in Ethereum clients or PHP versions. For anything customer-facing and long-lived, that is a hard stop unless we own the fork.
• You need active support — prefer the maintained web3.php lineage or a hosted provider SDK with an SLA.
• You need signing and key management in production. Private keys never belong in the application tier; use KMS/HSM or a custody provider regardless of client library.
• You need event indexing, reorg handling, or historical queries at scale — that's a dedicated indexer, not an RPC client.
• You need multi-chain/L2 abstraction or gas policy — this gives raw RPC, not strategy.

How to Pitch It (Stakeholders)

One-liner: A capable, MIT-licensed PHP client that lets our Laravel app talk to Ethereum directly — excellent for de-risking a crypto feature cheaply, not something to build a revenue-critical path on as-is.

For executives: If we're evaluating any on-chain capability — token gating, crypto checkout, wallet login, NFT membership — this package lets a PHP engineer produce a working prototype in days rather than standing up a new service in a new language. That is a cheap way to buy information before we commit roadmap and hiring. The catch is decisive: the project is archived, so it is a prototype and internal-tooling tool, not a production dependency. Approve a spike, not a platform.

For engineering: Thin, forkable RPC client with reasonable ergonomics for contract calls and transaction sending. Treat it as a reference implementation: if the spike validates, either fork and own the maintenance or swap to a maintained client or provider SDK. Put an abstraction boundary around the client so that swap is a one-file change.

Recommendation: Fund a 1–2 week spike behind a feature flag with a written exit criterion — "fork and own" or "replace with provider SDK" — decided before any customer sees it. Do not add it to a long-lived production service's dependency manifest without a named owner.