Innovation City Sets a New Standard in Web3 Security . Here’s How QuillAudits Made It Happen
Our thorough audit identified key vulnerabilities and delivered targeted solutions, reinforcing security, improving reliability, and ensuring a robust foundation for Web3 innovation
Before QuillAudits
- License Supply Accuracy - Total license count relied on _nextTokenId, which was not updated after revocations, leading to inflated and incorrect supply data
- Expired License Transfers - Expired licenses could still be transferred or reassigned by privileged roles, violating expiry rules and creating compliance risks
- Start Time Handling - Tokens minted with startTime = 0 stored incorrect timestamps, causing inaccurate reporting and breaking time-based logic
- Token ID Consistency - Token minting started from ID 0, conflicting with documented expectations and potentially causing integration confusion
- Access Control Clarity - Misleading comments and role usage created ambiguity around permissions and responsibilities
- Event Emission Efficiency - Duplicate MetadataUpdate events increased gas costs and cluttered logs
- Standards Compliance (ERC-5192) - locked() function did not follow ERC-5192 standards for non-existent tokens, leading to incorrect behavior
After QuillAudits
- License Supply Accuracy - Implemented a separate tracking mechanism to accurately reflect active license supply, ensuring correct reporting and system reliability
- Expired License Transfers - Added strict expiration checks to prevent transfer or reassignment of expired licenses, preserving validity and regulatory integrity
- Start Time Handling - Introduced validation and proper timestamp handling to ensure accurate start time recording and reliable time-based operations
- Token ID Consistency - Aligned implementation with documentation to ensure consistent and predictable token ID behavior
- Access Control Clarity - Updated documentation and clarified role usage to improve developer understanding and maintainability
- Event Emission Efficiency - Removed redundant event emissions, optimizing gas usage and improving log clarity
- Standards Compliance (ERC-5192) - Updated implementation to comply with ERC-5192, ensuring correct and expected behavior across integrations
Get an Audit done today for your Smart Contract
Join 1500+ leaders who secured themselves from losing Billion Dollars
Innovation City’s DigitalLicense contract functions as a centrally controlled, revocable Soulbound Token (SBT) system designed to manage digital licenses with precision and control. While built on standard ERC-721 structures, it departs from fully trustless ownership models by enabling controlled issuance, revocation, and reassignment of licenses.
The system’s security and reliability depend heavily on the operational security of privileged roles—MINTER_ROLE, UPGRADER_ROLE, and DEFAULT_ADMIN_ROLE—which govern critical functions. These contracts ensure structured license management, enforce access control, and enable transparent tracking of license states within the ecosystem.
The Future of Decentralised License Management
Innovation City envisions building a robust digital infrastructure for managing licenses, permissions, and digital identities through upgradeable Soulbound Tokens (SBTs). This approach aims to bring greater control, transparency, and efficiency to systems where ownership is non-transferable but still requires lifecycle management.
By leveraging blockchain-based licensing with revocation, upgradeability, and role-based control, Innovation City seeks to create a framework where digital assets can be securely issued, monitored, and governed without relying on traditional centralised systems.
This model enables organisations to maintain regulatory compliance, operational flexibility, and data integrity, while ensuring that licenses remain verifiable and tamper-resistant. Through this approach, Innovation City is positioned to redefine how digital rights and permissions are managed in an increasingly decentralised world.
Addressing Innovation City's Security Vulnerabilities
Our audit of Innovation City uncovered several vulnerabilities that required attention, including inaccurate license supply tracking, the ability to transfer expired licenses, and inconsistencies in time-based logic.
To address these issues, we implemented accurate license accounting mechanisms to ensure reliable supply data, enforced strict expiration checks to prevent invalid license transfers, and improved timestamp handling to ensure correct lifecycle tracking of licenses. We also enhanced standards compliance and optimised contract behaviour for better reliability.
These enhancements significantly strengthened Innovation City’s security posture, ensuring accurate license management, improved compliance, and greater trust in the system.
Innovation City's Journey Through Our Audit Process
Our comprehensive audit was executed through the following steps:
- Information Gathering
- Collected and reviewed all relevant documentation, including whitepapers, technical specifications, and design documents.
- Obtained a clear understanding of the Innovation City platform's functionality and intended user interactions.
- Discussed client concerns and specific areas of focus for the audit.
- Manual Code Review:
- Conducted a line-by-line review of the smart contract code, focusing on:
- Vulnerability identification: Searching for known vulnerabilities like reentrancy, front-running, integer overflows, and access control issues, etc.
- Logic flaws: Identifying inconsistencies or unintended behaviours in the code logic.
- Solidity best practices: Compliance with secure coding standards and adherence to established guidelines.
- Conducted a line-by-line review of the smart contract code, focusing on:
- Functional Testing:
- Developed and executed a comprehensive set of test cases covering various user interactions and edge cases.
- Leveraged tools like Hardhat and Ganache to deploy and test the smart contract locally.
- Automated Testing:
- Employed static analysis tools like QuillShield to identify vulnerabilities through automated code scanning.
- Utilised symbolic execution tools like Mythril to explore various code execution paths and uncover potential attack vectors.
- Integrated unit tests are written by the Innovation City team to verify specific contract functions and their behaviour.
- Reporting & Remediation:
- Prepared a detailed report outlining all identified vulnerabilities, categorised by severity and potential impact.
- Provided clear recommendations for fixing each vulnerability, including code snippets and best practices.
- Collaborated with the Innovation City Protocol team to prioritise and address the identified issues.
- Conducted additional verification testing after vulnerability fixes were implemented.
QuillAudits' Strategic Approach to Innovation City Security Audits
Our approach to auditing Innovation City involved a combination of threat modelling, a security-first mindset, and extensive testing. We used both white-box and black-box testing methods to ensure a thorough assessment, maintaining transparency and clear communication with the Huddle01 team throughout the process
Comprehensive Audit Discoveries and Remediation Strategies
Our comprehensive audit of these contracts revealed a total of 7 issues, categorised by severity:
- Medium Severity Issues (3): These issues pose a moderate risk and should be addressed promptly.
- Informational Issues (4): These findings provide valuable insights and recommendations for improvement.
Audit Discoveries
1. Inaccurate License Count After Revocation
Description:
The getTotalLicenses() function returns misleading data after licenses are revoked because _nextTokenId is never decremented when tokens are burned, causing the total count to include revoked licenses.
2. Tokens can be transferred even after expiration
Description:
The _update() hook enforces soulbound restrictions but does not check token expiration status. This allows MINTER_ROLE to transfer or reassign tokens that have expired.
3. StartTime of 0 does not default to store the current timestamp
Description:
When minting tokens and startTimeVal is set to 0 as the current timestamp to mean that the token is 'live' immediately, the logs are kept in the events, as well as the storage slot for startTime value holds 0 and not the timestamp required.
4. First Token ID Minted as Zero
Description:
Mints begin with the tokenId at 0, which is contrary to what is specified in the docs here.
5. Misleading comment with roles assigned to revoke()
Description:
Additionally, the contract's design document specifies that DEFAULT_ADMIN_ROLE should only manage roles, yet setContractURI() uses this role for contract metadata management.
6. Double event emission
Description:
The updateLicenseMetadata() function emits a MetadataUpdate event after calling _setTokenURI(), which already emits the same event internally.
7. ERC-5192 Compliance Issue
Description:
The locked() function does not follow the ERC-5192 specification regarding non-existent tokens. Per the standard, it should revert for non-existent tokens, but currently returns false.
Remediation Strategies
1. Inaccurate License Count After Revocation
Implement a separate counter to track accurate license supply and not _nextTokenId, as _nextTokenId can still be used for general mint count.
2. Tokens can be transferred even after expiration
Add expiration checks to _update() and reassign():
3. StartTime of 0 does not default to store the current timestamp
If (1) startTime is very sensitive for data provision AND (2) there is no plan to migrate old licenses to this new system, there should be sanity checks that startTimeVal is not below the current timestamp so new licenses cannot be backdated.
4. First Token ID Minted as Zero
Have the implementation contracts align with the specs as described.
5. Misleading comment with roles assigned to revoke()
Update the NatSpec comments to accurately reflect the implementation.
Additionally, clarify the intended scope of DEFAULT_ADMIN_ROLE in the contract documentation.
6. Double event emission
Remove the duplicate event emission.
7. ERC-5192 Compliance Issue
Align the current implementation to the ERC-5192 specifications.
Impressed by our findings and recommendations, the Innovation City Protocol developers promptly addressed all identified vulnerabilities.
Through our collaborative efforts, the Innovation City Protocol project is now significantly more secure, ensuring the protection of user funds.
Conclusion
The Innovation City smart contracts security audit identified and addressed critical vulnerabilities, protecting user funds and ensuring platform stability. This case study demonstrates the importance of proactive security measures for blockchain-based projects, especially those dealing with financial assets. By conducting audits and addressing identified issues, the Innovation City Team has taken a significant step towards securing its platform and safeguarding user trust.
