Solidity Laravel Package

Product Decisions This Supports

• Feature scoping: EVM read paths without leaving PHP. Enables a PHP product to encode contract calls (function selectors, ABI params), decode return values, and parse event topics — enough to ship balance lookups, token metadata, event-driven webhooks, or admin dashboards without a Node/Go sidecar.
• Build vs. buy: codec in-house vs. library vs. SDK. Frames the cheapest viable option for ABI encoding/decoding as a narrow helper rather than a full Web3 SDK. Useful input to a "do we add on-chain support to the PHP monolith or introduce a separate blockchain service?" decision.
• Roadmap gating for chain-adjacent features. Lets you estimate the cost of thin on-chain features (allowlist checks, NFT ownership verification, payment reconciliation) at days, not sprints — then decide whether the feature is worth the residual maintenance and security risk.
• Use cases to green-light: internal tooling, back-office reconciliation, test fixtures and fixtures generation, read-mostly data enrichment, prototype/demo of "PHP talks to a contract."
• Use cases to block by default: key custody, transaction signing, high-value transfers, anything customer-facing and money-moving, without an audited path and active maintenance ownership.
• Vendor/ownership planning. With 19 stars, zero dependents, and a last release in December 2020, the real decision is not "adopt or not" but "do we fork and own this?" Treat adoption as a small, capped bet.

When to Consider This Package

Consider it when:

• The backend is PHP and the on-chain surface is small and well-bounded: selectors, ABI encode/decode, event topic parsing.
• You want to avoid operating a Node/ethers sidecar for a handful of read calls.
• The usage is read-mostly, internal, or prototype-stage, where a bug is recoverable.
• You can wrap it behind an internal interface, vendor the source, and pin it — accepting that you may own patches.
• Licensing matters and MIT is acceptable (it is).

Look elsewhere when:

• The flow touches signing, key management, or value transfer — use maintained, reviewed tooling or a managed provider (RPC/SDK from Infura/Alchemy, ethers/viem in a small service, or an actively maintained PHP Web3 stack such as web3.php where it fits).
• You need active maintenance, PHP 8.x guarantees, security advisories, or typed/modern APIs — a 2020 last release and zero dependents are abandonment signals, not neutral facts.
• You need a full RPC client, wallet/HD derivation, or contract deployment — this is a helper, not an SDK; pick a broader library or a service.
• The roadmap implies on-chain work becoming core rather than incidental — a dedicated service in a better-supported ecosystem will age better than a PHP helper you must fork.

How to Pitch It (Stakeholders)

Executive summary. This is a small, MIT-licensed PHP helper for Solidity ABI work — computing function selectors, encoding/decoding parameters, and handling event topics. It lets a PHP backend talk to smart contracts directly, avoiding a separate Node service for narrow, read-mostly use cases. Integration is roughly a day to a few days including tests and an abstraction layer, versus one to two sprints for a dedicated sidecar. The trade-off is ownership risk: low adoption, no dependents, and no release since December 2020 mean we should treat it as glue we may need to fork — not as a foundation. Recommended posture: approve for internal tooling, read paths, and prototypes behind an internal interface; exclude from signing and money-moving flows unless security review and a maintained fork are funded.

For engineering. Pure PHP, MIT, no runtime services. Wrap it in our own ContractCodec interface so it is swappable; vendor the source, pin the version, and add golden-vector tests against known ABI encodings. Budget a short spike to confirm PHP version compatibility and edge-case coverage (dynamic types, tuples, arrays). The cost is small; the discipline is what protects us.