Crypto treasury management
Security guardrails on every deploy, and cloud waste cut automatically.
A treasury platform shipping several times a day needed security review on every release without slowing down, while its AWS and Datadog bills grew faster than usage.
- Company
- Coinshift
- Stage
- Venture-backed, US
- Stack
- AWS, Kubernetes on EKS, Datadog, Terraform, GitHub Actions
- Engagement
- Managed cost operations, then managed DevSecOps
- Agents
- Finly AI, Iris AI, Sage AI, ClearRisk
The situation
Coinshift runs treasury infrastructure for on-chain organisations: multi-signature workflows, reporting and integrations across many chains. Each new chain brought its own services, indexers and RPC node fleets, and each shipped on its own cadence.
The engineering team deployed several times a day. Security review of those deployments was manual, so it either slowed releases or got skipped. At the same time the AWS and Datadog bills were growing faster than users or transactions, and nobody had the hours to find out why.
The team had tried the usual fixes. A cost dashboard showed the same top-line numbers every month without telling anyone what to do about them. A quarterly clean-up recovered some spend, then usage grew back over it. What was missing was not visibility but hours: someone whose job it was to keep making the changes, with enough context to know which ones were safe.
What the audit found
5 things that were costing money or time.
Custom metrics tagged by wallet and transaction
High-cardinality tags turned a handful of metrics into millions of billable series. Custom metrics were the largest Datadog line, and most series were never queried. The wallet and transaction-hash tags had been added for one investigation and never removed.
DatadogIndexer and RPC logs indexed in full
Debug-level node logs flowed into production indexes at full retention. The searched fraction was small; the indexed fraction was everything. Indexer restarts alone produced bursts that pushed the account over its committed volume.
DatadogEKS node groups sized for peak chain events
Node groups were provisioned for launch-day and airdrop peaks. Utilization sat far below that for most of the month, staging clusters ran through every weekend, and a few large instance types carried workloads that fit on half the machine.
AWSDeployments gated by manual security review
Every release waited on a person to check Terraform plans and images. Under pressure the check became the bottleneck, and under more pressure it became optional. Nobody could say with confidence which controls had been applied to which release.
DeliveryCVE tracking across dozens of container images
Base images and dependencies changed weekly across many services. Knowing which vulnerability actually reached production was a manual, best-effort exercise, so critical CVEs and irrelevant ones arrived with the same urgency.
SecurityWhat changed
Agents did the work. Engineers approved it.
Metric and log rationalisation
Tag allow-lists on the highest-cardinality metrics, unqueried metrics dropped, exclusion filters on debug logs, and archive routing to S3 with rehydration on demand. Monitors consolidated so a page means something. Every removal was checked against 90 days of dashboard and monitor queries first, so nothing anyone used went away.
Rightsizing and schedules
Node groups resized on 30 days of real utilization with autoscaling bounds set to match, non-production clusters on stop and start schedules, and commitments matched to the steady-state floor. Production changes went out one node group at a time, each with a rollback and an engineer watching latency.
Policy-as-code in the pipeline
Terraform plans checked against policy on every pull request, images signed and verified before deploy, and drift between the console and code detected and reverted. Review became automatic instead of a person, and the record of what was checked ships with each release.
Vulnerability triage that reaches production
An SBOM per image, CVEs correlated with what is actually deployed, and patch pull requests opened for the ones that matter, with the rest filed rather than paged. The team stopped reading vulnerability feeds and started reviewing pull requests.
Results
What the next invoices showed.
The Datadog changes landed first because they carry no availability risk. Custom metric series fell to a fraction of their peak once the wallet and transaction tags were gone, and log indexing dropped to what the team actually searched, with the rest sitting in archive at a fraction of the price. The next Datadog renewal was negotiated from usage that reflected the product rather than its history.
On AWS, the node group resizing and non-production schedules took the bill down without a single incident attributed to the changes, and commitments then locked in the new floor. Finly keeps watching: when a new chain integration lands and utilization shifts, the next rightsizing proposal arrives as a pull request rather than as a surprise on the invoice.
The part the team talks about most is not cost. Deployments kept their cadence with security review built into the pipeline, so releases that used to wait on a person now wait on a check that takes seconds. Vulnerabilities reach an engineer as a patch pull request, ranked by whether they can actually be exploited in production.
“Since bringing DevLift's AI agents into our production environments, our infrastructure operates seamlessly. We established strict, automated security guardrails without slowing down our deployments, and Finly optimized our cloud waste by thousands of dollars automatically.”
What we learned
Three things we'd tell a peer.
- Take the observability savings first. They are large, reversible in minutes, and they buy trust for the compute changes that follow.
- Cardinality is a product decision disguised as a metrics setting. Ask who queries a tag before you keep paying for it.
- Security review that runs on every pull request is the only kind that survives a fast release cadence.
Timeline
How the engagement ran.
- Week 1
Read-only audit
Cross-account role and Datadog read keys. Thirty days of utilization and usage pulled and ranked.
- Weeks 2 to 4
First changes
Log and metric changes first, since they carry no availability risk, then node group resizing behind approvals.
- Month 2 onward
Guardrails and on-call
Policy-as-code in the pipeline, CVE triage, and DevLift engineers on the rotation.
Same pattern in your bill?
Book 30 minutes with an engineer to scope a free, read-only audit.
More case studies: StartGlobal, Inc., Aspora
You'll pick a time on the next page.