Icobench Client Laravel Package

Product Decisions This Supports

• Historical reference for ICO due-diligence tooling, not a live capability. kami/icobench-client is a thin 2018 wrapper around the ICOBench ratings API — a service that has been offline for years. Its value today is as an archaeological sample of how token-diligence tooling was assembled during the 2017–2018 ICO boom, not as an input to any current roadmap.
• Pattern reference for the API-client layer of a new build. If we are designing our own vendor-client package (config-published credentials, Laravel service-provider binding, thin fluent request methods), this repo is a small, readable example of the genre at roughly the granularity we would write ourselves. Useful to skim, not to depend on.
• Build-vs-buy signal for crypto data ingestion. The package demonstrates how narrow these vendors are — one provider, one credential model, a handful of endpoints — and how quickly both the vendor and its wrapper evaporate. That argues for a thin in-house adapter behind our own interface rather than betting on a third-party SDK as a dependency.
• Not a viable input to any shipping decision. 3 stars, 0 dependents, no release since June 2018, and a defunct upstream. It carries no signal about current demand, ecosystem health, or integration risk beyond "do not adopt."

When to Consider This Package

• Archaeology only. You are auditing or resurrecting a 2018-era Laravel codebase and need to understand what it depended on, why, and what should replace it.
• Coding sample only. You want a minimal, MIT-licensed illustration of wrapping a REST API in a Laravel service provider before writing your own equivalent internally.
• Look elsewhere for live crypto or asset data. ICOBench's dataset is no longer served; current equivalents (CoinGecko, CoinMarketCap, Messari, CryptoCompare) have maintained clients and, critically, functioning endpoints and support commitments.
• Look elsewhere for anything production-bound. No tests, no CI, no releases in seven years, no maintainer activity, and single-person provenance all fail the baseline for a dependency in a paying customer's path.
• Look elsewhere if you need SLA, rate-limit handling, auth rotation, or schema versioning. None of that exists here, and none of it will be added.

How to Pitch It (Stakeholders)

To executives: This is not a dependency we should take on. It is a small, unmaintained client for a ratings vendor that no longer exists, last shipped in 2018, with essentially no adoption. There is no commercial upside and a clear maintenance liability if it ever reached production. Recommendation: do not adopt; treat it as background research only.

To engineering: Worth a five-minute read as a conventional Laravel API-client structure — service provider, publishable config, thin request methods over Guzzle. Not worth a dependency: no upstream service, no tests, no release cadence, and a single inactive maintainer. If we need this class of integration, we should own a thin adapter behind a swappable interface with an explicit deprecation path, because crypto data vendors churn on roughly a two-to-three-year cycle. This package is a concrete argument for that architecture, not against it.

Decision this unlocks: Redirect any ICO/asset-data exploration toward a current provider and a first-party client, using kami/icobench-client only as a reference for request signatures. Low-risk call; make it early and decisively.