Five Questions,
Answered.
Infinity Blockchain Solutions' response to the standard selection questionnaire for the Smart Contract Suite.
Our Answers
"Two mainnet contract addresses you authored, verified on the explorer."
We've deployed over 700+ smart contracts across Ethereum, BNB Chain, Polygon, Base, and Solana. Here are a few of them, each verified and publicly viewable on its native block explorer:
"Has any contract you wrote been through an external audit? Which firm, and what was the most severe finding?"
Many of our contracts have been audited by leading firms in the Web3 security space, including Cyberscope, SolidProof, and Coinsult. A selection of our public audit reports:
Our goal is to always avoid any Critical, High, or Medium level issues in the contract, as they actually matter. Low or informational level issues do not carry much weight, since they are just best practices and vary from auditor to auditor.
"Which testing framework do you use and what coverage do you deliver? Have you written fuzz or invariant tests before?"
We test every contract using Solidity static analysis, Slither, Surya call graphs, and through manual code review. We've also conducted a number of audits ourselves, and the reports are public on our GitHub:
github.com/InfinityBlockchainSolutions/Audit-Reports ↗"If the owner role is a multisig address set in the constructor with no function to change it afterwards, and a state change must be irreversible with no admin override, how do you implement it and how do you test it?"
We treat "no function to change it" as a structural guarantee: the setter has to be absent from the bytecode, not just gated.
Implementation
- Owner is declared
address public immutable owner, assigned once in the constructor from the multisig address passed in at deployment. Solidity bakesimmutablevalues into the runtime code, so there is noSSTOREpath left for any function to reach afterward. - We skip OpenZeppelin's standard
Ownablehere, since it ships a mutable owner withtransferOwnership. A minimal custom check (or a hard-overridden, always-reverting transfer function) is used instead. - The irreversible action itself is a single
boolflag that can only movefalse → true, inside oneonlyOwnerfunction guarded by arequire(!confirmed)check. No function anywhere in the contract sets it back tofalse.
Testing
- Constructor test: confirms the multisig address is stored correctly and that no external/public selector in the ABI can write to it.
- Access-control test: any non-owner caller reverts on the confirmation function.
- Happy-path test: the owner's first call flips the flag and emits the expected event.
- Re-entry test: a second call, even from the owner, reverts with
AlreadyConfirmed. - Foundry invariant/fuzz test: arbitrary sequences of calls against every public function, asserting the flag never transitions back to
false. - Raw storage check: read the owner's storage slot directly (
vm.load/getStorageAt) to confirm it never changes, independent of the ABI surface.
"Would you do the work personally, or subcontract any part of it?"
All of the work would be handled directly by our team. None of it will be subcontracted. Specification review, implementation, testing, and deployment support are carried out in-house from start to finish.