As of 3 Nov 2026, Sky has 150 audit reports by 3 security firms on Trustblock; the latest is by ChainSecurity, dated 7 Sep 2026. Those reports list no open critical findings. It also holds 1 deployed contract on 1 chain.
Record last updated . It holds audits, findings and contracts up to Nov 2026, and incidents up to Oct 2026. Trustblock does not review code.
Newest first
150 audit reports, 77 in Cantina’s series, 68 in ChainSecurity’s series
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Sky: Keel ALM Controller v1. | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky: Solana Bridge Migration | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky: Migration NTT Manager EVM | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky: Migration NTT Manager Solana | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky: LZ Solana Governance | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky: LZ Governance EVM | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky: LZ Governance Relay | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky: LZ EVM Token Bridge | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky: Solana Cross-chain Payloads for LZ Migration | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky: LZ Solana Token Bridge | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| WH LZ Migration | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Wormhole LayerZero Migration Library | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
| Sky: Star Guard | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| DSS Flappers | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Dss Flappers | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
| Solana Crosschain Governance Payload Scripts | Security firm: ChainSecurity | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · chainsecurity.com |
| Sky Wormhole NTT Migration Update | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
| Sky Governance OApp | Security firm: ChainSecurity | Date: | Scope: Files named in the report | 1 critical finding, fixed | Open · chainsecurity.com |
| Lockstake: Sky Max Price Oracle | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Lockstake Smart Contracts | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
| Star Guard | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
| stUSDS | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Lockstake | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Sky Rates Converter | Security firm: ChainSecurity | Date: | Scope: Repository at commit a36dec2 | No open critical findings | Open · chainsecurity.com |
| MakerDAO Sky smart contracts | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 2 |
| High | 0 | 0 | 6 |
| Medium | 2 | 5 | 17 |
| Low | 6 | 59 | 107 |
The `Dog` and `Clipper` contracts are designed to be components in a modular system that works together consistently to achieve certain functions. These contracts also interact with components other than `Dog` and `Clipper`, and it is expected that these components are the same from both `Dog` and `Clipper` perspectives. However, given that `vow` can set quite trivially via `file` in both contracts, without any validation, there is potential that `vow` may diverge and therefore lead to aberrant unexpected behaviors. At the same time, it was also mentioned in the code walk-through call that the `Clipper.dog` state variable which is currently `immutable` may lose that status in the future, and therefore even components like `vat` could potentially be mismatched and lead to larger issues.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
The report gives no description here.
The report gives no description here.
There are several parameters in an auction that are deeply involved in tuning it, such as `cusp`, `tail`, `chip` or `tip`. In standard auctions, these parameters(or what they represent in terms of tuning) are usually set before the auction begins and held immutable until the end so that behaviour can be more predictable and fair to users and operators. However, it appears that in `Clipper`, all of these parameters can be mutated via `Clipper.file` at any time. This would mean that potentially an auction could be in flight and a subsequent parameter change in `file` abruptly stops the auction due to a `cusp` or `tail` decrement.
There is nothing preventing the single authorized address/user from calling `deny()` on themselves. This would cause the user to lock themselves out since they will no longer be able to call any function protected by the `auth` modifier in the smart contract.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
1. [ACKNOWLEDGED] The specification indicates that the `Clipper.dog` should be authorized to call `kick`. However, the `Clipper.constructor` does not set `wards[dog] = 1`. 2. [MITIGATED] The `cut` in the `StairstepExponentialDecrease.constructor` is set to zero. This is not good, because it will lead to the `price` function returning zero. It is also not inline with the specification, which gives an example of `cut = 0.99 * RAY`.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The majority of auth-ed functions do not have any input parameter validation in place, which could lead to unexpected values being set by authenticated accounts. The following list contains a few instances of such functions, however, the list is not exhaustive as it would be too long: 1. `Clipper.setBreaker` does not check the value of `level` and therefore the circuit breaker could be set to any unsigned integer value. In the current code, this is not a problem as the `isStopped` modifier uses the less-than (<) sign. However, it could be problematic if some service listens for `SetBreaker` events and it doesn’t expect any values other than 0, 1 and 2. 2. `Clipper.file` does not check if the value of the `data` parameter corresponding to each value of what is in the right range. For example, `buf` seems to always need to be higher than 100%, while `chip` and `cusp` should always be less than 100%. `tail` should always be greater than zero. 3. `Dog.file` does not check if the value of the `data` parameter corresponding to each value of what is in the right range. For example, `chop` should probably never be 0; `Hole` and `hole` should also never be zero. 4. `LinearDecrease.file` does not check if the value of the `data` parameter corresponding to each value of what is in the right range. For example, `tau` should always be greater than 0, otherwise the `price` function will throw due to a division-by-zero error. 5. `StairstepExponentialDecrease.file` does not check if the value of the `data` parameter corresponding to each value of what is in the right range. For example, `step` should always be greater than 0, otherwise the `price` function will throw due to a division-by-zero error. Also `cut` should always be greater than 0, otherwise the `price` function will return 0.
The report gives no description here.
In `Clipper`, the auction sets the `top` price as a function of the OSM result. It is stated in the MIP45 specification that: > Note that the current OSM price is between one and two hours delayed relative to the actual market price. This means that there is a possibility that the actual market price could be sufficiently under the OSM price that the Keepers have no incentive `take`, therefore leading to incomplete auctions that `redo`. Every `redo` incentivizes callers with `tip` and `chip` which is funded from `vat`, thereby draining it slowly. Auctions which are incomplete for longer amounts of time run a higher risk of accumulating bad debt. Combined, they may cause a persistent overall value loss. The potential loss is scaled by the length of the OSM delay, since this plausible event is bounded by it. This issue was foreshadowed by [MIP45c21](https://forum.makerdao.com/t/mip45-liquidations-2-0-liq-2-0-liquidation-system-redesign/6352#MIP45c21) and [MIP45c23](https://forum.makerdao.com/t/mip45-liquidations-2-0-liq-2-0-liquidation-system-redesign/6352#MIP45c23) of the specification, and can be thought of as similar but not the same due to the focus on the oracle delay.
The report gives no description here.
The report gives no description here.
The report gives no description here.
Smart contracts will often have `owner` variables to designate the person with special privileges to make modifications to the smart contract. In these contracts we have a homemade authentication system that guards key functions such as `file`, `cage`, `yank` or `setBreaker`. Whilst it is understood these contracts are designed with a multilateral governance system in mind for the privileged role, it is important to note the potential impact.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The purpose of the `tip` state variable is to incentivize keepers to call `bark` such that they would be reimbursed for the gas fee. However, since this is a flat fee, it may not cover the gas costs when the network is highly congested and the gas prices are high.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
Every Solidity file scoped specifies in the header a version number of the format `pragma solidity >=0.6.11`. The greater-or-equal (`>=`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version _and above_, hence the term "unlocked".
The report gives no description here.
| Address | Chain | Source code |
|---|---|---|
| 0xdc03…384f0xdc035d45d973e3ec169d2276ddab16f1e407384f | Chain: Ethereum | Source code: Verified source |
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="sky"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us