Smart contracts

Core concepts

Blockchain has introduced a shift in how applications execute logic and manage data in decentralized environments. Two core components that enable this automation are smart contracts and chaincode. While the terminology varies depending on the platform, “smart contracts” on Ethereum and other EVM-based platforms, and “chaincode” on Hyperledger Fabric, the conceptual foundation is similar: encapsulating business logic in a secure, verifiable, and autonomous format.

Both serve as deterministic code that gets triggered by transactions, leading to changes in state or the execution of defined logic. These units of automation replace the need for centralized backend services or intermediaries, reducing operational costs and increasing transparency and efficiency. However, the differences in architecture, programming model, governance, and performance between public and permissioned networks have led to platform-specific design choices and development methodologies for these artifacts.

Historical context and conceptual foundation

The concept of smart contracts dates back to the 1990s, introduced by Nick Szabo. His definition was more theoretical, focused on creating digitally-enforced contracts that automatically execute when predefined conditions are met. At the time, there was no platform robust enough to implement such logic in a decentralized and tamper-proof environment.

This changed with the advent of Ethereum in 2015. Ethereum was the first blockchain platform designed from the ground up with smart contracts in mind. It introduced the Ethereum Virtual Machine (EVM), a fully isolated runtime environment where smart contracts could be deployed and executed in a decentralized and trustless way.

Chaincode emerged later as part of Hyperledger Fabric, a permissioned blockchain platform developed under the Linux Foundation’s Hyperledger project. Fabric was built with enterprise requirements in mind, such as access control, privacy, and modular consensus, making it suitable for supply chain, finance, government, and other regulated industries. Chaincode plays the same functional role as smart contracts but operates in a controlled and governed environment.

Smart contracts in Ethereum

Ethereum smart contracts are programs written primarily in Solidity, a statically typed, contract-oriented language inspired by JavaScript and C++. These contracts are compiled into bytecode, which runs on the Ethereum Virtual Machine (EVM). Each deployed contract is stored at a specific address and maintains its own storage, execution logic, and interface functions.

A smart contract in Ethereum is deployed through a transaction containing its compiled bytecode. Once deployed, the contract becomes immutable, its logic cannot be changed unless an upgrade pattern, like proxy contracts, is used.

Smart contracts are triggered when a user or another contract sends a transaction to the contract’s address. The transaction includes a function selector (derived from the function signature) and the required parameters encoded using the Ethereum ABI (Application Binary Interface). When executed, the EVM processes the contract logic deterministically on every full node across the network.

Key constructs inside a smart contract include:

• msg.sender: The address of the account or contract that called the function
• msg.value: Amount of Ether sent with the call
• block.timestamp: The timestamp of the current block
• storage: A persistent key-value store associated with the contract
• memory: A temporary, volatile area used during execution

Contracts can hold Ether, interact with other contracts, emit events, perform mathematical computations, and enforce access control using modifiers.

Chaincode in Hyperledger Fabric

Chaincode in Hyperledger Fabric is the equivalent of a smart contract but designed for a permissioned, enterprise environment. It is commonly written in Go, but support is also available for Java and Node.js. Instead of being compiled to bytecode for a virtual machine, chaincode runs as a Docker container, isolated from the peer nodes.

The chaincode lifecycle in Fabric is significantly more structured and involves organizational governance. Here’s how it works: 1. Package: The chaincode is bundled into a .tar.gz archive that includes the source code and metadata. 2. Install: This package is installed on endorsing peers. 3. Approve: Each participating organization in the consortium must approve the chaincode definition. 4. Commit: After approval, the definition is committed to the channel.

The primary interface includes three functions:

• Init: Invoked when the chaincode is first deployed or upgraded.
• Invoke: Handles logic execution for transaction proposals.
• Query: Performs data reads without altering the ledger.

Unlike Ethereum, the state is not stored directly on the blockchain but maintained in a key-value world state database like LevelDB or CouchDB. Each peer maintains its own copy of this world state, while the blockchain itself acts as an immutable log of all transactions.

Execution models: Ethereum vs. Fabric

One of the most fundamental differences lies in how smart contracts and chaincode are executed and validated.

In Ethereum, every transaction is:

• Sent to the network
• Mined into a block by a validator
• Executed by every node on the network to ensure consistency
• Recorded in the blockchain

This is a replicated state machine approach. All full nodes execute the transaction and reach consensus on the outcome.

