Blockchain and Crypto Development Services — NOVASOLUTIONS

Blockchain Development Solutions for DeFi, NFT, and Web3

A project arrives with a task: "Build us a DeFi protocol." Behind that lie at least six independent engineering tasks—smart contracts, dApp frontend, oracles, event indexing, node infrastructure, and tokenomics. Each is solved with its own stack and has distinct failure points. Over 7 years we have delivered 50+ blockchain projects—from simple NFT collections to multi-chain DeFi protocols with TVL exceeding $200M. We guarantee code security and compliance with audit standards.

What Does Web3 Development Include?

A blockchain project is not "write Solidity." A typical production stack looks like this:

Each layer can be ordered separately or as a package. Most clients come with either already written contracts that need verification and deployment, or a product idea that needs to become a working protocol from scratch.

Why Smart Contracts Are the Highest Risk Layer?

The bulk of the budget and time in Web3 projects goes into contracts—and for good reason. Smart contract code directly manages real money without an intermediate server that can be patched overnight.

Reentrancy and Cross-Function Attacks

Classic reentrancy became textbook after The DAO, but variants continue to emerge. A more insidious version is cross-function reentrancy, where OpenZeppelin's ReentrancyGuard doesn't help: an attacker enters through one function not protected by the guard and manipulates state read by another.

Example from a recent audit: a lending protocol on Arbitrum used nonReentrant on withdraw() but not on liquidate(). A flash loan allowed the attacker to call liquidate() inside a callback, change the collateral ratio before withdraw() checked it again. Losses totaled $1.4M before the protocol was halted via multisig.

The correct approach is the checks-effects-interactions pattern plus a global mutex at the protocol level, not at the individual function level.

Storage Collision in Proxy Patterns

Upgradeable contracts via UUPS or Transparent Proxy are standard for production protocols. But the storage layout between implementation and proxy must match exactly. One variable added at the beginning of a new implementation shifts all slots and overwrites existing user data.

OpenZeppelin provides @openzeppelin/upgrades-plugins for Hardhat and Foundry, which checks storage layout during upgrades. But the plugin won't help if the developer manually manages slots via assembly—manual layout audit is needed here.

Gas Griefing and Unbounded Loops

Contracts with for (uint i = 0; i < users.length; i++) over a dynamic array are a gas bomb. With a sufficiently large array, the transaction cannot fit into a block at all. We've seen projects where governance voting was blocked because the participant array grew to 50k addresses, and the distribute function iterated over all of them in a single transaction.

The solution is the pull-over-push pattern: users claim rewards themselves instead of receiving them via push. Or pagination with checkpoint storage.

DeFi and Oracles: How to Avoid Losses?

A DeFi protocol is a system of interdependent contracts. Integration points between them are the main attack vector.

Oracle Manipulation

Price oracles based on spot price from Uniswap v2 are a well-known vulnerability. A flash loan allows shifting the spot price in a pool in one transaction, taking a loan against inflated collateral, and returning the flash loan, leaving with profit. This is not theory: Mango Markets lost $114M exactly this way.

The correct approach is Chainlink Price Feeds with TWAP (time-weighted average price) or Uniswap v3 TWAP via observe(). TWAP is harder to manipulate because the price must be sustained for several blocks, which is expensive.

Concentrated Liquidity and Impermanent Loss

AMM on Uniswap v3 with concentrated liquidity requires careful position management. LP tokens are ERC-721 instead of ERC-20, meaning standard vault patterns for compounding don't work directly—adapters like Arrakis or custom range management logic are needed.

NFT, Frontend, and Infrastructure: Key Components

ERC-721 and ERC-1155 are base standards. Complexity starts with dynamic NFTs: metadata stored on-chain via base64-encoded SVG or off-chain via IPFS with update capability. Marketplace royalties via ERC-2981 are standard, but OpenSea implements it their way, Blur ignored it until recently. This must be considered when designing royalty mechanics.

Wagmi v2 + viem is the current standard for TypeScript dApps. RainbowKit or ConnectKit cover UX wallet connection. The main complexity is multi-chain: a user may be on Ethereum Mainnet, while the contract is deployed on Arbitrum. Handling chain switching, pending transactions, and rejected signatures without losing state is a separate engineering task.

Own nodes provide control over RPC and no rate limits, but require DevOps support. For most projects, Alchemy or QuickNode with an archive node is sufficient. The Graph Protocol for event indexing is standard: a subgraph describes mapping handlers in AssemblyScript and indexes events into a PostgreSQL-compatible storage with a GraphQL API.

Tokens: ERC-20, Vesting, Governance

ERC-20 with basic functions can be written in a day. Complexity lies in tokenomics: vesting schedules with cliff, liquidity bootstrapping via Balancer LBP or Fjord Foundry, governance via OpenZeppelin Governor or Compound-style bravo. Each of these components has its own attack vectors—vote delegation manipulation, flash loan governance attacks, frontrunning on vesting claim.

Stack and Tools

Contracts: Solidity 0.8.x, Rust + Anchor (Solana), Move (Aptos/Sui). Testing: Foundry (fuzz, invariant tests)—Foundry performs fuzz tests 10x faster than Hardhat; Hardhat (integration); Slither (static analysis); Echidna (property-based fuzzing). Libraries: OpenZeppelin Contracts 5.x, Solmate, PRBMath. Frontend: React 18 + TypeScript, wagmi v2, viem, RainbowKit, ethers.js. Infrastructure: The Graph, Alchemy, QuickNode, Infura. Deployment: Foundry scripts, Hardhat Ignition, Gnosis Safe for multisig.

Work Process

Requirements analysis → contract architecture and interaction scheme → development with test coverage → internal audit via Slither + Echidna → external audit (if required) → testnet deployment → mainnet with multisig timelock → monitoring support via Tenderly or OpenZeppelin Defender.

Every protocol with TVL over $100k gets a timelock on upgrades—at least 48 hours. This is not overcaution; it's an industry standard after a series of attacks on instant upgrades.

What's Included in Deliverables

• Smart contract source code (Solidity/Rust/Move) with inline documentation
• Full test suite (unit, fuzz, invariant) covering edge cases
• Deployment scripts and migration guides for testnet and mainnet
• Security audit report (internal, optionally external with your chosen firm)
• Monitoring dashboard (Tenderly, Defender) and alert configuration
• Technical documentation: architecture diagram, upgrade procedures, emergency stop
• Team training session on contract interaction and governance

Timelines

• Simple ERC-20 with vesting: 2–3 weeks
• NFT collection with marketplace: 4–6 weeks
• DeFi protocol (lending or DEX): 3–6 months including audit
• Full Web3 product (contracts + frontend + infrastructure): 4–9 months

Cost is calculated individually after a technical briefing. Share your project brief with us—we will help estimate the scope and timelines. Order the development of blockchain solutions protected from the most sophisticated attacks.