Zumokit Bundle Laravel Package

Product Decisions This Supports

• Multi-wallet as a first-class product capability. The 1.0.9 change to the User and Wallet entity interfaces moves the package from "one crypto account per user" to "multiple wallets per user." This directly unlocks product surface area: per-asset balances, portfolio views, multi-chain accounts, and account-switching UX. If multi-wallet is on your roadmap, this release is the enabling dependency; if it is not, the change is neutral-to-negative complexity.
• Build vs. buy on wallet/ledger primitives. The package supplies user↔wallet association and entity contracts rather than a full ledger. That argues for buy/borrow the model layer, build the money-movement layer — you avoid re-deriving account modeling while keeping custody, reconciliation, and compliance logic in-house where audit requirements demand it.
• Integration cost estimation. The addition of a documentation root (Resources/doc/index.rst) and a dedicated Zumokit Bundle integration guide (Resources/doc/index.md) gives engineering a concrete basis for scoping onboarding effort instead of a spike.
• Test and static-analysis posture as a vendor-risk input. New functional test scaffolding (phpunit.xml.dist, composer changes) and PHPStan (dev-only) are the kind of signals that justify a "buy" recommendation to a skeptical engineering lead — but they are signals of intent, not proof of coverage.
• Roadmap gating decision. Treat the interface change as a contract-stability event, not a routine patch. Pin the version, read the interface diff, and decide whether your code depends on the old single-wallet shape before any upgrade commitment.

When to Consider This Package

Adopt (with diligence) when:

• You need multiple crypto accounts per user and do not want to design that association model from scratch.
• You are on Symfony, not Laravel — the release ships Resources/doc/index.rst, a phpstan-symfony dev dependency, and bundle-style docs. The "Laravel/PHP package" framing does not match the artifacts; confirm framework fit before anything else.
• Your team will own custody, signing, reconciliation, and compliance; the package only needs to model the account boundary.
• You can absorb interface churn: "Improved User and Wallet entity interfaces" plus "Removed excess code" in a patch-level release (1.0.9) is a compatibility risk. Verify against your own subclasses/implementations.

Look elsewhere or defer when:

• You need a maintained, actively-supported dependency. The toolchain referenced here — Travis CI, Flint CI, a 2020-era release — reads as dormant. For anything touching balances, an unmaintained dependency is a standing liability.
• You require semantic-versioning guarantees; interface improvements landed in a patch release is a yellow flag on release discipline.
• You need out-of-the-box Laravel service providers, facades, or config publishing — none are evidenced.
• Your scope includes transaction history, fee handling, or on-chain indexing; this package does not appear to address those.

How to Pitch It (Stakeholders)

To executives: This is a small, narrowly-scoped PHP component that models the link between a user and their crypto wallets. The 1.0.9 release makes that link support multiple wallets per user — the capability we would need for asset-specific accounts and portfolio views — and adds test scaffolding and integration documentation, which lower the cost and risk of evaluating it. It is not a payments or custody system; it is a starting data model. My recommendation is a time-boxed spike, not an adoption decision: the package shows signs of being unmaintained, so we validate the multi-wallet model against our requirements and then decide whether to depend on it or reimplement the ~small surface we actually need.

To engineering: The 1.0.9 interface changes to User and Wallet are the substantive item — assume they are breaking for anything implementing or extending those contracts, and diff before upgrading. New functional-test plumbing and PHPStan (dev-only) improve confidence but should be verified for actual coverage rather than assumed. Note the framework mismatch: the artifacts are Symfony bundle conventions, so confirm this is the right target for a Laravel codebase before investing in integration.

Decision requested: Approve a short evaluation spike with an explicit exit criterion — either the multi-wallet model fits and the maintenance risk is acceptable, or we take the entity design as reference and own the implementation.