How a Global Bank Reviewed Smart Contracts Against Its Business Rules With CertiK

Client Success Case Studies
How a Global Bank Reviewed Smart Contracts Against Its Business Rules With CertiK

Executive Summary

A global bank operating in Hong Kong was developing smart-contract functionality to support digital asset operations within a controlled blockchain environment. The implementation combined token functionality with institution-controlled permissions, transaction restrictions, administrative actions, and upgrade mechanisms. The institution needed an assessment that examined the code in the context of its intended business rules and operating model, rather than applying generic assumptions about publicly accessible token systems.

CertiK reviewed the in-scope contracts through manual analysis and static checks, focusing on implementation correctness, privileged authority, transaction behavior, and upgrade safety. Client clarifications helped distinguish intentional operating requirements from implementation concerns and documentation gaps. Detailed assessment reports and companion summaries provided a documented security baseline and practical recommendations for future maintenance and release decisions.

Key Challenges

Aligning Smart Contract Behavior with Institutional Requirements

The implementation needed to support ordinary token activity while preserving the institution’s authority over sensitive operations and exceptional situations. Different transaction paths could legitimately apply different controls, depending on the intended business rules and the permissions of the participants.

The assessment therefore needed to distinguish an unintended control gap from a deliberate design choice. Where a behavior was intentional, the implementation and documentation still needed to describe it consistently so that developers, operators, and integrators would not rely on conflicting assumptions.

Understanding Privileged Authority Within the Operating Model

Sensitive operations were assigned to dedicated roles within a permissioned deployment model. The client also described external key-management arrangements and operational procedures supporting the use of privileged accounts.

The challenge was to assess what the contracts enforced directly while identifying where security depended on controls outside the reviewed code. Institutional governance could provide relevant context, but its description could not be treated as independent verification of the entire operating environment.

Maintaining Consistency Through Upgrades and Functional Changes

Upgradeable components introduced considerations beyond the immediate release. Initialization permissions, storage-layout maintenance, and the interaction between new and existing functionality needed to remain understandable as the implementation evolved.

Supporting transaction functionality also required clear treatment of edge cases and policy-dependent behavior. Without precise specifications, future changes could introduce inconsistent checks, integration ambiguity, or avoidable maintenance risks.

CertiK’s Solution

Reviewing the Implementation Against Its Intended Business Rules

CertiK combined detailed source-code examination with architecture-level analysis. The review examined functions, access restrictions, state changes, events, failure conditions, and the relationships between internal logic and externally accessible operations. At the architectural level, the team considered inheritance, role hierarchy, upgrade design, and the interaction between privileged actions and ordinary token activity.

Client explanations were incorporated into the assessment. Where implementation behavior was intentional but insufficiently documented, CertiK identified the issue as a specification or documentation concern rather than automatically presenting it as a confirmed implementation defect. This kept the assessment grounded in the institution’s intended operating requirements.

Examining Privileged Operations and Transaction Controls

CertiK reviewed the authority associated with sensitive functions and how that authority interacted with transaction restrictions. The assessment considered the distinction between ordinary user activity and institution-controlled intervention, together with the controls governing changes to the implementation.

Related transaction paths were compared to identify inconsistent behavior, unclear exceptions, and unnecessary validation. Recommendations addressed implementation clarity and maintainability while distinguishing security observations from code-optimization opportunities.

Combining Tool Checks with Manual Validation

Static analysis supported the identification of structural issues, permission patterns, and potentially risky code constructs. The audit team then checked the results against the source code, surrounding execution paths, client clarifications, and the intended operating model. False positives and duplicate observations were removed or consolidated before reporting.

The resulting assessment documented each finding’s classification, affected area, explanation, recommendation, and status. Companion summaries presented the principal observations and operating assumptions in a shorter format for internal stakeholders.

Value Delivered

A Documented Security Baseline

The assessments gave the institution a structured reference for the reviewed implementation, its administrative capabilities, and the assumptions supporting its operation. The principal observations concerned specification clarity, documentation consistency, and opportunities to strengthen upgrade lifecycle controls.

The reports preserved the distinction between recommendations delivered and changes verified. Acknowledgment of a finding did not mean that the underlying recommendation had been implemented or independently retested.

Clearer Alignment Between Code and Operational Expectations

CertiK identified areas where descriptions of authority, transaction restrictions, and exceptional actions did not fully explain the intended behavior. The recommendations provided a basis for aligning implementation comments, interfaces, and technical documentation.

This gave engineering and operational stakeholders a clearer reference for interpreting the contracts and deciding which matters required code changes, documentation updates, or further clarification of business requirements.

Practical Guidance for Future Maintenance

The engagement provided recommendations for more controlled initialization, clearer storage-layout maintenance, consistent treatment of transaction edge cases, and removal of unnecessary checks.

These recommendations addressed both the reviewed implementation and the risk of ambiguity during future development. They gave the institution concrete considerations to carry into subsequent upgrades and maintenance without implying that future releases had already been assessed.

Preparing to Launch or Update a Digital Asset Service?

CertiK reviews the smart contracts behind your service to identify security risks and assess whether they work as your business intends. Clear findings and recommendations help your team make informed development and release decisions.

相关博客

Why Brazil Is Becoming a Blueprint for Digital Asset Regulation

Why Brazil Is Becoming a Blueprint for Digital Asset Regulation

CertiK's CBO Jason Jiang joined the Central Bank of Brazil and Veirano Advogados at Blockchain.RIO to discuss how collaborative VASP regulation is turning Brazil into a global model for digital asset compliance.

CertiK’s Path Forward: Advancing Trust, Transparency, and Web3 Infrastructure

CertiK’s Path Forward: Advancing Trust, Transparency, and Web3 Infrastructure

As conversations at the 2026 World Economic Forum at Davos-Klosters, Switzerland continue to influence how global leaders engage with emerging technologies, one message is becoming increasingly clear: Web3 is entering a new phase defined by institutional participation, regulatory engagement, and long-term infrastructure.

What Makes a Web3 Project Worth Trusting?

What Makes a Web3 Project Worth Trusting?

Here's how a Web3 project can build trust with its community, and where that fits into the ethos of "trustlessness."