In Hyperledger Fabric, the process is more modular:

• Execution: Proposals are simulated by endorsing peers.
• Ordering: The endorsed transactions are submitted to an ordering service.
• Validation: Committing peers validate the endorsements before updating the state.

This execute-order-validate model allows Fabric to achieve high throughput and low latency while maintaining governance and security. It also enables confidential transactions using private data collections and organizational policies.

Smart contract storage and gas economy

In Ethereum, smart contracts operate under a tightly resource-constrained environment. Every operation within a contract consumes gas, which is paid in Ether. Gas acts as a safeguard against misuse or infinite loops and compensates miners or validators for the computation performed.

This makes storage optimization a major design concern. On-chain storage is expensive, so developers often use lean data structures:

• mapping(address => uint) for lookup tables
• Arrays for indexed access (though costly when large)
• bytes32 hashes to reference off-chain content (like IPFS data)
• Event logs to emit data retrievable by off-chain services without being stored on-chain

Additionally, there is no built-in concept of relational data or SQL-like queries. Developers must implement their own indexing, filtering, and pagination logic, or use off-chain services like The Graph to index contract events and expose a GraphQL API.

Due to Ethereum’s immutable nature, upgrading a contract means deploying a new version. Developers implement upgradeable contract patterns, such as:

• Proxy pattern: Separate storage from logic. The proxy contract forwards calls to the logic contract.
• EIP-1967 and EIP-1822: Standard layouts for upgradeable contracts
• UUPS (Universal Upgradeable Proxy Standard): A minimal and efficient upgrade pattern

These patterns allow the contract logic to be changed without losing state. However, they introduce complexity and must be handled with precision to avoid bricking the contract or introducing security vulnerabilities.

Chaincode storage and private data

In Fabric, the storage model is more flexible and familiar for enterprise developers. The world state is a database, typically:

• LevelDB: Default key-value store, fast and lightweight.
• CouchDB: Optional document-oriented store, supports complex queries.

Each key in the world state maps to a value (usually a JSON document). Transactions that change the state are recorded in blocks on the ledger but the current state is stored separately. This model separates state from the immutable transaction log.

Unlike Ethereum, Fabric allows for private data collections (PDCs). These are used when some data should only be visible to a subset of organizations in the consortium. Instead of storing sensitive data on the ledger, Fabric stores a hash of the data and shares the actual payload directly between authorized peers.

This enables compliance with privacy regulations and use cases such as:

• Trade finance (sharing sensitive invoice data)
• Pharmaceutical supply chains (batch data confidentiality)
• Government and inter-agency workflows

Chaincode can access both public state and private collections using the Fabric SDK or the GetPrivateData API. This modularity gives developers fine-grained control over data visibility and trust.

Access control and authorization

Security and permissioning differ significantly between public and private blockchains. Ethereum contracts are public by default. Anyone can call a function unless explicitly restricted. Developers implement access control using:

• Modifiers (e.g., onlyOwner)
• Role-based access (hasRole in OpenZeppelin’s AccessControl)
• Multi-signature schemes for administrative operations
• ecrecover to verify signatures and off-chain identities

Fabric uses MSP (Membership Service Providers) to manage identities. Each participant has an X.509 certificate issued by a recognized CA (Certificate Authority). Access control is enforced at several levels:

• Chaincode logic can inspect the client’s identity using APIs like GetCreator() or attribute-based logic.
• Channel configuration defines which organizations have access to which data and chaincode.
• Endorsement policies define which organizations must sign off on a transaction for it to be considered valid.

This makes Fabric highly suitable for inter-organization workflows, supply chains, and regulated environments where access must be restricted and auditable.

Language support and developer experience

The choice of programming language and development tools is another key distinction.

Ethereum:

• Primary language: Solidity
• Others: Vyper (Python-inspired), Huff (low-level), Fe (experimental)
• Tooling: Hardhat, Foundry, Truffle, Remix
• Testing frameworks: Mocha, Chai, Waffle
• Deployment: Infura, Alchemy, custom RPC nodes

Smart contract development includes writing Solidity code, compiling with the Solidity compiler (solc), and testing with local testnets like Ganache or Hardhat’s in-memory network. Advanced debugging, gas estimation, stack tracing, and coverage analysis are critical.

Hyperledger Fabric:

