Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
106 changes: 106 additions & 0 deletions client/library/library/audits/daylight-1.html
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
<page
clientName="Daylight"
reportDate="August 4, 2025"
auditTitle="Daylight A-1"
auditVersion="1.0.0"
repoUrl="https://github.com/daylight-energy/daylight-protocol-contracts"
repoCommitHash="c69f56bba7b2228ee80e0daaf06497b1c8b2c085"
repoCommitHashFinal="dad43d5efeb42d248c2fc542838bdbc080b61eb0"
layout="/library/audits/_layout.html"
passwordEncrypt="env:PAGE_PASS_DAYLIGHT_1"
>

<content-for name="schedule">
The security audit was performed by the Macro security team from June 27, 2025 to July 11, 2025.
</content-for>

<content-for name="spec">
<ul>
<li>Discussions on Slack with the {{page.clientName}} team.</li>
<li>Technical documentation provided by {{page.clientName}} team.</li>
</ul>

<h2 id="tmaar">Trust Model, Assumptions, and Accepted Risks (TMAAR)</h2>
<template type="audit-markdown">
### **Owner (Protocol Owner)**

Highly trusted. This is the entity that deployed and has administrative control over the core contracts, currently a single owner address via `Owned` contract.

**Capabilities:**

- State Management (`DaylightState`): Can update the `cummulativeUsageRoot`, which represents the authenticated stream of all energy usage data.
- Asset & Data Configuration (`DaylightDevices`, `DaylightMeters`, `UtilityVerifier`, `FlexibleCapacityChallenger`): Can update the manifests that define the expected data structures from off-chain services (Texture, Arcadia).
- Tokenomics (`DayToken`, `TokenRebates`, `ClaimPool`): Can manage minters/burners for `DayToken`, set rebate rates and token prices, apply penalties, and manage the `ClaimPool`.
- Oracle Management (`RegionalValueIndex`): Can add or remove trusted oracles that provide regional energy value data. Initially, the owner will also be the oracle.
- Challenge Parameters (`FlexibleCapacityChallenger`): Can configure the parameters used for flexible capacity challenges and issue them.
- Staking (`RegionalStaking`): Can disburse rewards for specific regions.

**Trust Assumptions:**

- Trusted to act in the best interest of the protocol.
- Trusted to provide valid and correct data for state updates and to configure all parameters fairly and securely.
- A compromised or malicious owner could disrupt the protocol by publishing invalid data, setting unfair parameters, or abusing administrative and economic functions. Daylight intends to decentralize the owner entity in future upgrades as the protocol matures.

### **Oracle (Regional Value Provider)**

Trusted. These are external accounts authorized by the Protocol Owner to provide regional energy value data to the `RegionalValueIndex`. During the protocol's initial phase, the protocol owner will act as the initial oracle. Therefore, the same trust assumptions as the Protocol Owner entity itself.

- Oracles can submit the latest energy value for a specific region.
- Oracles are trusted to provide accurate and timely data.
- Malicious or faulty oracles could submit incorrect values, leading to unfair reward distribution.

### **Off-Chain Services & APIs**

These are highly trusted external dependencies. Includes the Opacity Network (for BLS signatures) and data providers Texture and Arcadia.

### **Opacity Network (BLS Oracle)**

- Provides cryptographic attestations (BLS signatures) for data coming from services like Texture.
- The Opacity network is trusted to be secure and to only sign valid data. Its underlying cryptography is assumed to be sound.
- A vulnerability in the Opacity network could lead to unauthorized on-chain actions, such as fraudulent device minting.
- Signature validity, malleability, and replayability are entrusted to the Opacity BLS registry contract.

### **Texture & Arcadia (Off-Chain Data Providers)**

- Act as the source of truth for physical device data (identity, location, capacity) and utility usage data.
- These services are trusted to provide accurate, timely, and non-malicious data.
- Their APIs are assumed to be stable and available.
- The protocol's integrity is fundamentally reliant on these data sources. Downtime, inaccuracies, or malicious data from these services could disrupt the system, leading to incorrect reward calculations or failed challenges.
- zkTLS proofs (via Opacity) help ensure data integrity from the correct API endpoints, mitigating man-in-the-middle attacks.
- On-chain checks prevent and reject invalid data (e.g., data from the future).

