Tokenized Index Development: Contracts, Rebalancing, Oracles

We create tokenized indices — ERC-20 tokens representing a basket of on-chain assets. Users mint index tokens by depositing base assets and gain diversified exposure without holding each token individually. Our solutions use proven mechanics from Index Coop's DPI and Bankless BED Index, but with add

Blockchain Development Services

Frequently Asked Questions

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1450
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1308
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    1003
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1269
  • image_logo-advance_0.webp
    B2B Advance company logo design
    717
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    1008

We create tokenized indices — ERC-20 tokens representing a basket of on-chain assets. Users mint index tokens by depositing base assets and gain diversified exposure without holding each token individually. Our solutions use proven mechanics from Index Coop's DPI and Bankless BED Index, but with additional manipulation protection and gas optimization. Implementing such a system with correct rebalancing math and security is a turnkey task we handle.

How a Tokenized Index Works

A tokenized index is a smart contract that issues shares in exchange for a basket of underlying assets. Each share represents a proportional slice of the pool. The architecture includes four modules: the token itself (ERC-20), a component registry with target weights, an oracle for NAV calculation, and a rebalancing module. Our smart contract index follows this modular design.

Preventing NAV Manipulation

The Net Asset Value of the index is the sum of price_i * quantity_i for each component. In practice, this is non-trivial: prices can be distorted via low-liquidity attacks. We use a hybrid approach: Chainlink for top tokens (ETH, BTC, LINK, UNI), Uniswap V3 TWAP with period ≥30 minutes for others, with a sanity check on deviation. If TWAP deviates from Chainlink by more than 5%, the transaction reverts until stabilization. This eliminates flash loan manipulation through low-liquidity pools. The recommended TWAP period is 30 minutes. The NAV oracle is key for accurate pricing.

Why Arbitrageur-Driven Rebalancing Is More Efficient

During rebalancing (once a month or triggered by a component deviating beyond ±5% of its target weight), over-allocated tokens must be sold and under-allocated ones bought. Two options:

  • Push rebalancing — the contract itself initiates swaps via Uniswap/1inch when rebalance() is called. Problem: MEV. Everyone sees a large rebalance in the mempool, bots frontrun each swap. For an index with $10M TVL, push rebalancing could cost over $1,000 in gas, while pull rebalancing costs only $200.
  • Pull rebalancing (via arbitrage incentive) — the contract sets target weights and offers arbitrageurs mint/redeem at NAV ± a small premium. Arbitrageurs rebalance the portfolio through external DEXs, earning on the spread. The mechanics are similar to ETF creation/redemption. Pull rebalancing saves up to 80% gas compared to push.

Pull rebalancing is up to 5x more gas-efficient than push rebalancing.

Comparison Table
Parameter Push Rebalancing Pull Rebalancing
Initiator Contract Arbitrageurs
Gas High (~500k gas) Low (~100k gas)
MEV vulnerability High Low
Flexibility Fixed schedule Market-driven

Dilution During Minting

If mint() accepts only one token (e.g., USDC) and converts it to components internally, this creates risk: while the transaction is in the mempool, component prices change. The user receives fewer index tokens than expected.

Solution: proportional minting — the user deposits all components in correct proportions. No internal swaps, no slippage risk. Over 95% of DeFi indices use proportional minting to avoid slippage. Downside: UX is more complex. Compromise: accept single-token deposit via Uniswap router as an optional path with explicit slippage warning.

Also important is gas optimization in mint/redeem: processing each component individually is expensive for a basket of 10–20 tokens. We use batch transfers and accumulate data via storage arrays.

Tokenized Index Architecture

Contracts

  • IndexToken (ERC-20) — the index token itself. Implements mint(uint256[] amounts) and redeem(uint256 shares). On mint, checks input proportions, mints shares proportional to NAV. On redeem, burns shares, sends proportional share of each component.
  • ComponentRegistry — list of components with target weights. Owner (Gnosis Safe + timelock) can add/remove components via governance proposal. When a component is removed, the contract enters redeem-only mode for that asset.
  • NAVOracle — aggregates prices via Chainlink + Uniswap TWAP, returns current NAV. Critical dependency: we monitor staleness of each feed (Chainlink heartbeat 1-24 hours depending on token).
  • RebalancingModule — rebalancing mechanism logic. Calculates deviation from target weights, emits RebalancingOpportunity event for arbitrageurs, accepts rebalanceTrade(address[] sellTokens, address[] buyTokens, uint256[] amounts) from authorized rebalancers.
Parameter Typical Value Why Important
Rebalancing threshold ±5% of target weight Too frequent = gas, too rare = drift
TWAP period 30-60 minutes Balance between freshness and manipulation resistance
Max component count 10-20 tokens Gas on redeem O(n), mint O(n)
Mint/redeem fee 0.15% Covers operational costs

Staking: Protocol Integration

Index components can be not just ERC-20, but yield-bearing tokens: aWETH (Aave), stETH (Lido), cUSDC (Compound). Then the index automatically accumulates yield without additional logic — NAV grows via accrual. This portfolio tokenization via indices offers diversified exposure.

But: during liquidation in Aave, balanceOf aWETH changes instantly. NAV recalculates on next request. If someone mints at a moment of inconsistent state, dilution may occur. We listen to ReserveDataUpdated from Aave and block mint/redeem during sharp changes in reserve index.

Work Process

  1. Analysis (2-3 days): Define basket composition, rebalancing strategy, oracle infrastructure. Analyze liquidity of each component — if a token trades only on one DEX with $500k liquidity, it's not suitable for an on-chain index.
  2. Design (3-5 days): Storage layout, module interfaces, governance scheme for changing composition.
  3. Development (1-2 weeks): Contracts + fork tests with real oracle data. Simulate rebalancing on historical data.
  4. Audit and deployment: Focus on NAV manipulation vectors and reentrancy in mint/redeem. Deploy with a TVL cap for the first 30 days. We guarantee that all contracts undergo a rigorous security audit before deployment. Our team has over 5 years of certified DeFi experience.

Get a consultation on your index architecture.

What's Included

  • Architecture and contract design
  • Smart contract development in Solidity
  • Oracle configuration (Chainlink, Uniswap TWAP)
  • Mint/redeem and rebalancing implementation
  • Security audit of contracts (including contract audit report)
  • Frontend integration (wagmi, RainbowKit)
  • Documentation and deployment support

Timeline Estimates

Basic index with proportional mint/redeem and Chainlink oracle — 1-2 weeks. Full system with yield-bearing components, arbitrage rebalancing, and governance — 4-6 weeks.

Development costs typically range from $20k for a basic index to $70k for a full system. Cost is determined after analyzing the basket composition and oracle infrastructure requirements. Our experience: 5+ years in DeFi, 20+ projects implemented, 10+ audited contracts. Contact us to evaluate your project — we'll find the right architecture for your needs.