• Language: Go (recommended), JavaScript (Node.js), Java
• Tooling: Fabric SDKs for Node.js, Java, Go
• Development: peer lifecycle CLI, Docker-based containerization, Fabric CA for identity issuance
• Local deployment: Using Fabric samples or Docker Compose environments

Fabric provides structured sample chaincode templates and encourages modular design. Testing is typically performed using scripts that invoke chaincode through the SDK or CLI, simulating proposals and observing ledger updates.

In contrast to Ethereum, Fabric’s containerized environment allows for more traditional application development practices such as version control, unit testing, and CI/CD pipelines.

Event handling and off-chain integration

Smart contracts and chaincode both support emitting events, which are crucial for off-chain applications to track blockchain activity.

In Ethereum, contracts use the event keyword and the EVM logs these emissions. These logs are:

• Indexed by topics (event signature and arguments)
• Accessible via JSON-RPC (eth_getLogs)
• Frequently consumed by tools like The Graph, Moralis, or custom Node.js listeners using Web3.js or Ethers.js

In Fabric, chaincode emits events using the SetEvent API. These events are embedded in the transaction block and picked up by clients subscribed to the peer’s event services. Applications can register for block events, filtered events, or chaincode-specific events using the Fabric SDK.

This event-driven model is essential for building responsive frontends, notification systems, and external integrations (e.g., triggering a payment, updating ERP records, or syncing with cloud services).

Inter-contract communication and composability

In Ethereum, smart contracts can interact with one another using direct function calls or delegate calls. This enables composability, the property that allows multiple contracts to be used together like building blocks. Popular DeFi protocols (like Yearn, Aave, and Compound) rely heavily on this feature.

For example:

• A staking contract might call a reward distribution contract
• A DEX aggregator might route trades through multiple liquidity pools
• A governance contract might control upgrades to other contracts

However, care must be taken with reentrancy, gas limits, and fallback behaviors. Contracts should implement reentrancy guards and adhere to the “checks-effects-interactions” pattern.

Fabric does not support the same kind of composability because of its endorsement model and modular design. However, chaincode can still invoke other chaincodes via the InvokeChaincode function. This enables modular architecture where different chaincodes handle asset types, regulatory validation, or cross-channel data queries.

Governance and version management

Governance refers to the mechanisms used to control, upgrade, and manage access to contracts or chaincode in a blockchain network. In Ethereum, governance is often implemented at the application level, since the network itself is public and decentralized. Developers of decentralized applications (dApps) must build their own logic for:

• Administrator roles
• Multi-signature control
• DAO (Decentralized Autonomous Organization) structures for on-chain voting
• Time-locked functions and upgrade proposals

For example, a DeFi protocol may use a governance token that allows holders to propose and vote on upgrades to interest rate models or reserve factors. These votes trigger execution of functions in a “Governor” contract, which then calls the upgradable logic components. Governance becomes an intrinsic part of the protocol’s trust model.

Hyperledger Fabric takes a different approach. Governance is built into the platform:

• Only authorized members of the consortium can install or approve chaincode
• Channel configurations define organizational privileges
• Chaincode upgrades require unanimous or majority approval, depending on the endorsement policy
• Identity revocation and certificate expiration are centrally managed

Because Fabric is designed for permissioned consortia, every upgrade, channel change, or access configuration involves signed transactions from member organizations. This makes Fabric highly auditable and controlled, essential for enterprise-grade applications where legal compliance and operational risk are non-negotiable.

Performance and scalability

Smart contracts and chaincode differ significantly in performance, throughput, and scalability.

Ethereum, operating as a public blockchain, must optimize for decentralization and trust minimization. This limits throughput to a few dozen TPS (transactions per second) on the base layer. Although Ethereum 2.0 and layer 2 solutions (like Optimism, Arbitrum, zkSync) have increased capacity through rollups and sidechains, the base layer remains a bottleneck for compute-heavy logic.

Gas fees also influence scalability. During peak periods, gas prices can spike, making contract interactions prohibitively expensive for users. This pushes developers to optimize logic, reduce storage use, and batch operations to minimize user costs.

Hyperledger Fabric, by design, separates execution from consensus. It can achieve hundreds to thousands of TPS depending on the hardware, network configuration, and endorsement complexity. Since all participants are known and authenticated, Fabric eliminates the need for mining or staking, reducing overhead. Key scalability factors include:

• Number of peers and organizations
• Complexity of endorsement policies
• Volume of reads and writes per transaction
• Use of private data collections