### **Smart Contracts Assumptions**

- The protocol relies on third-party libraries (`Solmate`, `OpenZeppelin`), which are trusted to be secure and well-audited.
- Minor precision errors in on-chain calculations could lead to small losses of earnings for users.
</template>
</content-for>

<content-for name="source-code">

<p>Specifically, we audited the following contracts within the repository:</p>

<template type="file-hashes">
f28ea34f254fa972d0dedd03ba3f0792716cda1105aa19dcc254a50ae03abe9a ./src/assets/DaylightDevices.sol
f955778a3392d60fbad3173444ab9a89cc698e6a16dca9ccaffb7ae0978ea4fe ./src/assets/DaylightHosts.sol
630b93e9f6d46bf515c1e03b78925d890299185f9c8e42988df3e128f52cc957 ./src/assets/DaylightMeters.sol
541611db752aacd31c364bebe422542757b29552fb5cd261cbdb0c2ca38f209f ./src/DaylightState.sol
095fdeea9172b5bc93ad429ebc672493590f97acd3ce21b098303b40e59a7301 ./src/DayToken.sol
425ef01b9696816038d2161f8c2d6f6f71ee252a5dc8f4f306b301fdf76e510b ./src/interfaces/IDaylightDevices.sol
2369a1319cb164d239a92813eefe7b7b4347d8a330cceaeb3ce65b05de68118c ./src/interfaces/IDaylightHosts.sol
35592123d4299bc6b12e4010e06407ab3ff15b1abca97e2aad35c79dbd355732 ./src/interfaces/IDaylightMeters.sol
17ff0df85d27d7847631a24ce57086fdda1d6028cccbca68661442a6ee673c30 ./src/interfaces/IDaylightState.sol
89b7ea897db8749fd58ae32fb090e71f43062f98d085498b05085d47d0393862 ./src/interfaces/IERC20.sol
0fd703c2327bcd9dcfa5f6fa942dccda7d72995f6757bf89016af7d0598674d8 ./src/interfaces/IERC721.sol
c3c84e2b85f7e88e31bb5302f9903f7c31fb845e90c80dc88151e7dd497de6ed ./src/interfaces/IRegionalStaking.sol
8e2f62bd2b2cd6b17cf77f5861c3a32f6dba4f7ea02cf5fba89e99f21a966715 ./src/interfaces/IRegionalValueIndex.sol
a455009da4c5cdce9d063a726652591ef21580d24612919ca3b06a6e8df65f46 ./src/issuance/ClaimPool.sol
e2e5ce3540eca4bdc9f1d66700c0b0a0ccc367b4702979cbc0d7dc6aac291a60 ./src/issuance/FlexibleCapacityChallenger.sol
495390fe058c9b37581ddb5f2c3ab801e9fec189b58dc713b4fe8e9d60a49409 ./src/issuance/RegionalStaking.sol
a99b37af0d7208b2ffcdf9a13f1532e175c9ffc93a227c6362f2e522ffd582a8 ./src/issuance/RegionalValueIndex.sol
acf38087d526f9e528cb23e8dcaae82ce53ed7de618758f1589594926c49dd80 ./src/issuance/TokenRebates.sol
d2eb41f573b9f8b867de1a5f37dcccce2fca89b685963352780e28f6db5bc261 ./src/issuance/UtilityVerifier.sol
</template>

</content-for>

86 changes: 86 additions & 0 deletions client/library/library/audits/towns-10.html
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
<page
clientName="towns"
reportDate="July 25, 2025"
auditTitle="Towns A-10"
auditVersion="1.0.0"
repoUrl="https://github.com/towns-protocol/towns"
repoCommitHash="5356aa3d56ee92c078be75b2762d348428807957"
layout="/library/audits/_layout.html"
passwordEncrypt="env:PAGE_PASS_TOWNS_10"
>

<content-for name="schedule">
The security audit was performed by the Macro security team from June 24, 2025 to June 26, 2025.
</content-for>

<content-for name="spec">
<ul>
<li>Discussions on Slack with the HNT team.</li>
</ul>

