The Architecture Decisions Banks Must Get Right Before Building Onchain

For banks building onchain financial infrastructure, the decisions that most determine whether a program is defensible are made before a line of code is written. Upgrade governance, key management, and access control architecture are set during design, and by the time a security review is underway, they are largely fixed.

A security team can identify risks in those decisions, but it cannot always fix them without significant rework, or in some cases, full redeployment of a live system. This distinction matters enormously for onchain programs moving from innovation teams into core operations.

Why Onchain Architecture Is Harder to Change

In traditional software, most architectural decisions can be revisited with enough engineering effort. Access control models can be updated, infrastructure can be reconfigured, and most changes can be made without users noticing.

Onchain programs work differently. Smart contracts are immutable by default once deployed. Any upgradeability has to be deliberately designed in, and how that upgradeability is structured introduces its own security surface. Changes that would be routine in a traditional system can require onchain governance processes, new contract deployments, and migration of assets and state, all of which carry operational and security risk in a live financial environment.

This means the security posture of an onchain program is in large part a function of decisions made during architecture. A pre-launch security review documents the security model as built, and an architectural review shapes it.

The Decisions That Matter Most

Upgrade Governance

Whether and how a deployed contract can be upgraded is one of the most consequential architecture decisions a team makes, and one of the most commonly underspecified.

A non-upgradeable contract offers simplicity and predictability, but leaves no remediation path if a vulnerability is discovered post-deployment. An upgradeable contract introduces flexibility, but also introduces a question that needs a precise answer: who can authorize an upgrade, under what conditions, and with what controls?

Without a timelock, an upgrade can be executed immediately and unilaterally by whoever holds the relevant key. For banks, upgrade governance should map to institutional risk standards: timelocks that prevent immediate unilateral changes, multisignature requirements that distribute authority, and documented authorization processes that satisfy risk and compliance review, both internally and externally. These elements should be designed deliberately and in place before deployment.

Key Management and Access Control Architecture

Every privileged operation in an onchain financial system is controlled by private keys. The architecture of key management is fundamental to the security of the entire program: who holds keys, how they are structured and distributed, what authorization is required to use them, and how they can be rotated or revoked.

The consequences of getting this wrong compound quickly. Consider the privilege structure of a typical fiat-backed token:

• Proxy admin: can change contract logic
• Owner: controls role assignments
• Minter: controls issuance capacity
• Pauser: can halt transfers
• Blocklister: can freeze accounts

Each of these roles represents a distinct attack surface. If any one of them is compromised, the blast radius depends entirely on how the access control architecture was designed, and how quickly the rest of the system can respond.

A well-designed access control architecture limits what any single compromised key can do, ensures that high-impact actions require multiple approvals, and provides a clear path to containment. A poorly designed one means that compromising one role can cascade into full system control before any monitoring alert is actionable.

The Pause Mechanism and What It Does Not Cover

Many onchain financial programs include a pause mechanism as an emergency brake: the ability to halt transfers and minting quickly if something goes wrong. This is a sound design choice, and for banks, it is often a key part of the operational risk argument for going onchain.

A pause gates user-facing functions like transfers, mints, and burns. It does not, in most standard implementations, prevent privileged administrative actions. Ownership transfers, role updates, proxy admin changes, and contract upgrades can all execute while a contract is paused.

Dependency and Integration Design

Bank onchain programs integrate with external protocols, rely on oracles for pricing and data inputs, and in many cases, interact with other chains via bridges. Each of these integrations is an architectural choice and carries the risk profile of the external system it connects to.

Two relevant questions at the architecture stage are whether a given oracle or protocol is currently reliable, and whether the integration design limits exposure if it is not. Circuit breakers, fallback logic, and exposure limits are architectural controls that need to be specified before development begins.

Onchain dependencies carry their own risk profiles and represent attack surfaces beyond the primary smart contract. This is also a vendor risk and compliance question: protocols, oracles, and bridges warrant structured technical due diligence before integration, with findings documented in a form that satisfies internal risk review and regulatory scrutiny.

Chain Selection

The choice of which chain a program runs on is an early architecture decision with long-term security implications that is often treated primarily as a technical or ecosystem question.

Different chains carry materially different risk profiles: validator concentration, upgrade governance, incident history, and the maturity of the security tooling and security assessment ecosystem around them. For banks building production financial infrastructure, chain selection is a risk management decision as much as a technical one. It deserves structured analysis before development begins.

The Right Time to Assess These Decisions

A thorough security assessment of smart contract code before deployment remains a baseline requirement for any institutional onchain program. Ongoing monitoring after launch is necessary to maintain a current picture of exposure as the system, its dependencies, and the broader environment evolve.

The leverage is highest early, and not only because findings are cheaper to fix. Across 900+ security engagements, we see the same pattern: architectural decisions set the terms for every review that follows. An OpenZeppelin architectural review is a different kind of engagement than a pre-launch review: collaborative and prescriptive, it helps teams design access control structures, evaluate upgrade patterns, and make key management decisions before any of those choices are built in. A pre-launch review documents what was built and assesses it against known risk patterns. Both are necessary.

For banks where onchain programs face risk committee sign-off, compliance review, and regulatory scrutiny, that distinction is material. A program reviewed at the architecture stage produces a cleaner security assessment record, fewer deferred findings, and a clearer document to hand to a risk committee or regulator.

FAQs

Why are architecture decisions harder to change in onchain programs than in traditional software?

Smart contracts are immutable by default once deployed. Changing governance structures, access controls, or upgrade logic after deployment requires either a pre-designed upgrade mechanism or full redeployment, both of which are complex, high-risk operations for a live financial system.

What is upgrade governance and why does it matter for institutional onchain programs?

Upgrade governance defines who can authorize changes to a deployed smart contract and under what conditions. Without controls such as timelocks and multisignature requirements, a single compromised key can alter live contract logic before any response is possible. For banks, this needs to be designed to institutional risk standards before deployment.

Does a pause mechanism stop all activity in an onchain financial system?

Not necessarily. A standard pause mechanism halts user-facing functions like transfers and minting, but does not prevent privileged administrative actions such as ownership transfers, role updates, or contract upgrades. Understanding the precise scope of a pause is an architecture question that should be resolved and documented before launch.

How should banks approach onchain dependencies like oracles and bridges from a security perspective?

Onchain dependencies carry their own risk profiles and represent attack surfaces beyond the primary smart contract. Integration design should include controls that limit exposure if a dependency fails or is compromised. This is also a vendor risk and compliance question: protocols, oracles, and bridges warrant structured technical due diligence before integration, with findings documented in a form that satisfies internal risk review and regulatory scrutiny.

When is the right time to engage a security partner for an onchain program?

Security review at the architecture stage, before development begins, produces the highest leverage because findings can be fully remediated rather than deferred. Pre-launch security assessments and ongoing post-launch monitoring are also necessary, but the decisions that most determine a program's security posture are made during design.