Smart contracts · Wallets · dApps

Web3 & DeFi development
scoped around what can go wrong.

Bring blockchain functionality into a usable product. We develop decentralized application interfaces, wallet integrations and smart-contract systems, connecting on-chain logic with the off-chain services your product needs.

Discuss your Web3 project ↗

From scope to delivery

What we can build
together.

We clarify chain selection, custody boundaries, administrative privileges and failure scenarios before implementation. Testnet validation comes before mainnet deployment. Independent security review and any applicable legal review must be scoped separately; software delivery is not a guarantee of protocol safety or regulatory approval.

Smart-contract development

Token logic, staking mechanisms and protocol integrations with documented permissions, tests and deployment procedures.

Wallets & dApp interfaces

Wallet connection, transaction states, network selection and clear signing experiences for web and mobile users.

DeFi & on-chain data

Swap and liquidity interfaces, protocol integrations, indexing and dashboards built around the selected blockchain ecosystem.

Who this is for

Teams with a reason to be on-chain.

The projects that go well are those where a blockchain solves a specific problem: shared state between parties who do not trust each other, settlement that can be verified, or composability with existing protocols. Typical clients:

Founders building a dApp who need the contracts and the interface from one team, so that transaction states in the UI match what the contracts actually do.
Existing products adding wallet features such as sign-in with a wallet, token-gated access, on-chain payments or displaying a user’s assets.
Protocol teams that have audited contracts and need a front end, a dashboard or an indexing service built around them.
Businesses testing an idea that want a testnet proof of concept before committing to a mainnet launch and an audit budget. Our guide to prototypes, proofs of concept and MVPs explains which of these you are actually asking for.

If a conventional database would do the job, we will say so. A normal web application is cheaper to build, cheaper to run and can be fixed after launch.

The process

Specify, test, review.
Then deploy.

Deployed contracts cannot be patched quietly the way a web server can. The process puts the effort before mainnet for that reason.

How we work in detail ↗

Specification and threat model

A written description of each contract’s roles, functions, invariants and admin powers, plus a list of ways it could be attacked or misused. This document is also what an auditor will ask for first.

Contracts and tests

Solidity implementation built on established open-source libraries where they exist, with unit tests, scenario tests for the economic flows and tests for the failure paths. Static analysis tools are run as part of the build.

Testnet and interface

Deployment to a public testnet with the front end connected, so you and early users can exercise real wallet flows: connecting, switching networks, approving, signing, waiting and failing.

Independent audit

You engage an external auditor. We supply the code, tests, specification and deployment scripts, answer their questions and fix the findings. Re-review of the fixes is between you and the auditor.

Mainnet deployment and handover

Scripted, repeatable deployment, contract verification on the block explorer, transfer of admin roles to wallets you control, and documentation of every privileged function.

Security

What we do, and what we cannot promise.

Plainly stated. BBR writes and tests smart contracts. BBR is not a security audit firm, and our own testing does not replace an independent audit. No developer or auditor can guarantee that a contract is free of vulnerabilities. If your contracts will hold meaningful value, include an external audit in the budget and timeline from the start.

Within that limit, these are the practices we follow to reduce risk:

Prefer widely used, already audited library implementations of token standards and access control over custom code
Keep contracts small and the on-chain surface minimal
Write down every privileged role and what it can do, and recommend multisig control and timelocks for admin actions
Test the unhappy paths: reentrancy, rounding, unexpected token behaviour, oracle failure and paused states
Use pause or withdrawal-limit mechanisms where they fit the design, and document who can trigger them
Never handle client private keys. Deployment and admin keys are generated and held by you
Plan for incidents: who is monitoring, who can pause, and how users are informed

Technology

Contracts are written in Solidity for EVM networks using standard development and testing frameworks. Front ends are built with React and Next.js and established wallet-connection libraries. Off-chain services such as indexing, notifications, user accounts and admin tools run on Node.js and PostgreSQL, connected through the kind of event-driven integration work we do for conventional products.