Fabric can horizontally scale by splitting data across channels, independent ledgers with their own policies and chaincode. This allows one network to serve multiple business units or use cases in parallel.

Auditing and traceability

Smart contracts provide transparency because all interactions and state changes are visible on the blockchain. This is a double-edged sword. While it improves accountability, it also exposes sensitive logic and data. To mitigate this, developers use techniques like:

• Abstracting logic behind proxies
• Emitting only hashed or obfuscated data
• Encrypting off-chain payloads and linking via content hashes

Ethereum’s public nature is useful for use cases like:

• Verifying ownership (NFTs)
• Proving event occurrence (e.g., time of creation)
• Demonstrating fairness in auctions or gaming

Tools like Etherscan, Tenderly, and The Graph enhance auditability by providing indexed access to contract history, call traces, and error diagnostics.

Fabric provides native auditing capabilities tailored to enterprises. Each block contains a full cryptographic record of transactions, signed by the submitter and validated by the network. Logs can be exported to SIEM systems, fed into compliance dashboards, or attached to legal evidence trails.

Moreover, private data collections in Fabric allow organizations to prove data existence or perform zero-knowledge proofs without revealing raw data. This capability is invaluable for industries like:

• Pharmaceuticals (e.g., batch integrity)
• Trade finance (e.g., invoice fraud prevention)
• Government (e.g., tamper-proof registries)

Real-world use cases

Both smart contracts and chaincode have seen wide adoption, but in different domains:

Ethereum smart contracts

• DeFi: Lending (Aave), AMMs (Uniswap), stablecoins (DAI)
• NFTs: ERC-721 and ERC-1155 used in marketplaces like OpenSea
• Gaming: On-chain assets and play-to-earn mechanics (Axie Infinity)
• DAOs: Governance via tokenized voting
• Identity: Soulbound tokens and decentralized identifiers

These applications benefit from Ethereum’s global accessibility, network effects, and liquidity. However, they face limitations on speed, privacy, and cost.

Fabric chaincode

• Supply chain: Tracking agriculture, vaccines, mining products
• Finance: Cross-border payments, factoring, CBDCs
• Government: Land registry, voting, customs compliance
• Health care: Clinical trials, pharma cold chain, patient consent
• Insurance: Fraud prevention, parametric claims

These use cases prioritize privacy, trust, auditability, and control. They are often implemented as B2B consortia with legal agreements backing the chain.

Developer challenges and solutions

Developing smart contracts is intellectually rigorous and security-critical. Common challenges include:

• Unintended logic bugs (e.g., integer overflow, reentrancy)
• Upgrade complexity
• Gas estimation and limits
• Eventual consistency of cross-contract calls

To address these, best practices include:

• Using tested libraries like OpenZeppelin
• Auditing with tools like MythX, Slither, and Certora
• Writing extensive test cases and simulations
• Using static analyzers and symbolic execution tools

Chaincode developers face different hurdles:

• Understanding the Fabric lifecycle and endorsement policies
• Designing for modularity across organizations
• Managing certificate-based identities and wallets
• Setting up dev environments with Docker and CA nodes

Fabric provides starter kits, test networks, and sample chaincode to simplify onboarding. Larger projects benefit from using CI/CD pipelines, Helm charts, Kubernetes orchestration, and secrets management for production deployments.

Interoperability and cross-chain functionality

As blockchain ecosystems diversify, interoperability is becoming a crucial requirement. Smart contracts and chaincode must increasingly interact with systems beyond their native network, whether that’s another blockchain, a legacy ERP system, or a cloud-based analytics engine.

Ethereum and cross-chain interactions

Smart contracts on Ethereum can’t directly interact with other blockchains or external systems. To bridge this gap, developers rely on:

• Oracles (e.g., Chainlink, Band Protocol): These bring external data onto the blockchain. For example, fetching off-chain asset prices, weather information, or compliance results.
• Bridges: Used to transfer tokens and data between chains (e.g., Ethereum, Polygon). This allows liquidity movement and contract invocation across chains.
• Relayers and Message Passing Protocols: Protocols like LayerZero, Axelar, or Wormhole enable generic message-passing between smart contracts deployed on different blockchains.

However, these tools introduce new attack surfaces. Oracle manipulation (e.g., price feed exploits) and bridge vulnerabilities (e.g., reentrancy in token wrapping contracts) have led to several high-profile exploits in recent years.

