← Back to Work

Engineering Case Study

Institutional DLT Risk Audit

Smart Contract Security · DLT Risk Engineering

Independent smart-contract security analysis examining implementation risks, static-analysis signals, and security controls on OpenZeppelin ERC-20 components in an institutional DLT research context.

Completed Engineering Project Public Source Security Analysis Independent Study
Source → View Audit →

Overview

This project is a public documentation repository of Slither static-analysis reports and analyst notes covering OpenZeppelin’s ERC20, ERC20Burnable, and ERC20Capped contracts.

The work demonstrates a reproducible security-analysis workflow: compile with a pinned Solidity toolchain, run Slither human-summary output, review tool signals manually, and document severity-aware findings for institutional digital-asset risk discussions.

This was an independent engineering/security analysis and does not represent an audit commissioned, sponsored, approved, reviewed, or endorsed by UBS. The repository name reflects research context, not a commercial engagement.

Engineering / Security Problem

Token contracts sit at the center of institutional DLT tokenization and custody discussions. Even widely used reference implementations require structured review so that tool output, known ERC-20 design tradeoffs, and compiler/build assumptions are not confused with exploitable vulnerabilities.

The problem this project addresses is methodological: run deterministic static analysis on concrete ERC-20 components, separate tool signals from validated findings, and communicate residual risk clearly — without claiming a full third-party audit of a production bank system.

My Role

Smart Contract Security Engineering · Independent Analysis

I personally performed the Slither static analyses, captured human-summary outputs, wrote the ERC-20 narrative report, and framed findings for institutional DLT risk discussion. The contracts under analysis are OpenZeppelin’s public ERC-20 implementations — not proprietary UBS systems and not original Solidity authored for this repository.

This case study does not claim professional auditor certification or employment/consulting work for UBS.

Analysis Scope

All contracts were sourced from OpenZeppelin Contracts. The public GitHub repository stores reports and documentation — not a Foundry/Hardhat application tree with custom business logic.

Contracts analyzed

  • ERC20.sol — core token logic
  • ERC20Burnable.sol — burn extension
  • ERC20Capped.sol — supply-cap extension

Related units reviewed in reports

  • IERC20, IERC20Metadata
  • IERC6093, Context
  • Imported error interfaces surfaced by compilation

Contract Architecture Under Review

The analysis targets the standard OpenZeppelin ERC-20 composition path rather than a custom institutional application stack.

Interfaces IERC20 · IERC20Metadata · IERC6093
Core ERC20 · Context
Extensions ERC20Burnable · ERC20Capped
Analysis artifact Slither human-summary + analyst notes (public repo)

Security Methodology

Methods actually used in the repository and reproducible locally:

  1. Scope selection of OpenZeppelin ERC-20 core and extensions
  2. Pinned toolchain: Slither v0.11.3, solc 0.8.27 via solc-select, Foundry / forge used as part of the compilation environment invoked during Slither analysis
  3. Slither human-summary static analysis per contract path
  4. Manual review of tool signals vs known ERC-20 design behavior
  5. Severity-aware documentation (no High/Medium/Low issues reported by Slither summaries)
  6. Institutional risk commentary framing — without claiming regulatory certification

Static-analysis output was reviewed and contextualized. Tool signals were not automatically treated as exploitable vulnerabilities.

Static Analysis Results

Committed Slither human-summary artifacts for ERC20Burnable and ERC20Capped, plus the ERC-20 narrative report, document the following severity counts:

0 High
0 Medium
0 Low
1 Informational

Across the Burnable/Capped summaries: no optimization findings, no assembly, and ERC-20 feature tables flag Approve Race Cond. as informational. Example Cap summary metrics from the committed report: 8 contracts in source files, 204 SLOC, 32 functions on ERC20Capped.

These counts were re-verified by re-running Slither human-summary on local OpenZeppelin ERC20Capped.sol (same 0 / 0 / 0 / 1 pattern). Absence of High/Medium/Low findings is not a proof of absolute security.

Findings

No Critical, High, Medium, or Low vulnerabilities were reported in the committed Slither summaries. The validated items below are informational / architectural observations.

