UPLC Link Checks Cardano Contracts Against Published Code
Cexplorer integration brings source verification into contract browsing, while on-chain records preserve the details developers and auditors need to repeat the check.
By SongMarketCap
Updated:
UPLC Link lets Cardano users check whether a deployed smart contract matches the source code published for it. The open-source platform rebuilds contracts and compares their cryptographic fingerprints. Through Cexplorer, users can access the repository and build information associated with a script they are inspecting.
Cexplorer Connects Cardano Scripts With Their Source
Cexplorer’s “Verify Source” option links contract inspection with UPLC Link, providing access to the source repository, exact code revision, compiler version, and contract parameters.
Giovanni Gargiulo, Senior Blockchain Architect at the Cardano Foundation, demonstrated the workflow during Developers Office Hours on September 25. A session summary published on October 7 documented the integration and plans to expand compiler support.
The tool addresses a gap between publishing code and identifying what runs on-chain. A project may release its source and commission an audit, but users still need a way to establish that the deployed contract corresponds to the reviewed version.
For applications handling ADA and other Cardano assets, this connects the rules available for inspection with the scripts governing swaps, loans, or locked funds. Source verification establishes that connection; a security audit assesses the code for vulnerabilities.
Rebuilding Contracts Produces a Checkable Match
Cardano smart contracts execute as compiled Untyped Plutus Core, or UPLC. Their script hashes identify the compiled programs without revealing which source revision or build settings produced them.
UPLC Link starts with a specific GitHub commit and compiler version. It builds the source, calculates the resulting script hashes, and compares them with the expected on-chain identifiers.
The platform also handles parameterized contracts, whose final form depends on values supplied during setup. Developers can enter those values through the interface, including references to other scripts, and recalculate the result.
Matching requires the correct source, compiler, and parameters.
The public interface is currently labeled alpha and supports Aiken contracts. The presentation described work toward Scalus, Plutarch, and plu-ts support, alongside a planned connection with Blaster for automated formal verification of contract properties.
These extensions would broaden the platform’s coverage beyond its current Aiken workflow.
On-Chain Records Support Independent Verification
CIP-0171 proposes a shared metadata format for recording the information needed to reproduce a Cardano contract build. It uses transaction metadata label 1984 to identify the source repository, code revision, compiler, build environment, and parameters.
The source remains in its repository, while the blockchain preserves the build instructions. Auditors and researchers can publish records independently of the original deployer, then test them by rebuilding the referenced code and checking the resulting hash.
The specification remains a proposal in the official CIP registry. Its format accommodates several compiler families, with each verification tool determining which it supports.
UPLC Link already offers registration through a signed Cardano transaction, with the network fee paid in ADA. Its backend indexes submitted records for discovery through the public registry. The project also provides an API for other services and publishes instructions for running the platform locally.
For a registered contract, reviewers can start from its address or script hash, retrieve the recorded build details, and check the source connection themselves. Application teams can provide that reproducible record alongside their code and audit reports.