Laravel Bitcoin Laravel Package

Product Decisions This Supports

• Build vs. buy for Bitcoin plumbing. The value here is commodity glue: a Laravel-configured wrapper around Bitcoin Core's JSON-RPC plus wallet primitives (address generation, balance, send, transaction lookup, mnemonic handling). Writing that yourself is days, not quarters of work — so the decision is not "build a Bitcoin integration from scratch" but "adopt a thin wrapper or a hosted node/API provider." Frame the package as a shortcut, not a platform.
• Scope split — the most important PM call. The package bundles two very different risk profiles: (a) an RPC client for node operations, which is low-risk, easily replaced, and testable against a regtest node; and (b) BIP39 mnemonic/seed generation, which is a cryptographic critical path where a silent behavior change loses customer funds. Approve (a) and (b) separately, with separate gates. Do not let one "composer require" imply both are equally vetted.
• Custody model decision. Whether the product holds keys at all is a business/compliance decision this package surfaces. It supports non-custodial flows (generate a phrase, user backs it up, we never derive from it), watch-only/treasury ops (xpub + derivation paths, no signing), and low-value hot wallets. It does not substantiate a full-custody, insured, audited wallet product — don't let a working prototype create that expectation on the roadmap.
• Feature enablement and sequencing. Concrete near-term candidates: per-user BTC deposit addresses, payment status/confirmation polling, treasury balance dashboards, and account onboarding with recovery-phrase UX. All are incrementally shippable on top of the RPC path before anyone touches the key path.
• Sourcing input for the custody roadmap. A short spike on this package is a cheap way to validate demand and internal capability for BTC support before committing budget to a regulated custodian, MPC vendor, or hardware-wallet integration. It is also a legitimate reference implementation if you later buy.
• Maintenance and ownership budgeting. Release discipline is thin (a one-line note shipping a dependency removal as a patch version), the project is small (4 stars), and there is effectively no bus factor. That's a real roadmap input: either budget recurring engineering time to pin, diff, and verify upgrades, or mandate an internal interface in front of it so it stays swappable.
• Documentation/scope audit item. The package describes itself as a Bitcoin Core RPC + wallet-ops integration, while the reviewable detail concentrates almost entirely on BIP39 behavior. That mismatch is itself a PM-relevant finding: we do not have a reliable, single-source statement of what is production-ready. Assign someone to read the source and produce a capability matrix before it goes on any roadmap slide.

When to Consider This Package

Consider it when:

• You're a Laravel/PHP shop, Bitcoin is the only chain you need, and it's a supporting feature rather than the product.
• You already run — or are willing to run — your own Bitcoin Core node; the wrapper assumes RPC access and does not replace node operations.
• Volume is low to moderate and you can tolerate polling Bitcoin Core rather than running a dedicated indexer.
• The use case is non-custodial onboarding, watch-only treasury visibility, internal tooling, testnet/regtest proofs-of-concept, or a deliberately capped hot wallet.
• Your team has, or will assign, someone who can run official BIP39 test vectors and reason about determinism. This is a hard prerequisite, not a nice-to-have.
• You want the convention-over-configuration Laravel experience — service provider, publishable config, facades — and are willing to wrap it in one domain service anyway.

Look elsewhere when:

• Nobody wants to operate a node. Use a managed node/RPC provider or a hosted blockchain API; this package adds nothing there.
• You need genuine custody: regulated custody, insurance, key ceremony, MPC/threshold signing, HSM backing, or audit attestations. That's a vendor decision, not a Composer decision.
• You need high-throughput address scanning, historical backfills, or mempool-scale indexing. That's electrs/Esplora/indexer territory; Bitcoin Core RPC will become the bottleneck and the on-call burden.
• Multi-chain or an EVM roadmap is plausible in the next 12–18 months. Adopting a single-chain wrapper now creates a migration you'll pay for later.
• Procurement requires a support SLA, security review artifacts, or a named maintainer with a track record. A small, single-maintainer project with one-line release notes won't clear that bar.
• The feature is customer-facing and custody-adjacent on a near-term deadline. The verification work (vectors, round-trip parity, normalization, secret redaction) is real calendar time you must fund up front.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is an MIT-licensed Laravel package that lets us add basic Bitcoin support — deposit addresses, balance checks, transaction lookups, and recovery-phrase onboarding — without building Bitcoin infrastructure ourselves. Integration cost is low and conventional: a Composer install, a config file, and one internal service class. What we are buying is convenience, not a security guarantee. The package is small, maintained by effectively one person, and its release notes are thin enough that a dependency change shipped as a patch version. My recommendation is a scoped pilot — testnet first, then a deliberately capped mainnet hot wallet or a non-custodial flow — with a defined verification gate (official BIP39 test vectors plus a round-trip parity check across versions) before any customer funds are involved. I need a named engineering owner and roughly one to two engineer-weeks of spike and hardening time approved; the risk isn't the integration, it's skipping the verification.

To engineering — the ask: Small, conventional package: auto-discovered provider, facades, publishable config. Wrap it in a single MnemonicService/BitcoinService so the underlying library stays an implementation detail. Pin the exact version rather than a caret range until the suite is green. Add fixed-vector tests (exact expected mnemonic for known entropy), not "12 words were returned" assertions — that's the only thing that catches silent drift. Verify NFKD normalization for non-English wordlists and passphrases, and scrub phrases from exception messages and request logs. Isolate the node-RPC path from the key path so one can ship without the other.

The decision I'm asking for:

1. Approve a time-boxed spike plus verification budget, with a single named owner for this dependency.
2. Decide the custody stance — non-custodial, watch-only, or capped hot wallet — before build, because that decision determines whether this package is sufficient or merely a prototype.
3. Accept the framing: cheap to adopt, cheap to replace only if we keep it behind our own interface, and expensive to get wrong if we treat a patch release as routine.