Permissioned DeFi Guide: How Chain Operators Can Add Guardrails for Crypto Compliance, KYC, and More

Blockchains are built to be permissionless: Anyone can transact and anyone can build. That openness has facilitated the constant innovation, more efficient transacting, and global access to liquidity that makes DeFi uniquely powerful compared to traditional systems.

But for banks, fintechs, and other TradFi players moving onchain, openness brings challenges. While these institutions want the benefits of decentralization, they still have regulatory obligations around financial crime and market integrity that don’t disappear when they move onchain. 

Luckily, it’s possible for chain operators to deliver the compliance controls TradFi needs, while still maintaining base level decentralization that makes crypto so powerful. Thanks to the granular control a dedicated chain provides, chain operators can add onchain permissioning mechanisms in several ways – at the consensus, bridge, RPC, and protocol levels – to layer in compliance controls as needed for specific use cases. Let’s explore how below. 

Blockchain permissioning layers: Different levels of chain infrastructure can support different controls

Every chain is made up of layers of infrastructure that builders can tweak and combine in different ways to suit their use case – including when it comes to compliance. Each layer of the chain can support unique guardrails and methods of enforcing compliance requirements, and each has a different level of impact on the chain’s overall decentralization. 

Here’s our breakdown of the chain infrastructure layers where you can implement compliance guardrails, ranked from least to most impactful on the chain’s overall openness and decentralization.

• Protocol layer: The protocol layer refers to apps and assets built on your chain with smart contracts. You or the builders developing the contracts can encode rules around who can use individual assets or apps with minimal impact on the rest of the chain.
• Bridge layer: The bridge is how people move funds on and off of your chain. You can implement controls at the bridge layer to decide who can and can’t enter your ecosystem, without dictating what they do once they’re inside.
• RPC layer: The RPC layer is how users and apps interact with your chain – carrying out transactions, reading and writing data, etc. You can implement controls around how RPC requests are approved or not, and around access to official RPC endpoints via API keys. These measures shape how users interact with the network’s entry points, but they’re policies that can be easily updated – plus, on many chains, savvy actors can still run their own nodes, meaning RPC layer controls’ overall effect on the chain’s openness would be limited. 
• Consensus layer (sequencer or validator set): The consensus layer refers to your chain’s block producers — sequencers on rollups, or validators on L1s. You can enforce controls here by setting base-level policies around which transactions get included in blocks. This provides the strongest compliance guarantees but also has the biggest impact on the chain’s overall openness, as every transaction on the chain will be subject to these rules.

It’s important to remember that most compliance functionalities can be addressed in different ways at different layers of the chain’s infrastructure. Let’s dive more into what permissioning looks like at each layer below.

Protocol layer: App and asset-level rules for permissioned DeFi

The protocol layer refers to the apps, assets, and other tools built on your chain, which run based on the code of their underlying smart contracts. Any permissioning or controls implemented at the protocol layer will only apply to the specific apps and assets associated with the smart contracts modified, providing precise guardrails that don’t constrain the rest of the chain’s activity. 

It’s important to keep in mind that strictly from the chain operator point of view, you aren’t the one primarily responsible for implementing protocol layer controls – it’s the people building the protocols. Many chain operators do build apps on their own chain, i.e. in the case of a chain dedicated to a single app (an appchain), or a team that builds first-party apps to sit within their chain’s larger ecosystem. But in many cases, third-party developers are the ones who will be directly implementing protocol layer controls. However, you can enable protocol layer controls indirectly with supporting infrastructure like chain-wide identity standards, integrated compliance-focused oracles, smart contract templates with compliance features, and other such tools.

Examples of possible compliance controls and permissioning measures at the protocol layer include:

• Whitelisting by asset: Token standards like ERC-3643 support tokens with built-in permissioning measures, such as whitelisting controls for who can hold and transfer the token – very useful for RWAs, tokenized funds, etc.
• Credit checks in lending pools: A lending protocol can require users to pass onchain or attested creditworthiness checks before borrowing. This can incorporate both onchain collateral ratios and offchain data (such as proof of assets held with a custodian), ensuring borrowers meet prudential requirements before accessing leverage.
• Geographic restrictions on asset holders: Smart contracts can verify a user’s jurisdictional credential before allowing them to hold or transact a specific asset. For example, a team could offer a structured product token with built-in code blocking U.S. persons from subscribing if they don’t have the proper U.S. registrations, preventing regulatory breaches while still allowing users in other countries to use the token.

In short, the protocol layer gives issuers and app builders the ability to hard-code compliance into their products without affecting the broader chain.

Bridge layer: Whitelisting and KYC bridging

The bridge is how assets and users move on and off of your chain, connecting it to the wider crypto ecosystem. The bridge layer is therefore the most natural place to implement KYC checks and other whitelisting measures that determine who can and cannot access your chain in the first place.

The bridge layer enforces uniform, ecosystem-wide policies at the perimeter of the network, while leaving internal activity and composability largely intact. So, your chain can remain open and permissionless in terms of what users can do, even with permissioned bridging controlling who those users are.

Examples of possible compliance controls and permissioning measures at the bridge layer include:

• KYC for the whole chain: Require all users to complete KYC before bridging in, ensuring you can attribute all activity to specific users as regulations require and prevent high-risk users from entering.
• Limited institutional access: Similar to the above, you can also limit bridging to approved wallets. For instance, some TradFi chains may want to limit users to verified banks or financial institutions.
• Bridging velocity limits: Many banks enforce transaction velocity limits to mitigate certain forms of fraud and money laundering. You can do the same at the chain level by enforcing daily caps on users’ inflows and outflows via the bridge.

The bridge acts as your ecosystem’s front gate, giving you powerful tools to shape who participates in your network and under what conditions.

RPC layer: Node-level access controls for your blockchain

The RPC (Remote Procedure Call) layer is how most users and applications interact with your chain, mostly using official node endpoints. At the RPC layer, chain operators can gate who gets to send transactions in certain contexts, apply real-time checks before broadcasting transactions to the network, and log metadata that regulators may require. These measures don’t necessarily alter the chain’s underlying openness – users can independently run their own nodes on many chains – but they can ensure that the default pathways to using the network are compliant.

Examples of possible compliance controls and permissioning measures at the RPC layer include:

• Geographic restrictions: Official RPC endpoints can block requests from sanctioned or high-risk jurisdictions based on IP addresses or other characteristics, ensuring for regulators that users from blacklisted regions can’t interact with the network through its standard gateways.
• Transaction approval based on regulations: Transactions carrying unique risk or regulatory requirements (e.g. high-value transfers, complex derivatives trades, etc.) can be routed through specialized nodes that apply automated compliance checks (e.g. reviewing the initiating address for suspicious activity or relevant credentials). If the transaction passes, the node green-lights it and relays it to the chain. This creates an auditable approval workflow similar to what regulators require offchain.
• Automatic Travel Rule compliance. RPCs can require originator and beneficiary information for large transfers before they’re broadcast, attaching the relevant metadata or encrypted credential payloads. This aligns with the FATF Travel Rule by ensuring identifying information is collected and transmitted on transfers above the defined threshold.

The RPC layer is a great way to apply real-time compliance measures to specific transactions. 

Consensus layer: Sequencer and validator-level controls for network-wide enforcement 

The consensus layer refers to how the chain produces new blocks. For rollups, that means the sequencer. For L1s, that means the validator set. 

Permissioning controls implemented here are the deepest and most sweeping, because they determine which transactions get included in the blockchain at all. That makes the consensus layer the most powerful lever for compliance, but also the most inflexible and impactful on the chain’s overall openness: every user and every app inherits whatever rules the consensus layer enforces. Therefore, chain operators should generally use this layer to implement rules that are essential to their use case or necessary for coordinating activity across multiple protocols. 

Examples of possible compliance controls and permissioning measures at the consensus layer include:

• Circuit breakers: The SEC and similar regulatory bodies use circuit breaker rules to temporarily halt trading at times of great volatility or sudden price drops. With TradFi embracing blockchains for stock tokenization, it’s easy to see that we may want similar capabilities onchain. Chains focused primarily on trading of tokenized assets could implement circuit breakers at the consensus layer to temporarily halt transactions – either ecosystem-wide or just for a subset of tokens – in periods of extreme volatility, liquidity failure, or suspected exploits.
• Cross-app coordination: Because sequencers see all pending transactions, they can enforce rules that span multiple protocols – for instance, blocking a wallet flagged for a risky position on a perps DEX from borrowing on a separate lending protocol, ensuring compliance and risk controls apply consistently across the ecosystem.
• Chain-wide enforcement: We’ve discussed many rules and permissioning tactics in the context of specific apps, assets, or transaction types. If a chain wanted to enforce similar rules across the entire network, the sequencer would be the place to do it. For instance, the consensus layer could enforce maximum limits on daily transaction activity or loan collateralization on all addresses across the ecosystem, or set different rules for different addresses based on their accreditation or verified offchain holdings. Or, the consensus layer could ensure that only certain classes of investors are allowed to execute specific types of high-risk transactions, regardless of which protocols they use. 

Consensus layer controls provide the strongest compliance guarantees for your chain by enforcing rules network-wide. However, they’re virtually impossible to implement without a significant level of centralization. 

Chain operators can implement permissioned DeFi controls that fit their strategy

For institutions, the challenge has never been whether blockchains can deliver efficiency, liquidity, and innovation – it’s whether they can do so within the boundaries of compliance. Permissioned DeFi provides the answer, and owning the chain yourself is the best way to set the permissioning rules that make sense for your users. By applying controls at the protocol, bridge, RPC, and consensus layers, chain operators can add the same guardrails that exist in traditional markets – KYC, AML, sanctions screening, investor protections – while still preserving the unique benefits of DeFi.

The specific rules and infrastructure used to enforce them will depend on your use case, user base, and appetite for openness versus control. But the takeaway is clear: permissioned DeFi isn’t about compromising on innovation. It’s about unlocking it for a broader set of participants who need compliance by design. With thoughtful implementation, your chain can achieve the perfect mix of decentralization, innovation, and compliance.