<h2 id="tmaar">Trust Model, Assumptions, and Accepted Risks (TMAAR)</h2>
<template type="audit-markdown">
### **End User**

Considered untrusted and potentially malicious. The system is designed defensively against potential malicious actors. These can be Space’s members executing a swap through their Space or EOA executing swaps directly through the Router.

- The user is responsible for the approvals they sign, and the parameter input amounts are correctly passed to the swap functions.
- Address inputs (`router`, `approvedTarget`, and `recipient`) are validated, and execution flow is strictly controlled.
- Slippage is validated to ensure the result of the swap yields the expected amounts, despite being selected by the user.
- Poster fee configuration is bounded to the user signature.

### **Protocol Governance**

Highly trusted. The protocol owner entity that manages the core protocol rules through the PlatformRequirements contract. It is trusted to:

- Only add legitimate, non-malicious, and correctly functioning DEX router contracts to the whitelist.
- Configure reasonable protocol swap fees.
- Ensure the spaceFactory and feeRecipient addresses are correct and secure.

### **Space Owner**

Trusted within the scope of their own space. A Space Owner configures fee parameters (`posterFeeBps`, `forwardPosterFee`) only for swaps initiated through their space's `SwapFacet`.

- They are trusted to set fee configurations, but are limited to the hardcoded constant `MAX_FEE_BPS` (2% fee).
- Their actions cannot affect other spaces or the `SwapRouter` behavior.

### **Whitelisted Routers**

Highly trusted. The security model of the `SwapRouter` relies on the integrity of the external contracts on the router whitelist. These routers are trusted to:

- The router is trusted to execute swaps at a fair market rate. The slippage check is a user-defined safety net, not a guarantee of the best possible price.
- The router is trusted not to execute malicious code within the `swapData` call. While approvals and balances are cleared after the swap, the system trusts the router not to misuse them during the transaction itself.
- The internal `nonReentrant` guard prevents direct re-entry but does not control the router's interactions with the external contracts.
- Reliably return any unused input tokens to the `SwapRouter` after the swap.

### **Permit2 Contract**

Trusted infrastructure. The `SwapRouter` relies on the canonical `PERMIT2` contract at its hardcoded address ([0x000000000022D473030F116dDEE9F6B43aC78BA3](https://basescan.org/address/0x000000000022D473030F116dDEE9F6B43aC78BA3)).

- It is trusted to be secure and to correctly implement the signature verification and token transfer logic as specified by Uniswap. Any vulnerability in `PERMIT2` would be directly inherited.

### **Space Factory & Points Contracts**

Trusted core infrastructure. The `SwapRouter` and `SwapFacet` trust these contracts to perform their functions correctly and non-maliciously.

- `Architect` is trusted to accurately identify which callers are valid Spaces.
- `TownsPoints` is trusted to implement a secure and economically sound points calculation and minting system.
- `SpaceFactory` is trusted to get a valid and secure `SwapRouter` address implementation.
</template>
</content-for>

<content-for name="source-code">

<p>Specifically, we audited the following contracts within <i>packages/contracts/</i> repository directory:</p>

<template type="file-hashes">
2b9f0668b730a046798e9d340fee68446c20b0fa2f035ba29a8cab7d6a3f4c70 src/router/SwapRouter.sol
9225a3a7426187386602c391f55c2e8c05c4d0e85e3f9eddde3a50c5893936dc src/router/SwapRouterStorage.sol
a76ceb0a78460dc6b2723997e8761fd09daa3f2421a9634c4759dab1724df6a0 src/spaces/facets/swap/SwapFacet.sol
57c64fecba1e9882c7dabb174fc838c6148e97bb57e2bafcf8c1d46a3e999211 src/spaces/facets/swap/SwapFacetStorage.sol
b057e532074c111acce79c3867fa3eb0cec2091cace33e13f632399950710b20 src/spaces/facets/membership/MembershipStorage.sol
fe04f7f327a67c071b21b878f0ed39ef93d97bf384f260102ddb5122c1586fd4 src/spaces/facets/points/PointsBase.sol
</template>

</content-for>

2 changes: 1 addition & 1 deletion content/collections/private