Skip to content

Manual Verification Support for 10 DeFi Contracts on opBNB Mainnet (Chain ID: 204) - viaIR Compilation Required #1592

@steadefiquantum

Description

@steadefiquantum

Problem Summary:

I am requesting manual verification assistance for 10 production smart contracts deployed on opBNB Mainnet (Chain ID: 204). These contracts implement complex DeFi logic that requires Solidity 0.8.19 compilation with viaIR: true to avoid "Stack too deep" errors. The current opBNBScan verification interface does not support viaIR compilation, resulting in bytecode mismatches.

Project Details:

Project Name: Steadefi Quantum Nexus
Description: Advanced DeFi protocol with 12-level matrix farming system, deflectionary tokenomics, and multi-tier bonus structure
Website: https://app.steadefinexus.com
Network: opBNB Mainnet (Chain ID: 204)

Technical Specifications

Compiler Configuration:

Solidity Version: 0.8.19
Compiler: v0.8.19+commit.7dd6d404
Optimization: Enabled (200 runs)
viaIR: true (CRITICAL - Required for compilation)
EVM Version: paris
License: MIT

Why viaIR is Required:

Our contracts implement complex DeFi logic including:

Multi-level matrix calculations (12 levels deep)
Recursive sponsor placement algorithms
Complex bonus distribution logic across 10 tiers
Yield calculation with multiple validation steps
Without viaIR compilation, we encounter "Stack too deep" errors that prevent compilation entirely.

Contracts Requiring Verification

Total: 10 Contracts
sUSDT (Stablecoin Token)
Address: 0x063b73035fEb6d63CF6057ad3181dF9b2f319abd
Constructor: None
SLDToken (SOLIDUS - Governance Token)
Address: 0x7E92bC4f35FcE6A0839A9d5810eAa43995C44f4f
Constructor: None
AuxFund (Auxiliary Fund Manager)
Address: 0x9E5Aac1Ba1A2e6AEd6b32689DfCF62A509Ca96f3
Constructor Args: [0x7e92bc4f35fce6a0839a9d5810eaa43995c44f4f, 0x9e5aac1ba1a2e6aed6b32689dfcf62a509ca96f3]
Registration (User Registration System)
Address: 0xb675B051450fEb9E7E196d590238C9E82d416C70
Constructor Args: Multiple token and contract addresses
SlotSystem (Matrix Slot Management)
Address: 0x710cfe47d275784C70E0A59c725a35499E08614E
Constructor: None
MatrixSystem (12-Level Matrix Logic)
Address: 0x15Ce55f4e8F602656458048fE793Ea708C5552eB
Constructor: None
TierBonus (10-Tier Uni-Level Bonus)
Address: 0x8B72a698a0C81AFe92DFe87DD65a35C79CaC9B13
Constructor Args: [0x9e5aac1ba1a2e6aed6b32689dfcf62a509ca96f3]
CatalystPool (Daily Yield Pool)
Address: 0x0EaB074D99829A3F25F7d292882cD4633F7C0AD8
Constructor Args: [0x9e5aac1ba1a2e6aed6b32689dfcf62a509ca96f3]
P2PEscrow (Peer-to-Peer Trading)
Address: 0xae8faF2D18b4f5E2E731020D019c48b9FeD11187

Constructor Args: Multiple token and contract addresses

SteadefiCore (Main Protocol Controller)

Address: 0x8d04d023acec9c9017f9d8dd8ed3bbae5ac98821
Constructor Args: Multiple token and contract addresses

Verification Methods Attempted

opBNBScan Web Interface - Flattened Source
Result: Bytecode mismatch (no viaIR option available)

opBNBScan Web Interface - Standard JSON Input
Result: Bytecode mismatch despite viaIR: true in JSON

Hardhat Etherscan Plugin
Result: API errors and authentication issues

Manual API Submission (V1)
Result: "You are using a deprecated V1 endpoint" error

Bytecode Verification Status
✅ Deployed bytecode matches local compilation when compiled with viaIR: true

Example (SLDToken):

Deployed Bytecode (first 200 chars): 0x60806040908082526004918236101561001757600080fd5b600091823560e01c90816301ffc9a7146113db5750806306fdde03146112e6578063095ea7b3146112bd5780630a65788e146110b457806318160ddd14610afa578063...

Local Compilation Bytecode: Perfect match when viaIR: true

Dependencies

All contracts use OpenZeppelin Contracts v4.9.6:

@openzeppelin/contracts/token/ERC20/ERC20.sol
@openzeppelin/contracts/access/AccessControl.sol
@openzeppelin/contracts/security/ReentrancyGuard.sol

And other standard OpenZeppelin imports

Files Available for Verification

I have prepared comprehensive verification materials:

Flattened Source Code Files (10 files)

Located in: contracts/flattened/
Naming: [ContractName]_flattened.sol

All OpenZeppelin dependencies included

Standard JSON Input Files (10 files)

Located in: contracts/verification-json/
Naming: [ContractName]_verification.json

Complete compiler settings including viaIR: true

Hardhat Configuration

hardhat.config.js with exact compilation settings

Deployment Artifacts

deployment-complete-204-1761736572644.json with transaction details
Request

Could you please provide manual verification support for these 10 contracts?

Given that:

This is a production DeFi protocol serving real users on opBNB Mainnet
Contract verification is critical for user trust, security auditing, and transparency
The current verification interface lacks viaIR support
All verification materials are prepared and bytecode matches perfectly

Contact Information

Email: info@steadefinexus.com
Available Hours: 10AM - 7PM UTC +5.30
Response Time: Within 24 hours

Additional Context

This issue is similar to #631 regarding viaIR compilation support, but affects multiple contracts on opBNB Mainnet rather than a single contract on Ethereum Mainnet. The lack of viaIR support in the verification interface prevents legitimate projects with complex smart contract logic from achieving verification.

Proposed Solutions

Immediate: Manual verification using the provided materials
Short-term: Add viaIR option to opBNBScan verification interface
Long-term: Update Blockscout verification microservices to support viaIR compilation

Impact

AuxFund_verification.json
CatalystPool_verification.json
MatrixSystem_verification.json
P2PEscrow_verification.json
Registration_verification.json
SLDToken_verification.json
SlotSystem_verification.json
SteadefiCore_verification.json
TierBonus_verification.json

Users: Cannot verify contract functionality leading to trust issues
Security: Auditors cannot review unverified contracts
Ecosystem: Other protocols cannot integrate with unverified contracts
Project: Legitimate DeFi protocol cannot achieve transparency standards

Thank you for your time and consideration. I am available to provide any additional information or clarification needed for the verification process.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions