Erd Laravel Laravel Package

Technical Evaluation

Architecture fit. mx-sdk-laravel is a thin Laravel service-provider wrapper around the MultiversX PHP SDK (mx-sdk-php). Its architectural role is narrow and well-boundaried: register a singleton client, expose config (network endpoint, chain ID, PEM/keystore paths), and publish a facade. For a TPM this is a low-blast-radius dependency — it should sit behind your own adapter/interface so application code never imports the vendor facade directly. The v3.0.0 change does not alter this architecture; it is a framework-compatibility release, not a design change.

Integration feasibility. High, with a caveat. The release is a single PR ("Add Laravel 12 compatibility") promoted to a major version. That versioning signals a constraint change, not a feature change: the most likely mechanics are a bump to illuminate/support ^12.0 and/or a raised PHP floor. Integration is therefore trivial on Laravel 12 and potentially blocked on older versions. Assume composer require will fail on Laravel 10/11 until you confirm the new constraint set — verify this before scheduling work.

Technical risk.

• Ecosystem coupling (medium-high). The package is effectively a pass-through to mx-sdk-php. Real breaking-change risk lives upstream (MultiversX protocol/API changes, PHP SDK majors), not here. Pin and monitor the transitive SDK.
• Maintainer concentration (high). Single contributor on the visible commit history; the org (PeerMeHQ) is the durability backstop. A major bump with a one-line changelog and no migration notes is a signal of low release-engineering maturity, not necessarily low quality.
• Semantic-versioning discipline (medium). Jumping 2.3.0 → 3.0.0 for a compat addition is correct semver (dropping framework support is breaking) but it means you cannot infer risk from the diff. Read the composer.json diff, not the release notes.
• Supply chain (low-medium). Standard Composer risk; no indication of abandoned status, but low release cadence means security fixes may lag.

Key questions.

1. What exactly changed in composer.json — PHP floor, illuminate/* constraints, and mx-sdk-php range?
2. Does v3.0.0 still support Laravel 10/11, or is this a hard cutover? Is a 2.3.x LTS-style branch maintained?
3. Is mx-sdk-php bumped as a transitive consequence, and does that carry its own breaking changes?
4. What is the maintainer/org support commitment — issue triage SLA, security disclosure path?
5. Are there consuming services on Laravel ≤11 that would be stranded by this release?

Integration Approach

Stack fit. Clean, if you are on Laravel 11/12 and PHP 8.2+. The package is conventional: service provider, config file, facade — no queue workers, no migrations, no published assets beyond config. It imposes no opinions on your domain layer, which makes it a safe peripheral dependency. If you are on Laravel 10 or PHP 8.1, v3.0.0 is likely out of reach and you remain on 2.3.x.

Migration path. Assume a two-step:

1. Isolate first. If the package is currently called directly from application code, wrap it in a BlockchainClient interface with the vendor facade as one implementation. This is worth doing regardless of the upgrade and makes the version bump a one-file change.
2. Upgrade the host, then the package. Because the major bump is driven by framework constraints, the Laravel 12 upgrade is the critical path — mx-sdk-laravel v3.0.0 is the last step, not the first. Do not attempt to isolate this package upgrade from a framework upgrade.

Compatibility. Confirm the matrix explicitly rather than inferring: Laravel 10 / 11 / 12 × PHP 8.1 / 8.2 / 8.3 / 8.4. Pay particular attention to the PHP floor, since Laravel 12 raises it and the SDK may follow. Check whether mx-sdk-php itself supports the PHP version you intend to run.

Sequencing.

1. Read the composer.json diff on the v2.3.0…v3.0.0 compare (available in the linked changelog) — this is the authoritative source, not the notes.
2. Inventory which services depend on the package and their current Laravel/PHP versions.
3. Introduce the adapter/interface wrapper and remove direct facade usage.
4. Upgrade host framework to Laravel 12 in a staging branch; run integration tests against MultiversX devnet/testnet, not mocks alone.
5. Pull v3.0.0; verify transaction signing and read paths end-to-end.
6. Keep a 2.3.x pin documented as rollback for any service that cannot move.

Operational Impact

Maintenance. Minimal in steady state — the wrapper is small and rarely changes. The maintenance burden is concentrated in tracking: you must watch three things (this package, mx-sdk-php, MultiversX network/API changes). Assign an owner who reviews upstream releases quarterly; the low cadence here makes it easy to miss a year of drift.

Support. Realistically community/org-supported, not vendor-SLA-backed. Do not place this on a critical path that requires guaranteed response times without an internal fallback (calling the MultiversX REST API directly is a viable escape hatch and should be documented as such). Establish an internal "if this package is abandoned" runbook now, while the surface area is small.

Scaling. Not a scaling concern in the conventional sense — the package is a client library, so throughput is bounded by outbound HTTP to the MultiversX gateway and by your own signing/key-management approach. Watch for: connection pooling and timeouts on the Guzzle client, rate limits on the public gateway (plan for a dedicated/paid endpoint at volume), and key storage — PEM files on disk are the default and are a poor fit for multi-instance deployments. Move secrets to a managed secret store and consider an external signer if throughput or compliance demands it.

Failure modes.

• Composer resolution failure on upgrade — the most likely and most immediate; surfaced at build time, cheap to detect, cheap to fix by pinning.
• Framework/package drift — host upgrades pass but the SDK lags (or vice versa), leaving you stranded mid-migration. Mitigate by tracking the compatibility matrix in your dependency register.
• Silent upstream protocol change — MultiversX changes an endpoint or payload shape; the wrapper passes it through and your transactions fail at runtime. Mitigate with contract tests against testnet in CI.
• Key/credential mishandling — misconfiguration here is a fund-loss failure mode, not an availability one. Treat config changes as change-managed.
• Abandonment — no releases for an extended period. Low severity given the escape hatch, but only if you built the adapter.

Ramp-up. Low for any Laravel developer — a service provider and a facade are familiar territory; expect under a day to first working transaction. The real ramp-up cost is domain knowledge: MultiversX transaction structure, gas/nonce handling, and key management. Budget that learning separately and do not confuse "the package is easy to install" with "the integration is easy to get right." Enforce the adapter boundary in code review so the learning curve is contained to one module.