Pricing factors and common mistakes

Where the budget goes.

We quote against a written specification. The factors that move the number:

Novelty of the contract logic. A standard token or a simple staking contract assembled from known components is a small job. A new financial mechanism is a research project with a testing burden to match.
Number of external protocols. Every integration with another protocol or oracle brings its own assumptions and failure modes.
Upgradeability and governance. Proxies, role systems and timelocks add contracts, tests and documentation.
The interface. A polished dApp with clear transaction states, error recovery and mobile wallet support is often more work than the contracts.
Indexing and data. Dashboards and history views need an indexing layer, because reading everything directly from the chain is slow.
Costs outside our quote. The independent audit, legal advice, deployment gas and any bug bounty are separate line items, and you should budget for them. For contracts that will hold real value, the audit can cost as much as the development itself.

Mistakes that are expensive on-chain

Leaving the audit to the end of the budget. Auditors are booked in advance, and findings take time to fix. Treat the audit as a fixed stage and not a last-week formality.
A single wallet as owner. One compromised laptop can then drain or freeze the protocol.
Putting everything on-chain. This costs users gas and removes your ability to fix mistakes, with no benefit to anyone.
Treating the front end as harmless. A compromised interface can ask users to sign malicious transactions even when the contracts are sound. Dependency hygiene and deployment security matter here as well.
Launching without a legal view on whether the token or product is regulated where you plan to offer it.

Fit

Projects we take on,
and projects we decline.

We are selective about this kind of work, because failure here is public and permanent.

Good fit

We are likely a strong match if

You are building on an EVM-compatible network and can explain why the product needs to be on-chain
You want contracts, interface and off-chain backend delivered by one team
You accept that an independent audit is a separate, budgeted stage
You will hold your own keys and admin roles, ideally through a multisig
You have, or will obtain, legal advice for your target markets

Not a fit

We will decline or point you elsewhere if

You want us to certify contracts as secure or to act as your auditor
The plan is to deploy value-holding contracts to mainnet with no external review
You need contract development for non-EVM chains
The project relies on misleading users, such as hidden mint functions, undisclosed admin powers or guaranteed-return claims
You expect us to provide custody of user funds or to advise on regulatory status

Questions

Frequently asked
questions.

Does development include a smart-contract audit?

An independent audit is a separate engagement. We can prepare code, tests and technical documentation for external reviewers and scope remediation after their findings.

Which blockchains do you work with?

Our smart-contract work is in Solidity for EVM-compatible networks: Ethereum and the layer-2 and sidechain networks that run the same virtual machine. The choice between them comes down to transaction cost, where your users and liquidity already are, and which protocols you need to integrate with. We do not offer contract development for non-EVM chains.

Does the whole product need to be on-chain?

Almost never. On-chain code is expensive to run, public and hard to change, so it should hold only what truly needs shared, verifiable state: balances, ownership and settlement rules. Accounts, content, notifications, search and analytics belong in a conventional backend. Deciding where that line sits is one of the most valuable parts of scoping.

Can contracts be changed after deployment?

Only if they were designed for it. Upgradeable proxy patterns allow logic to be replaced, but they introduce an admin key that users must trust and attackers will target. Immutable contracts avoid that risk but cannot be patched. We set out the trade-off for your case, and if upgradeability is chosen we recommend that a multisig and a timelock control it, not a single wallet.

Do you advise on token regulation or legal structure?

No. Whether a token, staking programme or DeFi product is regulated in your target markets is a legal question, and you need a lawyer who specialises in it. We build to the requirements your counsel sets, such as geographic restrictions or identity checks through a third-party provider.

Your next move

Planning an on-chain product?
Start with the threat model.

Tell us what the contracts need to do, which chain you have in mind and who will hold the admin keys. We reply with questions, risks we can see and a suggested scope.