ERC-20 approve race condition

Informational Validated · Known design issue
Affected component
OpenZeppelin ERC20 / Burnable / Capped analysis surface
Detection method
Slither human-summary (“Approve Race Cond.”) + analyst confirmation
Description
Standard ERC-20 approve() can be overwritten in a way that enables a classic allowance race if callers rely on raw approve transitions.
Potential impact
Token-allowance front-running in poorly designed integrator flows — not unique to this analysis target.
Recommendation
Prefer increaseAllowance() / decreaseAllowance() (or equivalent safer patterns) in integrators. Documented as recommended mitigation in the narrative report.
Resolution status
Recommended — not a custom-contract remediation in this repository (OpenZeppelin reference contracts were not forked/patched here).

Mixed Solidity pragma constraints across imports

Informational / Architectural Contextual observation
Affected component
Imported OZ units (IERC20, IERC20Metadata, IERC6093, ERC20, Context)
Detection method
Manual review of pragma ranges documented in the ERC-20 Slither narrative report
Description
Different minimum/caret pragma constraints appear across related interface and implementation files. The report notes this can increase audit complexity and build-environment sensitivity.
Potential impact
Build reproducibility / governance hygiene concerns rather than an immediate exploit class.
Recommendation
Institutional integrations should pin compiler versions and treat pragma consistency as a governance control.
Resolution status
Observed / documented — explicitly described as not an immediate security vulnerability.

Testing

The public repository does not contain a Foundry/Hardhat test suite, fuzz tests, or invariant tests. Foundry appears in the documented toolchain because Slither’s analysis workflow invoked forge/solc compilation against the OpenZeppelin sources.

Testing · Not included in repository artifacts

No fabricated test counts. Validation evidence is the committed Slither reports plus reproducible static-analysis re-runs.

Remediation

No patched Solidity forks or before/after remediation commits exist in this repository.

  • Approve race: mitigation recommended via safer allowance APIs — status Recommended
  • Pragma consistency: treated as documentation / governance observation — status Observed

Institutional DLT Risk Lens

The repository frames ERC-20 static analysis in an institutional digital-asset context (tokenization / custody discussion). Supported technical themes from the work:

  • Deterministic analysis toolchain (pinned Slither / solc versions)
  • Privilege and minting posture surfaced by Slither feature tables (“No Minting” on analyzed extensions)
  • Allowance / approval integrity as an integrator risk domain
  • Compiler and build reproducibility as an operational control

This page does not claim FINMA, MiCA, Basel, or other regulatory compliance certification.

Security Limitations

  • Independent engineering study — not commissioned by an institution
  • Limited to OpenZeppelin ERC-20 components named in the reports
  • No custom application contracts, deployment addresses, or production infrastructure review
  • Static analysis does not prove absence of vulnerabilities
  • No formal verification, economic attack simulation, or frontend/backend security assessment
  • Point-in-time analysis against the OpenZeppelin sources used during report generation

What I Personally Did

Slither static analysis Completed

Ran and archived human-summary outputs for ERC-20 / Burnable / Capped.

Finding validation Completed

Separated informational tool signals from exploitable-vulnerability claims.

Manual Solidity review notes Completed

Documented pragma consistency and known approve-race design behavior.

Security documentation Completed

Published public report markdowns and project README on GitHub.

Technology

  • Solidity (OpenZeppelin ERC-20 sources under analysis)
  • Slither v0.11.3
  • solc 0.8.27 (solc-select)
  • Foundry / forge (compile environment used by Slither)
  • Python 3.13.2
  • OpenZeppelin Contracts
  • Git / Markdown

Current Status

Completed Engineering Project · Independent Security Analysis · Public Source

Available

  • Public GitHub repository
  • Committed Slither report markdowns
  • Reproducible static-analysis workflow against OpenZeppelin sources

Scope

  • Independent engineering/security study
  • Smart-contract-level static analysis of reference ERC-20 components
  • Not an institution-commissioned audit
  • Not certification of production security
Source → View Audit →