Bitcoind Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. vendor for BTC integration: Informs whether to wire a JSON-RPC client to Bitcoin Core ourselves, adopt a maintained library, or use a managed node provider — this bundle is a data point that "vendor the wrapper" is the wrong shape for a modern PHP/Laravel codebase.
• Roadmap scoping for crypto payments/treasury: Clarifies that the PHP side of "accept BTC" is cheap (days) and the node side is expensive (storage, sync, ops, compliance). Useful for pricing the feature honestly rather than anchoring on library effort.
• Framework strategy validation: Serves as a concrete example in the "do we still support Symfony2-era code?" debate; it is an EOL-framework artifact with no Laravel fit, which strengthens the case for standardizing on Laravel-native, maintained dependencies.
• Architecture boundary decisions: Supports the call to isolate crypto operations behind a first-party interface (e.g., BitcoinRpcClient) so the client library, node provider, or even chain can be swapped without product rework.
• Discovery/validation signal: 15 stars, 0 dependents, no maintenance cadence — a defensible input for a "do not adopt" recommendation in a build-vs-buy review, not a reason to adopt.
• Risk register input: Helps surface the real failure modes early (node in IBD, missing -txindex, reorg handling, credential exposure, RPC deprecation) so they land on the roadmap as owned workstreams rather than launch-week surprises.
• Use-case triage: Distinguishes read-only chain/address queries (low complexity, viable) from wallet/signing/send paths (high blast radius, separate review) — a useful scope-splitting lever for a PM.

When to Consider This Package

Consider it (as a reference, not a dependency) when:

• You need a short technical spike to size BTC integration and want a working example of how JSON-RPC wiring looks in a PHP DI container.
• You operate an existing Symfony2 application that already talks to a trusted, self-hosted bitcoind, and the need is narrow: config, service wiring, RPC passthrough.
• The context is an internal tool or prototype where a thin wrapper saves boilerplate and the team has explicitly accepted the maintenance risk.
• You want to harvest the underlying nbobtc/bitcoind-php client and re-bind it as a Laravel service provider — the bundle's service definitions are trivial to reproduce.

Look elsewhere when:

• You're on Laravel (the default case here). This is a Symfony Bundle expecting the Symfony kernel; it does not fit Laravel's service container. Consume the client library directly or use a maintained Laravel wrapper.
• You're on Symfony 3.4+, 5/6/7, or PHP 8. Symfony2 is end-of-life (2018); its conventions and Guzzle-era dependencies will conflict with contemporary stacks.
• You need production-grade crypto. Custody, key management, multi-sig, signing, and compliance belong in a hardened, actively maintained library or a managed service — not a 15-star, zero-dependent wrapper.
• Supply-chain confidence matters. No dependents, no advisory feed, no visible maintenance cadence means no community surfacing of defects and no guaranteed patches.
• You need Lightning, HD wallets, exchange-grade operations, or high-throughput reads — out of scope entirely; plan for batching, caching, and multiple nodes instead.
• Nobody on the team has run a full node. Then the managed-provider route (QuickNode, Blockdaemon, Chainstack) should be the default, and the package is irrelevant either way.

Recommendation: Treat as a reference implementation and a teaching artifact for RPC wiring, never as an adoption candidate. Budget for a maintained client library behind a first-party interface, plus node operations as a separately costed workstream.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Symfony2 bundle that connects a PHP app to a self-hosted Bitcoin node via JSON-RPC. It is free to license and cheap to evaluate, but it carries essentially no ecosystem validation (15 stars, zero dependents), targets a framework that reached end-of-life in 2018, and is not usable in a Laravel codebase. Recommendation: do not make it a production dependency. Approve at most a short spike that uses it as a reference for sizing; the real investment is the node — roughly a terabyte of fast storage, a multi-day sync, and ongoing operations — not the PHP code, which is measured in days. If BTC acceptance is on the roadmap, fund a maintained client behind our own interface and default to a managed node provider, with self-hosting as an explicit, separately costed option.

For engineering: The bundle is ~4 files of DI glue around nbobtc/bitcoind-php — no domain model, no transport abstraction, no maintenance. Do not install it. Instead: (1) vendor or pin the underlying client and accept a fork; (2) define our own narrow BitcoinRpcClient interface covering only the methods we actually call, and implement it against that client — this is the highest-value decision, because it makes the library swappable and the RPC surface auditable, and gives us one place for logging, metrics, timeouts, and retries; (3) bind it as a Laravel singleton with credentials from the secret manager, a health check, and a circuit breaker; (4) keep the provenance in a commit message and nothing else. Before any code, map every intended RPC call against the specific Bitcoin Core version the node runs — getinfo, getaccount*, move, and sendfrom are gone or deprecated, and signrawtransaction is now signrawtransactionwithwallet. Sequence regtest spike → interface + adapter + observability → node ops runbook and testnet rehearsal (including a deliberate reorg and restart) → production read paths with a managed-provider failover. Wallet and write paths, if needed at all, land later and behind a separate review. Assume zero upstream support: budget ~0.1–0.2 FTE for dependency stewardship, and nominate a standing owner for "Core upgrade review" — RPC deprecations, not launch bugs, are what bite teams two years in.