Code that holds money has to be right the first time.

Often, no — and we would rather say so before you spend the budget than after. A blockchain earns its place when several parties who do not trust each other need to write to the same record, when assets must be transferable without your permission, or when the guarantee has to survive your company shutting down. If none of those apply, a normal database is faster, cheaper and easier to change, and we will build you that instead.

No, and you should be suspicious of anyone who says they do. An audit performed by the team that wrote the code is a code review with a nicer name. We test to exhaustion, run static analysis, and review internally with a second pair of eyes — then we prepare the documentation and invariant specs so an independent firm can audit efficiently, coordinate with whoever you pick, and fix what they find.

Budget $15,000 to $60,000 and above, depending on how much code and how novel it is. Whether you need one is a function of what is at risk: a small NFT collection using a standard implementation is a different proposition from a lending protocol holding deposits. If real money will sit in the contract, the honest answer is yes, and we will scope the build so the audit is as cheap as it can be.

EVM chains primarily: Ethereum mainnet, and the L2s where most activity now happens — Base, Arbitrum, Optimism, Polygon, zkSync — plus BNB Chain and Avalanche. We also build custom EVM chains and rollups where a shared L2 genuinely does not fit. Chain choice is a scoping conversation, not a preference: it follows your users, your gas budget and where your liquidity already is.

It is a trade-off, and the answer depends on what you are building. Upgradeability lets you fix a bug, but it also means someone holds a key that can change the rules — which sophisticated users will notice and hold against you. We decide before deployment, not after an incident. Where we do make contracts upgradeable, the admin is a multisig behind a timelock so that any change is visible before it takes effect.

You do, from the first deployment. Ownership goes to a multisig you control — usually Safe — and we work through it rather than holding custody ourselves. We do not want to be a single point of failure for your treasury, and you should not accept a studio that does.

We can build and deploy the contract, set up vesting and distribution, and get it verified and multisig-owned. What we are not is your lawyers: whether your token is a security in a given jurisdiction, what you can say about it, and who you can sell it to are legal questions with real consequences. Get that advice before you write the code, not after — it frequently changes the design.

Yes, and it is usually where the difference between a usable product and a demo shows up. Wallet connection, transaction states that explain what is happening, gas estimates before someone signs, handling for pending and failed and dropped transactions, and a sensible fallback when the user's RPC provider is having a bad day.

Depends on how permanent it needs to be. Fully on-chain, usually as SVG, when the asset must outlive every service involved. IPFS with pinning for most collections, and Arweave when you want to pay once for storage that persists. What we avoid is a single centralised URL, which quietly turns your permanent asset into a broken image the day the bill goes unpaid.

Yes, with account abstraction. ERC-4337 smart accounts allow gas sponsorship — you pay, and the user does not need to hold ETH at all — plus session keys and social recovery. For consumer products aimed at people who have never used a wallet, this is usually the difference between working and not.

That is what the incident runbook is for, and it is written before deployment rather than during the emergency. Depending on the design it means pausing, upgrading through the timelock, or migrating to a new contract — plus monitoring that alerts on the anomaly rather than waiting for someone to notice on social media. We build for that scenario because the alternative is improvising while funds move.

Usually yes, starting with a paid review to establish what is actually deployed, whether the verified source matches, who holds the keys and what the upgrade situation is. Sometimes the finding is that the safest route is a fresh deployment and a migration. We will tell you that even though it is the more expensive answer, because the alternative is building on top of something nobody understands.