Sr25519 Bindings Laravel Package

Product Decisions This Supports

• Ecosystem entry decision — Substrate/Polkadot vs. staying EVM-only. This package is one of the very few ways to do sr25519 key generation, signing, and verification natively inside a PHP process. If a roadmap item is "support Polkadot/Kusama/Substrate-based chains," this is a concrete data point that the signing primitive exists in our stack — the decision it informs is go/no-go on Substrate as a supported network, not "which library do we use."
• Build vs. buy vs. sidecar architecture. The real product question is where signing lives: (a) in-process PHP via FFI with this package, (b) a Rust/Node signing microservice using schnorrkel/@polkadot/util-crypto, or (c) delegating to a wallet or custody provider. This package makes option (a) cheap enough to prototype, which lets you price the trade-off honestly: FFI in-process is faster to ship, worse to operate and audit.
• Authentication feature scoping. Enables "Sign-In with Substrate wallet" (challenge/nonce issuance, signature verification against an SS58 address) — a discrete, low-risk feature that only needs verification, not key custody. That is the highest-value, lowest-risk use case here.
• Backend service features that need to sign: faucets, airdrop distribution, NFT/token minting, validator/collator monitoring attestations, bridge or oracle attestation signing. All of these put a hot key in the PHP process, which should trigger a security review before commitment.
• Address handling and validation. SS58 address validation/derivation and signature verification are useful even in read-only products (dashboards, explorer-adjacent tooling) where no secret ever touches the app.
• Roadmap sequencing input. Because it is a primitive and not a platform, adopting it does not create product differentiation. The 23.7 opportunity score and 2 stars reflect that: treat Substrate support as a market-access bet with its own business case, not as a capability this package makes strategically attractive.
• Not a decision it supports: generic "crypto wallet login." Most Laravel wallet-auth demand is secp256k1/Ethereum (SIWE), which this does nothing for. Don't let it anchor a broader Web3 strategy.

When to Consider This Package

Adopt (or prototype with) it when all of these hold:

• You specifically need sr25519 — Substrate/Polkadot/Kusama signatures. It is not a substitute for ed25519 (use sodium) or secp256k1 (use simplito/elliptic-php or an Ethereum library).
• Your need is signing primitives only — keypair, sign, verify. It is not an extrinsic builder, SCALE codec, or RPC client; you will still need Substrate RPC access plus a SCALE encoder to submit anything on-chain.
• You can run PHP with the FFI extension and ship platform-specific native binaries. That means controlling your runtime: custom Docker images are fine; Laravel Vapor, shared hosting, and locked-down PHP-FPM builds are not.
• You are willing to vendor or fork it. One maintainer, two stars, zero dependents, a single 2024 release, no evidence of a third-party audit. MIT licensing makes a fork viable — budget for it rather than assuming upstream support.
• Secrets stay off the critical custody path, or you accept a documented risk. If the business is holding customer funds, this belongs behind an HSM/KMS or a dedicated signing service, not in a Laravel job worker.

Look elsewhere when:

• You only need occasional verification (e.g., login). A small Rust/Node sidecar or an RPC/light-client call is less operational surface than FFI binaries in every container.
• You need production key custody. Use a KMS/HSM-backed signer or a custody provider; sr25519 support there is the actual gating question.
• You need a full chain integration. Pair with a SCALE codec and Substrate RPC client, or use @polkadot/api in a service — the ecosystem maturity is on the JS/Rust side.
• You can't control the runtime (serverless, Vapor, managed PHP hosts).
• The Substrate requirement is speculative. With no committed customers or revenue attached, the maintenance and security overhead of a native dependency is not justified by a two-star package.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed building block that lets our PHP backend create and verify Substrate (Polkadot/Kusama) signatures in-process. It is not a product and not a differentiator — its only job is to answer "can we support Substrate chains without standing up a second backend language?" The answer is yes, cheaply enough to prototype. The caveat is maturity: one maintainer, negligible adoption, no audit, and a native-binary deployment requirement. Recommendation: fund a short spike only if a Substrate network is on the roadmap for a named customer or partner, and plan to own a fork rather than depend on upstream.

To engineering: Treat it as a thin FFI wrapper over schnorrkel — sr25519 keypair, sign, verify, SS58 handling. It is not an extrinsic builder, SCALE codec, or RPC client, so scope the surrounding work accordingly. Hard requirements: PHP FFI enabled, per-platform .so/.dylib/.dll in your images, no Vapor/serverless. Isolate it behind an internal Signer interface so we can swap to a Rust signing service without touching call sites, pin the version, and vendor it. Signing keys must not live in the app process for anything touching real value — route those through KMS/HSM or a dedicated signer from day one; use this package first for verification (wallet login, address validation), which carries no key-custody risk.

To security/compliance: No evidence of third-party audit, single maintainer, zero dependents. Acceptable for public-key verification; not acceptable as-is for custody of funds. Any hot-key use requires a documented threat model, key isolation, and a plan to fork and review the native module.