contributed toStarknetYellow NetworkAztec
why

The protocol works. What breaks is

shipped

faucet-terminal · Terminal faucet CLI for Starknet and Ethereum Sepolia. 2,800+ npm downloads in a month.

github.com/Giri-Aayush/faucet-terminal →

We believe the developer surface is part of the protocol, not marketing downstream of it. A quickstart that lies costs you the same integration a consensus bug does, and it fails quietly. So the engineers who can read your client source are the ones who write your docs, SDKs, and AI integrations.

/ 01 · Why

A protocol is only as real as the code someone else can build on.

Everything below follows from that sentence. Three things we think are true about how protocol teams ship, and what each one changes about the way we work.

01 · How it goes

Docs go to whoever has capacity, or to an agency that has never opened the client. They are correct the day they ship and drift every release after.

What we believe

The surface is written by the engineer who reads the source, in the same repo, against a running client. Examples are tested in CI so they break loudly instead of silently.

02 · How it goes

The whole surface is planned for a human reading a page, while a growing share of integration questions get answered by Claude and Cursor first.

What we believe

If a model answers wrong about your API, that is your surface failing, not the model. So we ship AI integrations and typed schemas, measured against a question set we write with your team.

03 · How it goes

Work ships under an agency name, in a private repo, with a case study written about it six months later.

What we believe

Public repo, your org, your licence, and the engineer who wrote it named on the commit. A result nobody can check is a claim.

/ 02 · How

How that belief shows up in a contract.

A belief with nothing at stake is a slogan. These are the terms it produces, including the work it makes us turn down.

We do
Retained engagements, one quarter minimum
Public repos, attributed to the engineer who wrote them
A written spec before any code
Examples tested in CI, so they break loudly instead of silently
Direct access to the engineer doing the work, not an account manager
Handover docs, so you can end the contract cleanly
We don't
Smart contract audits, we write the spec, we do not sign off
Token launches, growth campaigns, or marketing
Ongoing content or SEO retainers
Anonymous or unattributed work
Hourly billing, or one deliverable priced on its own

If the work you need is in the right-hand column, we will name someone who does it well rather than take the contract.

/ 03 · What

What that belief builds.

Eight things. Each one ships a repo, not a document about a repo.

01

Execution clients and nodes

High-performance full nodes and client internals in Rust and Go. P2P layers, sync, and the parts of the stack that have to stay up when real value is on the line.

02

Agent-readable developer surfaces

AI integrations, typed tool schemas, and docs restructured so Claude and Cursor answer correctly about your protocol instead of inventing an API. Measured against a question set we write with your team.

03

MEV and searcher infrastructure

Bundle pipelines, protection, and profit systems on the edge of the mempool. Sandwich-attack simulation and Flashbots integration.

04

Protocol documentation and reference

RPC reference, spec pages, and guides maintained in-repo against a running client, versioned with the protocol and tested in CI so examples break loudly instead of silently.

05

Smart contracts, Solidity and Cairo

Audited-grade contracts for protocols that hold real value. AMMs, order books, and the mechanism design underneath them.

06

SDKs and developer tooling

TypeScript and Python clients, CLIs, and test fixtures. Published to npm and PyPI, semver'd, with a maintenance window and a handover doc.

07

Onchain data, indexing, and backends

Subgraphs and custom indexers that make chain state queryable and fast, and the high-throughput, real-time backends that serve it.

08

Integration and migration engineering

Getting a team from testnet to mainnet, or off a deprecated interface, with the pull requests written and reviewed rather than a slide about the plan.

/ 04 · Work

Three engagements, each carrying a number.

Each links to the repo. If a client cannot be named, the repo still can be.

Placeholder · case study 01
00
Client · protocol · date

What shipped, in one sentence with the technology named.

Two lines on the before state, the constraint, and what changed. The number is the claim. This is the evidence for it. Ends in a repo link.

github.com/org/repo
Placeholder · case study 02
00
Client · protocol · date

What shipped, in one sentence with the technology named.

Prefer a number with a unit a foundation recognises: pages, tools, weeks, open issues closed, support questions removed.

github.com/org/repo
Placeholder · case study 03. Cut this if it is weaker than the first two
00
Client · protocol · date

What shipped, in one sentence with the technology named.

Two strong entries beat three where the third is padding. This slot is optional.

github.com/org/repo
/ 05 · Who

A team of engineers.

For now, Jino Labs is a team of engineers with several years of experience across developer relations, developer tooling, and infrastructure development. The work is public and attributed. Judge it from the repos.

01

Developer relations

Docs, guides, and integration support that answer the questions developers actually hit.

02

Developer tooling

SDKs, CLIs, and test fixtures, published to npm and PyPI and kept semver'd.

03

Infrastructure development

Clients, indexers, and the backends that stay up when real value moves.

github.com/jinolabs-xyz →
contact

Send the repo you want fixed.

Thirty minutes, no deck. You get a written scope and a number within two working days, or a referral if it is not our work.

Placeholder · real booking URL and address