To mitigate risk:

• Use decentralized oracles with reputation models
• Implement fail-safes and kill switches in contracts
• Design time-locks for sensitive operations
• Use multi-signature schemes for bridge control

Fabric and system integration

In contrast, Fabric is designed from the outset to be interoperable with enterprise IT systems. Chaincode interacts with:

• Client applications through SDKs that can relay events, fetch ledger data, and trigger invokes
• External databases or APIs through intermediary integration layers
• IoT networks feeding real-world data for automation (e.g., temperature sensors in pharma supply chain)

Furthermore, Fabric supports Chaincode-as-an-External-Service (CCaaS). This allows developers to write chaincode in any language and run it outside of the Fabric peer container. It opens the door to integrating with services like:

• Payment gateways
• Identity verification systems
• Cloud AI inference engines
• Enterprise databases (e.g., Oracle, SQL Server)

Integration patterns often include:

• Kafka streams or RabbitMQ for event-driven flows
• RESTful APIs with JWT tokens or OAuth for user authentication
• Hash-based proof mechanisms for verifiable claims

This flexibility is ideal for industries where blockchain is not a replacement, but a layer of integrity and auditability within a broader digital architecture.

Legal and compliance considerations

Smart contracts and chaincode carry real-world implications. As they increasingly encode legal agreements, regulatory frameworks are evolving to catch up.

Smart contracts can:

• Represent enforceable contracts (e.g., escrow logic for marketplaces)
• Trigger financial transactions or settlements
• Record legal rights (e.g., ownership of an NFT or real-world asset)

Challenges include:

• Immutability: Once deployed, a contract may be impossible to change, even if laws or user needs evolve.
• Jurisdiction: Ethereum nodes operate globally, but disputes are governed by national laws.
• Dispute resolution: There is no inherent mechanism for arbitration or human override in most public chain contracts.

Legal engineers are exploring hybrid contracts, where legal language and smart contract logic are linked. Tools like OpenLaw, Clause.io, and Accord Project attempt to bridge legal prose and executable code.

Efforts are also underway to formalize smart contract legality. For instance:

• EU’s MiCA regulation outlines requirements for crypto-asset service providers
• UK Law Commission recognizes smart contracts as enforceable under existing contract law
• The UNIDROIT project on digital assets and private law includes smart contract frameworks

Chaincode and compliance

Fabric, being permissioned, offers more compliance-aligned features:

• Identity and certificate traceability
• Role-based access control
• Confidential data sharing
• GDPR-aligned data deletion via off-chain referencing
• Regulatory reporting through block event logs

This makes Fabric well-suited for:

• Regulated industries like banking, insurance, pharmaceuticals
• Governments requiring high transparency and control
• Auditable workflow tracking (e.g., customs clearance, tax collection)

In many deployments, smart legal clauses are enforced via chaincode, while audit trails and logs are integrated with compliance reporting tools, reducing manual oversight and regulatory risk.

Security practices and threat models

Security in blockchain is binary, you’re either secure or exploited. The cost of failure is high, especially when code is immutable and value is at stake. Thus, security architecture is a fundamental concern for both smart contracts and chaincode.

Ethereum smart contract security

Risks include:

• Reentrancy: Attackers reenter the contract before state updates
• Integer overflow/underflow: Before Solidity 0.8.x, arithmetic bugs caused major losses
• Access control flaws: Misconfigured admin logic
• Front-running: Transaction order manipulation on public mempools
• Flash loan exploits: Temporary capital used to manipulate or drain funds

Security practices:

• Use established libraries (e.g., OpenZeppelin)
• Adopt design patterns like:
• Checks-Effects-Interactions
• Pull over Push payments
• Guarded fallback functions
• Write extensive unit and integration tests
• Conduct formal verification for critical logic
• Use static and dynamic analysis tools (MythX, Slither, Echidna)

Auditing firms such as Trail of Bits, Certik, and OpenZeppelin are often engaged before mainnet deployment.

Chaincode security

Chaincode operates in a more trusted and controlled environment but is not immune to risks:

• Logic bugs (e.g., flawed endorsement conditions)
• Data leakage via logs or improper use of private collections
• Identity spoofing if MSP or CA is compromised
• Insufficient validation of inputs
• Chaincode-to-chaincode access abuse

Security controls include:

