Sample Project
Web3
Escrow dApp Frontend
Wallet connect and signing flows, contract lifecycle states, dispute UI and a backend-for-frontend layer reading escrow state.
SolidityviemTypeScriptPostgreSQL
➤ ./webnuvexa --web3
Resolving chain clients...
Indexing contract events...
✓ Wallet connection flows wired
✓ Contract test suite green
✓ Indexer caught up to head
! Audit report NOT issued by us
Awaiting qualified auditor▒
// Web3 & Blockchain Engineering
Integration work against chains that already exist.
We build the parts around your contracts: dApp frontends, off-chain services, event indexers, wallet and signing flows, contract test suites, and the documentation a qualified auditor needs. Not token design, not audits, not trading infrastructure.
Vertical Loaded
v2.4.0
No audit reports issued
// 01_problems
The Problems We Actually Get Called About
Web3 engineering problems are rarely about writing a contract. They are about everything that has to agree with one.
[01]
problem
The Frontend Is The Product
Users never touch your contract. They touch a wallet prompt, a signature request, a network switch and a pending state. That surface has more failure modes than the contract does, and it is the part nobody budgets for.
[02]
problem
One Backend, Several Chains
A product that reads from Ethereum, an L2 and Solana has three clients, three confirmation models, three explorer conventions and three sets of gas semantics. Untreated, this becomes three subtly different code paths that disagree with each other.
[03]
problem
Events Nobody Can Query
Reading contract state directly does not scale and gives you no history. Teams need an indexer that turns emitted events into queryable rows, backfills safely, and survives a reorg without double-counting.
[04]
problem
Reorgs And Finality
On chains where finality is probabilistic, a transaction that succeeded can be un-succeeded. Balance displays, rewards and accounting logic all have to be written against that reality rather than assuming a confirmed transaction is permanent.
[05]
problem
Nothing To Give An Auditor
Audit firms need a documented system: the contract source with build instructions, the deployment addresses, the test suite and its coverage, the known-intended-calls list, and a written threat model. Teams routinely pay for a second round of an audit because this was missing.
[06]
problem
Unsigned Or Mis-Signed Requests
A dApp that sends a legitimate signature request to the wrong prompt, or that asks a user to sign an unbounded approval, has handed the user an avoidable loss. Signature payloads need the same rigour as any other security boundary.
// 02_web3_modules
What We Build Here
The contract itself is usually written by you or by your protocol team. This is the engineering around it.
build
active
BUILD: Chain Integration
Off-chain services, event indexers, backend-for-frontend layers, subgraph-style query models, and multi-chain clients behind one contract so callers never branch on chain.
SolidityRustTypeScriptGo
design
active
DESIGN: Wallet And Signing UX
Connect flows, network switching, transaction lifecycle states, signature and approval screens that state what is being signed, and failure states a non-technical user can act on.
WalletConnectEIP-4361Safe
grow
active
GROW: Developer Surfaces
Documentation, integration guides, example repositories and search visibility for the protocol questions developers ask before they integrate.
DevRelDocsSEO
// 03_web3_capabilities
Engineering Capabilities
Each line below is work we can scope and price as a fixed-fee phase.
[01]
technical
dApp Frontends
Typed contract clients, wallet connection, transaction lifecycle handling, and a UI that never leaves the user guessing whether an action succeeded.
[02]
technical
Off-Chain Services
APIs that read contract state, trigger transactions through a relayer or bundler, and hold no long-lived signing keys of their own.
[03]
technical
Event Indexing
Continuous indexing from a safe start block, backfill, reorg-aware confirmation handling, and a queryable model with deduplication that survives a chain reorganisation.
[04]
technical
Contract Test Suites
Foundry or Hardhat suites covering the intended calls and, more usefully, the calls that must revert. Coverage reported per contract, not as a headline number.
[05]
technical
Audit-Ready Documentation
Build instructions, deployment address registry, known intended-calls list, threat model and running test suite, packaged so a qualified auditor can start on day one.
[06]
technical
Gas And State Modelling
Reading the contract to find the batchable path, then measuring it rather than guessing. Optimisation is scoped as its own phase with a stated method.
[07]
technical
Bridge And L2 Considerations
Assumption differences between an L1 and an L2 treated explicitly: finality, sequencer dependency, reorg semantics and message passing.
[08]
technical
Key Handling Integration
We integrate with the signer, KMS or HSM you operate. We do not hold production private keys, and no developer or contractor ever does.
// 04_chain_support
Chains And Tooling We Work In
What we build against, and the honest reason each one appears here.
chain_support
| Layer | We work in | Why it earns its place |
|---|---|---|
| Smart contract | Solidity, Vyper, Rust (CosmWasm / Move where the chain requires it) | Contract language is dictated by the chain. We write to the language the ecosystem already runs, not to a preference. |
| Chain clients | viem, ethers.js, Web3.js, Solana web3.js | The client library is the only part of the stack that speaks the chain directly. Keeping it behind one adapter keeps the rest of the code chain-agnostic. |
| Contract tooling | Foundry, Hardhat | Both are needed: Foundry for fast property and fuzz tests, Hardhat where existing deployment scripts and team tooling depend on it. |
| Other chain runtimes | CosmWasm / Substrate (Rust to WebAssembly), Cairo for Starknet, Move for Aptos and Sui | Wasm, ZK-prover and object-model chains are separate codebases with separate verification models. The language follows the chain; it is never a configuration flag. |
| Off-chain services | TypeScript / Node, Go, Rust | Chosen for the job. Go where throughput and predictable resource use matter, Rust where a signing or encoding path has to be exactly right, TypeScript where the team will maintain it. |
| Data and indexing | PostgreSQL, Redis, The Graph, custom indexers | Contract events become rows. How they are stored depends entirely on the query patterns the product actually has. |
| Test and audit prep | Foundry fuzzing, Slither, Echidna, coverage reports, NatSpec | Static analysis and property tests are our preparation for an external auditor. They are not an audit and we do not present them as one. |
| Wallet standards | EIP-1193, EIP-4361 (SIWE), WalletConnect, Safe | These are the interfaces users already have. Integrating them properly is cheaper than asking users to install something new. |
Chain support here means we can build against it competently. It is not a claim that we have shipped every row above, and we will tell you which of these we have real experience with on your chain when we talk.
// 05_web3_pipeline
How A Web3 Engagement Runs
Fixed-fee phases. The audit is a separate fixed-fee engagement with a named third party, never a line item we deliver ourselves.
phase_01
Scope And Threat Model
Which chains, which contracts, who holds which keys, what the user can sign, and what an attacker would want. The output is a written scope boundary and a threat model you can hand to an auditor unchanged.
phase_02
Integration Layer
Typed clients behind a single adapter, wallet and signing flows, off-chain services and the indexer. Built against a local chain first so the loop is fast and testable.
phase_03
Test And Hardening
Contract and integration test suites, fuzzing and static analysis on our side, reorg and failure-path testing, and remediation of what those surfaces. Priced as a separate phase because the findings determine the effort.
phase_04
Audit Readiness And Handover
Documentation package, deployment registry, running test suite, known intended-calls list and handover. Your chosen audit firm receives a package that lets them bill for analysis rather than for getting up to speed.
// 06_constraints
What We Will Not Do
This is the Web3 version of an honest no, and it is long because the mismatches here are expensive for both sides.
We Do Not Audit Smart Contracts
WebNuvexa performs no smart contract security audit, publishes no audit report, and issues no security attestation or certification of any kind. Contract auditing is a regulated professional service performed by qualified firms with their own liability structure. We run tests, fuzzing and static analysis on our own code and package the evidence; a qualified third party issues any audit finding you rely on.
No Token Or Tokenomics Design
We do not design tokenomics, write whitepapers, structure token launches, or advise on emission schedules and economic design. That is work for a protocol economist and a technical writer, not a development studio.
No Trading Or MEV Infrastructure
We do not build trading bots, arbitrage systems, market-making logic, MEV searchers or strategies that depend on execution research we have not done.
No Custody Of Keys Or Funds
We do not hold, escrow or manage private keys, seed phrases or treasury wallets. We integrate with the signer, KMS or HSM you operate, and no WebNuvexa employee or contractor ever holds a production key.
No Regulatory Or Licensing Advice
Whether your token, protocol or product is a security, a commodity, a collective investment scheme or something else entirely is a legal determination made with qualified counsel and, where relevant, a regulator. We do not provide legal or regulatory advice.
No Guaranteed Audit Outcome
No engineering process can promise that an audit will return no findings. Anyone who offers that is selling a report, not a review. We scope our work so an audit has the best possible chance of being a single round, and we say so plainly.
// 07_web3_output
Sample Work
Illustrative sample projects showing the scope of work involved. These are not client engagements and the card descriptions describe scope, not outcomes.
Sample Project
Web3
Multi-Network Event Indexer
Continuous indexing from a safe start block with backfill, reorg-aware confirmation handling and a deduplicated query model.
GoPostgreSQLRedis
Sample Project
Web3
Audit Preparation Package
Foundry suite with fuzz and invariant tests, static analysis output, deployment address registry, NatSpec comments and a written threat model.
FoundrySlitherEchidnaNatSpec
Sample Project
Web3
Solana Program Client Layer
Typed instruction builders, account resolution and transaction submission behind a chain-agnostic adapter interface.
RustAnchorTypeScript
Shipping on a chain?
Tell us which chain, what the contract does, and where your auditor sits in the plan. We will tell you honestly whether we are useful here before you spend anything.