Platform Core Laravel Package

Product Decisions This Supports

• Build vs. buy for digital-asset infrastructure. This package is the shared foundation of the Enjin Platform — Laravel-side models, services, and API surface for collections, tokens, mints, transfers, and wallet/daemon integration. If a roadmap item reads "let users own/collect/trade digital items," this is one of the concrete "buy/adopt" options on the table, alongside hosted providers and rolling our own.
• Chain and vendor selection. Adopting platform-core is effectively a commitment to the Enjin Blockchain/Matrixchain and to Enjin's release cadence. It belongs in the same decision record as "which chain, which custody model, which indexer" — not in a separate engineering ticket.
• Self-host vs. SaaS API. It supports the specific question of whether we run the Enjin Platform API ourselves (control, data residency, cost at volume) versus consuming Enjin's hosted platform or a competitor's API.
• Integration effort estimation. Because it's Laravel-native and GraphQL-oriented, it gives engineering a credible basis for sizing an integration inside an existing Laravel monolith rather than a greenfield service — useful input to a quarterly capacity plan.
• Use cases it plausibly unlocks: game asset and item marketplaces, tokenized loyalty/rewards, digital collectibles, studio-side minting and drop management, and internal admin tooling over on-chain state.
• What it should not drive: general architecture decisions, framework standardization, or anything outside the blockchain-asset domain. Its scope is narrow and vendor-specific.

When to Consider This Package

Consider it when:

• Enjin is already chosen — by strategy, by an existing partner, or by a client requirement — and we need the Laravel-side core rather than a from-scratch integration.
• We intend to self-host the Enjin Platform API and want the vendor's own decomposition of it instead of reverse-engineering their hosted service.
• The team is on modern Laravel/PHP, comfortable with GraphQL (Lighthouse-style schemas), queue workers, and operating stateful services.
• We have, or can staff, blockchain operations competence: wallet/key custody, transaction signing, fuel/gas management, indexer and reorg handling. This package assumes that world; it does not remove it.
• We are willing to pin versions and absorb vendor-driven breaking changes, because "core" packages are tightly coupled to their sibling packages and rarely promise long-term API stability.

Look elsewhere when:

• Adoption signals are absent. Zero stars, zero dependents, and a minimal opportunity score mean this is effectively a publicly published internal artifact, not a community-vetted library. There is no third-party evidence of production use, no ecosystem of examples, no external bug surface. Treat "public" as a distribution mechanism, not a signal of maturity or support.
• We are chain-agnostic or want hiring flexibility. Provider SDKs (Alchemy, thirdweb, Moralis) or lower-level libraries (viem/ethers, OpenZeppelin contracts) have larger talent pools and less single-vendor risk.
• We need SLAs, LTS guarantees, or a support contract. None of that is implied here; verify commercially before it appears in a roadmap.
• Regulatory posture on tokens/digital assets is unresolved in our markets. That is a legal question this package cannot answer, and it gates the feature regardless of technology choice.
• We don't actually need on-chain settlement. If the requirement is "users can own and trade items," a database plus payments provider is dramatically cheaper, faster, and more supportable. On-chain only wins when external ownership, composability, or provable scarcity is the actual product value.

How to Pitch It (Stakeholders)

To executives: Enjin Platform Core is the shared Laravel foundation of Enjin's blockchain API — the plumbing behind minting and managing NFTs and tokens. Adopting it is a bet on Enjin's chain and on Enjin as a vendor, not a general-purpose library purchase. It can compress time-to-market for digital-asset features if we are already committed to Enjin; otherwise it introduces single-vendor dependency with very little external validation (no meaningful community adoption or third-party usage we can point to). Recommendation: fund a time-boxed technical spike and a commercial/support conversation with Enjin — not a roadmap commitment.

To engineering: This is PHP/Laravel and GraphQL-first, so it fits inside our existing application rather than forcing a new service. Two conditions: pin the version and wrap it behind our own adapter so its models and schema never leak into our domain, and assume we own the operational burden — wallet daemons, key custody, fuel, and indexer reliability are ours, not the package's. Budget for vendor-driven breaking changes given its "core" coupling to sibling packages.

To finance/legal: Nothing here resolves custody, securities, or consumer-protection questions around tokenized assets. Those need to be cleared in parallel, and they — not the library — are the real gate on this feature reaching the roadmap.