Tezos provides a suite of native Michelson instructions for common cryptographic operations, including hashing (SHA256, BLAKE2B, KECCAK) and elliptic curve signature verification (CHECK_SIGNATURE). These primitives are not external libraries but first-class protocol features, meaning their gas costs and behaviors are fixed by the network's amendment process. For builders, this eliminates dependency risk but demands precise, protocol-aware implementation to avoid subtle vulnerabilities in custody, escrow, and authentication contracts.
Protocols
Timelock and Cryptographic Primitives
Implementation guide for developers using built-in Michelson functions for hashing, CHECK_SIGNATURE verification, and time-locked transactions via the LEVEL instruction. Covers correct usage patterns, common mistakes, and where cryptographic review adds value for custody and escrow contracts.
introduction
CRYPTOGRAPHIC BUILDING BLOCKS
Introduction
A developer-focused guide to using Tezos's built-in Michelson primitives for hashing, signature verification, and time-locked transactions.
A critical but often misunderstood primitive is the LEVEL instruction, which returns the current block level. When combined with a comparison against a stored constant, it forms the basis for absolute time-locks in Michelson. Unlike Ethereum, where block times are variable, Tezos uses a fixed minimal block time, allowing developers to set a minimum elapsed time with a known lower bound. However, the LEVEL instruction reflects the block in which a transaction is included, not the time of submission, a distinction that can create race conditions in high-stakes settlement contracts if not modeled correctly.
Common implementation mistakes include using CHECK_SIGNATURE without verifying the signed message's structure, which can make a contract vulnerable to replay attacks across different entrypoints or contracts. Similarly, naive time-lock implementations that fail to account for the baker's ability to delay inclusion within a small window can create unintended arbitrage opportunities. A rigorous review of these cryptographic and temporal logic patterns is essential for any contract managing significant value, from institutional escrow to DAO treasury vesting schedules.
CRYPTOGRAPHIC PRIMITIVES AND TIMELOCK
Quick Facts
Operational and security facts for developers using Michelson hashing, signature verification, and time-locked transactions.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Hashing | Michelson provides BLAKE2B, SHA256, SHA512, and KECCAK opcodes. No new algorithms are added without a protocol upgrade. | Smart contract developers, auditors | Verify the specific hash function and digest size used in the contract against the protocol specification. |
Signature Verification | CHECK_SIGNATURE verifies Ed25519, Secp256k1, and P-256 signatures. The key and signature encoding must match the expected scheme. | Wallet integrators, custody teams, dApp developers | Audit the key prefix handling logic in off-chain signing tools to prevent signature mismatch failures. |
Timelock (LEVEL) | The LEVEL instruction pushes the current block level onto the stack, enabling time-locked transactions without an oracle. | DeFi protocol architects, escrow contract developers | Review timelock logic for off-by-one errors where block times may vary from real-world time assumptions. |
Key Management | Private key exposure leads to irreversible asset loss. Tezos offers no native social recovery or account abstraction at the protocol layer. | Custodians, exchanges, individual bakers | Implement remote signing with HSMs and audit the key ceremony process to eliminate single points of compromise. |
Operation Forging | Transactions must be locally forged into bytes before signing. Incorrect forging of complex parameters can lead to failed operations or fund loss. | Exchange engineers, wallet SDK developers | Validate forged bytes against a Tezos node using the /chains/main/blocks/head/helpers/forge/operations RPC before signing. |
Simulation | The simulate_operation RPC pre-flights transactions to predict gas costs, storage updates, and balance changes without risking assets. | Custody platforms, high-value transaction operators | Integrate simulation into the signing pipeline to catch parameter errors and unexpected contract behavior before broadcast. |
Randomness | On-chain randomness is limited. The RANDOM opcode and commit-reveal schemes are vulnerable to manipulation by bakers. | Gaming and lottery contract developers | Do not rely solely on on-chain entropy for high-value outcomes. Seek a security review of the randomness source and commit-reveal lifecycle. |
technical-context
CRYPTOGRAPHIC AND TEMPORAL BUILDING BLOCKS
Technical Mechanism and Usage Patterns
How Tezos Michelson provides native functions for hashing, signature verification, and time-locked execution, and where incorrect usage introduces security risk.
Tezos embeds a set of cryptographic primitives directly into the Michelson smart contract language, allowing on-chain logic to verify signatures, compute hashes, and enforce time-based constraints without relying on external oracles or off-chain computation. The core primitives include CHECK_SIGNATURE for Ed25519, Secp256k1, and P256 elliptic curve verification; BLAKE2B, SHA256, SHA512, and KECCAK for hashing; and the LEVEL instruction for accessing the current block level. These functions are gas-costed and available in any Michelson contract, making them foundational for custody contracts, multisig wallets, HTLCs (Hash Time-Locked Contracts), and escrow systems.
The CHECK_SIGNATURE instruction takes a key, a signature, and a message, returning a boolean. A critical operational detail is that the key must be supplied as a raw byte sequence in the expected format for the chosen curve, and the signature must be in the canonical, non-malleable form enforced by the protocol. Failure to validate the boolean result, or using a malleable signature from an external source, can allow unauthorized actions. For time-locked transactions, the LEVEL instruction returns the absolute block level of the current block. Developers typically compare this against a stored expiry level to gate withdrawals or settlement. However, LEVEL is not a timestamp; block times on Tezos are not perfectly constant, so time-sensitive logic must account for variance in block production rates, especially around protocol upgrades or network irregularities.
Common implementation mistakes include: using CHECK_SIGNATURE without verifying the recovered key against an expected set of authorized signers, constructing HTLCs where the secret preimage is not properly bound to the recipient to prevent front-running, and relying on LEVEL for precise time enforcement without an acceptable buffer. For custody and escrow contracts, a formal review of the cryptographic flow is essential. Chainscore Labs assesses whether signature schemes are correctly parameterized, whether hash preimage secrecy is maintained across the transaction lifecycle, and whether time-lock logic is robust against block-level manipulation and chain reorganization scenarios.
WHO MUST REVIEW TIMELOCK AND CRYPTOGRAPHIC IMPLEMENTATIONS
Affected Actors
Custody and Escrow Contract Developers
Teams building time-locked vaults, payment escrows, or vesting contracts are directly affected by the correctness of CHECK_SIGNATURE and LEVEL instruction usage.
Critical review areas:
LEVELcomparisons must use strict inequality operators to prevent premature fund release.- Signature verification logic must not be bypassed by malformed
keyorsignatureparameters. - Multi-sig timelock patterns require careful ordering of signature checks and level constraints.
Action items:
- Audit all code paths that combine
CHECK_SIGNATUREwithLEVEL-based gates. - Verify that failed signature checks correctly abort execution rather than falling through.
- Test edge cases around block boundaries where
LEVELmay equal the unlock threshold.
Chainscore Labs can perform targeted review of timelock and signature verification logic to prevent fund loss from off-by-one errors or verification bypasses.
implementation-impact
CRYPTOGRAPHIC AND TIMELOCK PRIMITIVES
Implementation Impact and Workflow
Operational impact analysis for developers integrating Tezos built-in hashing, signature verification, and time-locked transactions. Covers correct usage patterns, common failure modes, and where cryptographic review adds value for custody and escrow contracts.
01
Secure CHECK_SIGNATURE Integration
The CHECK_SIGNATURE instruction verifies Ed25519, Secp256k1, and P256 signatures but requires strict byte-level message formatting. A common mistake is hashing the wrong data representation or failing to enforce key continuity. For custody and multisig contracts, a single padding error can allow signature forgery. Teams should implement structured message formats with domain separation and have the verification logic reviewed against the specific Michelson encoding of the signed payload.
02
Timelock Construction with the LEVEL Instruction
The LEVEL instruction returns the current block level, enabling time-locked transactions by asserting that LEVEL is greater than or equal to a stored unlock level. However, block times on Tezos are not perfectly uniform, and bakers can influence block inclusion timing within a small window. For high-value escrow or vesting contracts, teams should model the acceptable timing variance and consider whether a multi-block confirmation requirement or an oracle-backed timestamp provides stronger guarantees for the specific use case.
03
Hashing Primitive Selection and Collision Resistance
Michelson provides SHA256, SHA512, BLAKE2B, and KECCAK. Developers must select the appropriate primitive based on the security model: SHA256 and BLAKE2B are widely used for commitment schemes, while KECCAK is required for Ethereum compatibility. A critical error is using a single hash where a double-hash or domain-separated construction is needed to prevent length-extension or cross-context attacks. Teams building bridges or cross-chain applications should document their hashing rationale and have it reviewed.
04
Operational Risks in Timelock Governance
Contracts that use LEVEL-based timelocks for governance actions (e.g., delayed admin upgrades) introduce an operational dependency on block production. During network slowdowns or baking disruptions, the unlock may be delayed beyond the expected wall-clock time. Operators must monitor the gap between current block level and the unlock threshold, and governance processes should account for this variance in their emergency response timelines. Chainscore Labs can review the timelock parameters against the protocol's historical block time distribution.
05
Composability Risks with Cryptographic Primitives
Contracts that combine CHECK_SIGNATURE, hashing, and timelocks in a single entrypoint create complex state machines where the order of operations is security-critical. For example, a timelocked withdrawal that verifies a signature after the lock expires must ensure the signature cannot be replayed across different lock periods. Teams should model the full lifecycle of such composite operations and test edge cases where block level and signature validity interact. A formal review of the entrypoint logic reduces the risk of race conditions and replay attacks.
06
Testing and Simulation Workflows
Michelson cryptographic operations behave deterministically but can produce unexpected results when fed malformed inputs or edge-case key formats. Teams should build test suites that cover invalid signature lengths, zeroed keys, and boundary block levels using the Tezos client's run_script and simulate_operation RPCs. For timelock contracts, simulate the exact block level at which the lock should release and verify the gas costs do not exceed the block limit. Chainscore Labs can design test vectors that stress the cryptographic assumptions of the contract.
CRYPTOGRAPHIC AND TIMELOCK IMPLEMENTATION RISKS
Risk Matrix
Evaluates failure modes and operational risks for developers implementing Michelson cryptographic primitives and time-locked transactions in custody, escrow, and high-value contracts.
| Risk | Failure mode | Severity | Mitigation |
|---|---|---|---|
Incorrect hash algorithm selection | Using BLAKE2B where SHA256 is expected by an off-chain verifier causes permanent signature or commitment validation failures. | High | Explicitly document the expected hash algorithm in the contract specification and verify it during a cryptographic review. |
CHECK_SIGNATURE key misuse | Verifying a signature against the wrong public key or a key not bound to the intended signer allows unauthorized spend authorization. | Critical | Ensure the public key is either hardcoded, sourced from a trusted oracle, or passed via a secure off-chain signing ceremony reviewed by Chainscore Labs. |
Timelock bypass via level manipulation | Relying on the LEVEL instruction for absolute time-locking without accounting for baker control over block timestamps can lead to premature or delayed execution. | Medium | Use LEVEL for relative block-count locks and document the acceptable drift. For strict time bounds, combine with an off-chain oracle or accept baker influence risk. |
Replay attack on signatures | A valid signature for one operation can be replayed on a different entrypoint or contract if the signed payload does not include a unique nonce, chain ID, or operation hash. | High | Include the chain ID, contract address, and a strictly incrementing nonce in the packed bytes before hashing and signing. |
Hash collision in commitment schemes | Using a truncated hash or a weak hashing scheme for a commit-reveal pattern allows a malicious participant to open a different value than committed. | High | Use a full 256-bit BLAKE2B or SHA256 hash. A security review should verify that the reveal payload is uniquely bound to the commitment. |
Gas exhaustion in cryptographic loops | Performing signature verification or hash operations inside an unbound loop can cause transactions to exceed gas limits, locking funds permanently. | Medium | Set strict limits on loop iterations and benchmark gas costs for worst-case cryptographic operations during the testing phase. |
Insecure randomness for timelock puzzles | Using a predictable seed or a weak source for a time-lock puzzle allows an attacker to solve it faster than the intended delay. | Critical | Do not rely solely on on-chain state for puzzle generation. Use a verifiable delay function (VDF) or a trusted external randomness source with a security review of the puzzle construction. |
Storage bloat from large public keys | Storing uncompressed or excessively large keys on-chain increases origination and interaction costs, making the contract economically unviable. | Low | Store only the hash of the public key on-chain when possible, or use the smallest key representation supported by the curve. Validate storage costs during a gas optimization review. |
CRYPTOGRAPHIC AND TIMELOCK PRIMITIVES
Developer Implementation Checklist
A practical checklist for developers integrating Tezos built-in cryptographic functions and the LEVEL instruction for time-locked transactions. Each item identifies a critical verification step, explains why it matters for contract security and correctness, and specifies the signal or artifact that confirms readiness for mainnet deployment.
Confirm that the chosen Michelson hash function (BLAKE2B, SHA256, SHA512, KECCAK) matches the required security properties for the use case. BLAKE2B is the default for on-chain operations and is optimized for Michelson, while KECCAK is necessary for Ethereum compatibility. Using the wrong primitive can break cross-chain verification or reduce collision resistance below the contract's security model.
Readiness signal: A design document mapping each hash usage to its cryptographic requirement, with a justification for the selected algorithm. Test vectors from a known-good implementation match on-chain results.
resource-links
TEZOS DEVELOPER REFERENCES
Source Resources
Canonical references and operational resources for Tezos teams implementing Michelson hashing, signature verification, timelock logic, and level-gated contract execution.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
DEVELOPER FAQ
Frequently Asked Questions
Common questions from developers implementing timelocks, signature verification, and hashing in Michelson contracts.
Use the LEVEL instruction to read the current block level and compare it against a stored unlock level. The canonical pattern stores the unlock level in contract storage during origination or a setup entrypoint, then checks { PUSH nat <unlock_level>; LEVEL; COMPARE; LT; IF { PUSH string "locked"; FAILWITH } {} } at the start of any protected entrypoint. Why it matters: Timelocks are foundational for vesting contracts, atomic swaps with refund paths, and DAO execution delays. An incorrectly implemented timelock can allow premature fund movement. What to verify: Confirm the comparison operator direction (LT vs LE), ensure the unlock level cannot be overwritten after setup, and test edge cases where the block level equals the unlock level. Chainscore Labs reviews timelock logic for off-by-one errors and storage mutability risks that could bypass the lock.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.