• Certificate revocation and renewal mechanisms
• Endorsement and validation policies
• TLS-secured communication between peers and clients
• Audit logging and block-level integrity proofs
• Isolated container execution for chaincode logic

Organizations often deploy Fabric in hardened Kubernetes clusters with firewalls, DDoS protection, and intrusion detection systems to defend the full stack.

Enterprise adoption strategies

The path to adopting blockchain solutions differs significantly based on whether an organization builds with public smart contracts or private chaincode. Each comes with distinct architectural choices, legal implications, and business models.

Public blockchain adoption with smart contracts

Organizations building on Ethereum or other public blockchains often aim to:

• Tap into public liquidity and composability (e.g., DeFi or tokenized assets)
• Establish transparent and decentralized infrastructure for services like identity, media, or decentralized storage
• Implement open innovation models, such as incentivized networks and community-owned protocols

Adoption journey: 1. Prototype with testnets like Goerli or Sepolia using frameworks like Hardhat or Foundry 2. Deploy contracts on mainnet or L2 chains (Polygon, Arbitrum, Base) 3. Integrate frontends with wallet connectors (e.g., MetaMask, WalletConnect) 4. Secure through audits and bug bounty programs 5. Onboard users with token incentives, governance rights, or NFT rewards

Regulatory risks, gas cost volatility, and UX friction remain barriers. However, the community-driven innovation and developer tool maturity in Ethereum’s ecosystem make it the preferred platform for open financial and digital ecosystems.

Enterprise blockchain adoption with Fabric chaincode

Private consortiums adopting Fabric begin by identifying multi-party workflows that require:

• Trusted execution across organizational boundaries
• Verifiable audit trails
• Fine-grained access control
• Integration with legacy systems (ERP, CRM, payment rails)

Adoption journey: 1. Define the consortium: Roles, data owners, regulators, service providers 2. Design the network: Number of peers, channels, ordering nodes 3. Develop chaincode in Go or Node.js for domain-specific workflows 4. Configure MSPs, CAs, and identities for each organization 5. Launch pilot networks on local or cloud infrastructure 6. Scale deployment to production with orchestration, monitoring, and compliance processes

Industries like logistics, healthcare, government, and finance are actively deploying Fabric-based networks due to its modular, governed, and privacy-preserving design.

Trends shaping the future

Smart contracts and chaincode are evolving rapidly in response to both technical innovation and market demand. The following trends are shaping the future of blockchain development and deployment:

1. Zero-knowledge proofs (ZKPs)

Smart contracts are incorporating zk-SNARKs and zk-STARKs for privacy-preserving computation. Use cases include:

• Private voting (e.g., MACI)
• Anonymous identity (e.g., Semaphore, zkLogin)
• Scalable L2 rollups with zero-knowledge validity proofs (zkSync, Scroll, Polygon zkEVM)

Fabric is also exploring ZKP integration through custom chaincode modules that validate off-chain assertions without revealing underlying data.

2. Account abstraction

Ethereum is transitioning toward account abstraction (EIP-4337), allowing smart contracts to act as user wallets. This will enable:

• Gasless transactions (sponsored by dApps)
• Biometric or social login
• Session keys and programmable recovery

It transforms the UX of smart contract interaction and lowers the barrier to Web3 adoption for non-technical users.

3. Tokenization of real-world assets

Both smart contracts and chaincode are powering the tokenization of assets:

• Real estate, commodities, bonds, and even invoices
• On-chain trading, settlement, and collateralization
• Compliance with local regulations via role-based access and KYC integration

Platforms like SettleMint, ConsenSys Codefi, and R3 Corda are at the forefront of building asset tokenization infrastructure using these paradigms.

4. CBDCs and digital cash

Central banks are exploring digital currencies built on smart contracts or chaincode. Examples:

• Ethereum-based pilots (e.g., Banque de France, MAS)
• Fabric-based implementations (e.g., Project Bakong in Cambodia)
• Interbank settlement using private blockchains (e.g., Jasper-Ubin, mBridge)

These systems use programmable logic for issuance, circulation control, compliance, and analytics.

5. Decentralized identity and verifiable credentials

Smart contracts are increasingly tied to DIDs and VCs:

• Establish on-chain identifiers
• Issue credentials via trusted institutions
• Validate claims without revealing user data (e.g., zero-knowledge credentials)

Fabric supports similar models using attribute-based certificates and private data collections, making it ideal for enterprise-grade identity networks.