Infrared Finance
Proof of Liquidity and liquid staking on Berachain: the app on Next.js with wallet auth and transaction flows, the protocol backend behind it - a Go monorepo of four services where an indexer turns chain events into a store the app can actually query, a GraphQL and REST API, a batcher on the chain oracle and a keeper harvesting vault rewards - and the validator infrastructure under both: AWS CDK, consensus and execution nodes, MPC-signed validator keys, and end-to-end tests that boot a real Berachain devnet.
Overview
Infrared Finance is a DeFi protocol built on Berachain that simplifies interacting with the chain's Proof of Liquidity system through liquid products, summed up in its tagline: Proof of Liquidity in one click. The lineup includes PoL vaults that make participation simpler and help users maximize rewards, iBERA liquid staking that opens BERA staking to everyone, iBGT, IR and a swap, alongside node infrastructure.
The public app is the visible part: Next.js with the App Router on Vercel, wallet authentication through MetaMask and other wallets, transaction flows and direct contract interaction. Behind it sits the part nobody sees - the protocol's own backend and the validator infrastructure it runs on, both delivered by the same team.
The backend is a Go workspace monorepo of four services over a set of shared packages. The indexer follows the chain and writes what it sees into its own store, because the queries a portfolio screen needs - a user's positions, a vault's history, rewards over time - cannot be asked of a blockchain directly; it runs write jobs, caching and metrics. The API serves GraphQL and REST over that index, with Redis and middleware in front. The batcher works with Berachain's oracle, and the keeper runs background jobs including the vault reward harvester. Shared packages carry the cache, database, HTTP, Redis, contract bindings and protobuf types that the four services have in common.
The validator side is infrastructure as code rather than console clicks: AWS CDK in TypeScript describes the stack, consensus and execution clients run on EC2 from forks of Berachain's beacon-kit and eth-docker, validator keys are signed through Cubist CubeSigner MPC rather than kept as files, secrets live in AWS Secrets Manager, and a Prometheus and AWS Distro for OpenTelemetry sidecar carries the metrics out.
Delivery is eight GitHub Actions pipelines - build, lint, end-to-end, release and separate deploys for dev, staging and production - where an image goes to ECR, is substituted into an ECS task definition and rolls out on ECS. CI reaches AWS through an OIDC role, so no cloud keys sit in repository secrets.
What was built
- A Web3 front end with wallet authentication (MetaMask and others), transaction flows and smart-contract interaction, on Next.js with the App Router.
- A Go monorepo of four services on a go.work workspace: indexer, API, batcher and keeper, over shared packages for cache, database, HTTP, Redis, contract bindings and protobuf types.
- An on-chain indexer that turns chain events into a queryable store, with write jobs, caching and metrics, so the app can ask questions a node cannot answer.
- A GraphQL and REST API over the index, with Redis and request middleware.
- A batcher working with Berachain's oracle and a keeper running background jobs, including the vault reward harvester.
- Validator infrastructure as code in AWS CDK and TypeScript, with consensus and execution nodes on EC2 built from forks of beacon-kit and eth-docker.
- MPC signing of validator keys through Cubist CubeSigner, with configuration and secrets in AWS Secrets Manager instead of key files on a host.
- Observability through a Prometheus and AWS Distro for OpenTelemetry sidecar, deployed to Fargate by CloudFormation.
- Eight GitHub Actions pipelines covering build, lint, end-to-end tests, release and per-environment deploys, with image to ECR, substitution into an ECS task definition and rollout on ECS, and OIDC-based AWS access.
- An end-to-end suite that boots a real local Berachain devnet: Kurtosis starts the network with the beacon-kit consensus client, Foundry scripts deploy contracts and build state - a vault, a token, a validator, accrued rewards - the service containers are built alongside it, and Go tests run against the whole thing on a self-hosted runner.
- Integration suites for vaults, users, rewards and withdrawals, load tests with vegeta, and unit tests for the contracts and chain-facing code.
- Code-quality gates in CI: golangci-lint, plus husky, commitlint and commitizen so conventional commits are enforced automatically.
Stack
Frontend
- Next.js (App Router)
- The live site and app, served from Vercel
- Wallet authentication
- MetaMask and other wallets, transaction flows and contract interaction
Backend
- Go 1.22 (go.work monorepo)
- Four services - indexer, API, batcher, keeper - over shared packages
- GraphQL + REST
- Public API over the index, with request middleware
- Contract bindings
- Generated Go bindings for the protocol's smart contracts
Data
- Indexed chain store
- What the indexer writes so positions, vaults and rewards can be queried fast
- Redis
- Caching in front of the API and the indexer
- protobuf
- Shared types across the services
Infrastructure & DevOps
- AWS CDK (TypeScript)
- The whole stack described in code, with Jest tests over the constructs
- AWS ECS, ECR, EC2
- Services on ECS from images in ECR; consensus and execution nodes on EC2
- GitHub Actions
- Eight pipelines: build, lint, e2e, release and deploys for dev, staging and production
- OIDC to AWS
- CI assumes a role instead of storing cloud keys in repository secrets
- Docker
- Service images, plus compose for local work
- Prometheus + AWS Distro for OpenTelemetry
- Metrics sidecar deployed to Fargate through CloudFormation
- Vercel
- Hosting for the public app
Web3
- Berachain
- The chain whose Proof of Liquidity system the vaults and liquid staking build on
- beacon-kit and eth-docker
- Forks of Berachain's consensus client and the execution-node tooling, run as the validator stack
- Cubist CubeSigner
- MPC signing for validator keys, with AWS Secrets Manager behind it
- Berachain oracle
- What the batcher service talks to
Tooling & QA
- Kurtosis
- Boots a full local Berachain devnet for end-to-end runs
- Foundry
- Scripts that deploy contracts and build test state: vault, token, validator, rewards
- Go test suites
- End-to-end across API, batcher, Redis, staking and vaults, plus integration suites
- vegeta
- Load testing against the API
- golangci-lint
- Linting enforced in CI
- husky, commitlint, commitizen
- Conventional commits checked automatically
Engineering highlights
The indexer exists because of a hard limit: a chain cannot answer the questions a portfolio screen asks. Reading events once and writing them into a queryable store is what makes positions, vault history and reward curves load in milliseconds.
End-to-end tests run against a real network, not mocks: Kurtosis boots a Berachain devnet with the beacon-kit consensus client, Foundry scripts create the vault, token, validator and rewards, service containers are built alongside, and the Go suites run over the lot - on a self-hosted runner, because a standard one does not have the resources.
Validator keys are never a file on a box: signing goes through Cubist CubeSigner MPC with secrets in AWS Secrets Manager, and CI reaches AWS through an OIDC role rather than stored credentials.
Infrastructure is code end to end - AWS CDK in TypeScript with its own Jest tests - so dev, staging and production are the same stack with different parameters rather than three hand-tended environments.