Blockchain Context Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for crypto deposit infrastructure. This package is a candidate "buy" (MIT, free) for the plumbing of crypto payments: RPC clients, deposit detection chains, finality/confirmation polling, gas fetching, and deposit transaction building for TON + EVM. A PM can use it to scope a payments roadmap without budgeting a chain-integration team from zero — the differentiation is in the product layer (ledgers, reconciliation, UX), not in re-implementing JSON-RPC.
• Feature scoping: inbound deposit detection and crediting. The Detection\ChainDepositCheckChain, Finality\ConfirmationCheckChain, ConfirmationCounterRegistry, and DepthPollingFinalityVerifier map directly to "when do we credit a user's balance?" decisions — confirmation depth policy per chain, reorg tolerance, and polling cadence are configurable product levers rather than hardcoded logic.
• Roadmap option value: multi-chain expansion. The tagged-iterator extension model means adding a chain or a deposit builder is a drop-in service, not a DI rewrite. That materially lowers the estimated cost of a "add USDT-TRC20 / BTC next quarter" roadmap item, and the v0.7.2 Bitcoin Core evidence reader shows the architecture generalizes beyond the original two chains.
• Wallet and key-management architecture. PrivKeyEncrypter (AES-256-GCM at rest) plus DepositWalletDeriverInterface / DerivedWallet / DepositEvidence value objects let a PM frame the custody question early: are we deriving per-user deposit addresses and encrypting keys in our own database, or delegating to a custodian? That decision drives compliance scope, insurance, and incident response — it should be made deliberately, not inherited from a library.
• Signature-based authentication / off-chain verification. SignatureVerifier (EIP-191 personal_sign, TON Connect Ed25519) supports "sign in with wallet," proving address ownership before withdrawals, and verifying signed payment intents — a discrete feature a PM can schedule independently of the deposit pipeline.
• Vendor-risk line item on the roadmap. Single maintainer, 0 GitHub stars, 0 dependents, "readme"-level maturity, first release dated 2026-10-13 — this is pre-adoption infrastructure. A PM should record it as an explicit dependency risk with an exit plan, not treat "MIT and on Packagist" as equivalent to a supported vendor.
• Explicit non-goals it helps clarify. It does not provide a ledger, double-entry accounting, reconciliation against on-chain state, fraud/AML screening, chargeback handling, tax reporting, or a hosted indexer. Those remain product work and should be budgeted separately.

When to Consider This Package

Consider it when:

• The product genuinely needs self-custodied, programmatically derived deposit addresses on TON and/or EVM, and the team is comfortable owning key material (or has a KMS/HSM story to bolt on around PrivKeyEncrypter).
• You are on Symfony 7 / PHP 8.3+, or you are willing to run a thin Symfony kernel or adapter alongside a Laravel app. Note the framework mismatch: this is a Symfony bundle, not a Laravel package — there is no service provider, no config/*.php publishing, and no Laravel-native facade. Laravel adoption means writing and maintaining that bridge yourself, and the autowiring/tagged-iterator benefits largely evaporate outside the Symfony container.
• Server prerequisites are already satisfied — ext-gmp, ext-sodium, ext-openssl, ext-bcmath. These are non-trivial on locked-down or shared hosting; verify before committing.
• You value the "no external SDK / pure PHP" property. No Node.js sidecar, no vendor SDK bindings — one runtime for app and chain code. This is an operational-simplicity win worth quantifying.
• Volumes are modest and polling is acceptable. The design is poll-and-verify, not webhook/indexer-driven. Fine for long-tail payment flows; reconsider at high throughput.
• A spike is cheap. With PHPStan level 9, a 245-test suite, CI on 8.3/8.4, and MIT licensing, a two-to-three sprint technical evaluation is low-cost and low-legal-friction.

Look elsewhere when:

• You need a supported vendor with SLAs, security review artifacts, or a bounty program. There is none here. For a payments product handling real money, "one maintainer, zero stars, zero dependents" is a finding, not a footnote — plan to fork, pin, and own the code, or choose a custodial provider.
• You are Laravel-first and want a native package. The integration tax likely exceeds the value; you would be buying the underlying SDKs (amashukov/ton-php, amashukov/eth-php, amashukov/eth-rpc-client-php, amashukov/toncenter-client-php) directly and writing your own wiring.
• You need outbound payouts / treasury management / multi-sig. The surface is deposit-oriented; do not assume symmetry.
• You require broad chain coverage (Solana, TRON, L2s, Cosmos). Current scope is TON, EVM, and emerging Bitcoin support.
• You need production-grade observability, idempotency guarantees, or replay-safe ledger integration out of the box. You will build these; the bundle gives you the chain primitives, not the money-movement semantics.
• Compliance requires vendor due diligence sign-off. A 0-star, single-author dependency with no security audit will not survive most fintech procurement reviews without an internal fork-and-own commitment.

How to Pitch It (Stakeholders)

One line: An MIT-licensed, pure-PHP toolkit that gives us the chain-level building blocks for crypto deposits — RPC clients, deposit detection, confirmation tracking, gas estimates, and signature verification — so our engineers write payment logic instead of blockchain plumbing.

For executives: The strategic value is time-to-market and optionality. It compresses the "connect to a chain and detect a deposit safely" problem — normally several engineer-months of unfamiliar protocol work — into a configurable layer, and its extension model means adding a chain later is incremental rather than a rewrite. Cost is zero in license terms; the real cost is ownership risk. This is early-stage, single-maintainer software with no adoption to date. My recommendation is a time-boxed evaluation, not a production commitment: prove it in a spike on testnet, and if it holds, budget for us to fork it, pin the version, add security review, and treat it as internal code. If we are not prepared to own it, the honest alternative is a custodial payments provider.

For engineering: The design is sound and idiomatic Symfony — env-agnostic config tree, DI autowiring of typed clients, tagged-iterator chains so new chains/builders self-register without container edits, ports-and-adapters separation of domain services from the host app, AES-256-GCM key encryption, and EIP-191 + TON Connect verification. Quality signals are real: PHPStan level 9, php-cs-fixer @PER-CS, Rector dry-run, PHPUnit across PHP 8.3 and 8.4. The caveats are equally concrete: Symfony-only (Laravel requires an adapter we would maintain), PHP 8.3+ with gmp/sodium/openssl/bcmath, poll-based finality rather than an indexer, and no production track record. Please scope the evaluation to include: key-custody threat model, RPC provider redundancy and rate-limit behavior, reorg handling under the confirmation-depth policy, and an honest estimate of the Laravel bridge if we go that route.

Ask: Approve a two-sprint technical spike (testnet only, no customer funds) plus a written build-vs-buy-vs-custodian recommendation, with the explicit understanding that adoption implies a fork-and-own commitment and a named internal owner for the dependency.