Adds Docker support for easy project setup. #79
Conversation
- Update Solidity version to ^0.8.20 - Import SafeERC20 from OpenZeppelin contracts - Implement safeTransferFrom in payInvoice function - Implement safeTransferFrom in payInvoicesBatch function - Add allowance validation before ERC20 transfers - Maintain CEI pattern for security
📝 WalkthroughWalkthroughThis pull request introduces Docker containerization for the frontend and blockchain services, upgrades the Solidity compiler from 0.8.13 to 0.8.20, integrates OpenZeppelin Contracts as a Git submodule, and refactors smart contract token operations to use SafeERC20 for enhanced safety. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.gitmodules:
- Around line 7-9: The .gitmodules entry for the OpenZeppelin submodule is not
pinned and currently tracks the default branch; update the submodule
configuration for "contracts/lib/openzeppelin-contracts" to reference a stable
release tag or branch (e.g., set branch = v5.0.0) so the submodule is
deterministic, then commit the updated .gitmodules; alternatively, after cloning
ensure the submodule is checked out to a specific commit/tag using git submodule
update --init --remote --checkout <path> and record that pinned commit in the
repo state so builds are reproducible.
In `@contracts/lib/openzeppelin-contracts`:
- Line 1: The OpenZeppelin v5.5.0 submodule raises a Solidity pragma mismatch:
update any project contracts that import or inherit OpenZeppelin modules (e.g.,
ERC1155, ERC20Votes, ERC4626, ERC721 variants, EIP712, EnumerableMap,
EnumerableSet, Strings, Votes) to use a compatible pragma (change "pragma
solidity ^0.8.20" to "pragma solidity ^0.8.24"), or alternatively verify and pin
OpenZeppelin imports to a version compatible with ^0.8.20; locate files that
import or inherit those symbols (ERC1155, ERC20Votes, ERC4626, ERC721, EIP712,
EnumerableMap, EnumerableSet, Strings, Votes) and either bump their pragma to
^0.8.24 or adjust imports to an older OZ release so the compiler pragma and
library requirements match.
🧹 Nitpick comments (2)
frontend/Dockerfile (1)
1-13: Consider adding a non-root user for better security.Running containers as root is a security risk, even in development environments. Consider adding a non-root user to follow Docker security best practices.
🔒 Proposed security improvement
FROM node:20-alpine +RUN addgroup -g 1001 -S nodejs && adduser -S nodejs -u 1001 + WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci --legacy-peer-deps COPY . . +RUN chown -R nodejs:nodejs /app + +USER nodejs + EXPOSE 5173 CMD ["npm", "run", "dev", "--", "--host", "0.0.0.0"]docker-compose.yml (1)
20-23: Pin the Foundry image tag for reproducible dev environments.Using
latestcan silently change behavior over time and break local setups. Prefer a version tag or digest.♻️ Proposed change
- image: ghcr.io/foundry-rs/foundry:latest + image: ghcr.io/foundry-rs/foundry:<pinned-tag-or-digest>
| [submodule "contracts/lib/openzeppelin-contracts"] | ||
| path = contracts/lib/openzeppelin-contracts | ||
| url = https://github.com/OpenZeppelin/openzeppelin-contracts |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the full .gitmodules file to see if commit is pinned
echo "=== Full .gitmodules content ==="
cat .gitmodules
echo -e "\n=== Checking for foundry.toml ==="
find . -name "foundry.toml" -type f | head -10
echo -e "\n=== Checking if submodule directory exists ==="
ls -la contracts/lib/openzeppelin-contracts 2>/dev/null | head -20 || echo "Submodule not found/initialized"
echo -e "\n=== Checking .git/config for submodule details ==="
grep -A 3 "openzeppelin" .git/config 2>/dev/null || echo "Not in .git/config"
echo -e "\n=== Checking .gitmodules for submodule ref ==="
cat .gitmodules | grep -A 5 "openzeppelin"Repository: StabilityNexus/Chainvoice
Length of output: 1045
🏁 Script executed:
#!/bin/bash
# Check foundry.toml content
echo "=== foundry.toml content ==="
cat contracts/foundry.toml
echo -e "\n=== Checking .git/modules for submodule details ==="
if [ -d .git/modules/contracts/lib/openzeppelin-contracts ]; then
echo "Submodule .git directory exists"
if [ -f .git/modules/contracts/lib/openzeppelin-contracts/HEAD ]; then
echo "HEAD file content:"
cat .git/modules/contracts/lib/openzeppelin-contracts/HEAD
fi
fi
echo -e "\n=== Check git ls-files for .gitmodules entry details ==="
git ls-files --stage | grep gitmodules
</parameter>Repository: StabilityNexus/Chainvoice
Length of output: 858
🏁 Script executed:
#!/bin/bash
# Find all foundry.toml files
echo "=== All foundry.toml files ==="
find . -name "foundry.toml" -type f
echo -e "\n=== Directory structure of contracts/lib ==="
ls -la contracts/lib/
echo -e "\n=== Check if lib directory exists at root ==="
ls -la lib/ 2>/dev/null || echo "No lib directory at root"
echo -e "\n=== Verify foundry.toml working directory context ==="
pwd
cat -n contracts/foundry.tomlRepository: StabilityNexus/Chainvoice
Length of output: 1074
Submodule must be pinned to a specific commit or stable release tag.
The OpenZeppelin Contracts submodule in .gitmodules is not pinned to any specific commit or release tag. Currently, it will point to the main branch, which is unsuitable for production use and breaks build reproducibility.
Update .gitmodules to include a pinned commit:
Example fix
[submodule "contracts/lib/openzeppelin-contracts"]
path = contracts/lib/openzeppelin-contracts
url = https://github.com/OpenZeppelin/openzeppelin-contracts
branch = v5.0.0
Or set a specific commit in git after initialization. Verify with a stable release tag (e.g., v5.0.0) rather than main.
The foundry remapping in contracts/foundry.toml is correctly configured as '@openzeppelin/=lib/openzeppelin-contracts/'.
🤖 Prompt for AI Agents
In @.gitmodules around lines 7 - 9, The .gitmodules entry for the OpenZeppelin
submodule is not pinned and currently tracks the default branch; update the
submodule configuration for "contracts/lib/openzeppelin-contracts" to reference
a stable release tag or branch (e.g., set branch = v5.0.0) so the submodule is
deterministic, then commit the updated .gitmodules; alternatively, after cloning
ensure the submodule is checked out to a specific commit/tag using git submodule
update --init --remote --checkout <path> and record that pinned commit in the
repo state so builds are reproducible.
| @@ -0,0 +1 @@ | |||
| Subproject commit fcbae5394ae8ad52d8e580a3477db99814b9d565 | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the OpenZeppelin Contracts submodule commit details
# First check if we have git available and can query the repository
# Try to get commit info directly via GitHub API instead of cloning
COMMIT="fcbae5394ae8ad52d8e580a3477db99814b9d565"
REPO="OpenZeppelin/openzeppelin-contracts"
# Use GitHub API to check if commit exists and get details
echo "=== Checking commit details via GitHub API ==="
curl -s "https://api.github.com/repos/${REPO}/commits/${COMMIT}" | jq '{sha: .sha, message: .commit.message, author: .commit.author.name, date: .commit.author.date}'
echo -e "\n=== Checking if commit is tagged ==="
curl -s "https://api.github.com/repos/${REPO}/commits/${COMMIT}/tags" | jq '.'
echo -e "\n=== Searching for release containing this commit ==="
curl -s "https://api.github.com/repos/${REPO}/releases" | jq '.[] | select(.tag_name | contains("v")) | {tag: .tag_name, published: .published_at, body: .body}' | head -50Repository: StabilityNexus/Chainvoice
Length of output: 50064
🌐 Web query:
OpenZeppelin Contracts v4.9 v5.0 Solidity 0.8.20 compatibility release notes
💡 Result:
Summary — key compatibility notes for OpenZeppelin Contracts v4.9 → v5.0 (Solidity 0.8.20)
- Minimum compiler: v5.0 raises the minimum Solidity compiler to 0.8.20 (v4.9 works with the 0.8.x line but v5.0 explicitly requires 0.8.20). [1][2][4]
- Language/features used in v5.0: adoption of custom errors, explicit imports, immutables, abi.encodeCall and other 0.8.20 features. [2]
- Breaking/major changes in v5.0: major-version (5.0) is NOT upgrade-safe from v4.x for storage/layout — treat as a breaking release; several public APIs and hooks were changed/removed (e.g., token hook/allowance API changes, proxy getter removals). Review the v5.0 release notes/changelog before migrating. [1][2][3]
- Backwards-compatibility guidance: OpenZeppelin follows SemVer — minor/patch preserve storage layout; major releases may break API and storage (so do not upgrade live contracts across major versions). See the docs for specifics on when and how breaking changes are introduced. [3]
- Practical migration notes: update pragma and compiler in your project to >=0.8.20, audit usages of removed/renamed functions and storage/layout differences, and consult the v5.0 changelog and upgrade guidance for the full list of breaking changes. [1][2][6]
Sources:
[1] OpenZeppelin — Introducing Contracts v4.9 (blog). (openzeppelin.com)
[2] OpenZeppelin — Introducing OpenZeppelin Contracts 5.0 (blog). (openzeppelin.com)
[3] OpenZeppelin Docs — Backwards Compatibility (Contracts v5.x). (docs.openzeppelin.com)
[4] @openzeppelin/contracts package / installation notes (shows Solidity pragma recommendation). (npm.io)
Would you like links to the full v5.0 changelog and a migration checklist?
Citations:
- 1: https://www.openzeppelin.com/news/introducing-openzeppelin-contracts-v4.9?utm_source=openai
- 2: https://www.openzeppelin.com/news/introducing-openzeppelin-contracts-5.0?utm_source=openai
- 3: https://docs.openzeppelin.com/contracts/5.x/backwards-compatibility?utm_source=openai
- 4: https://npm.io/package/%40openzeppelin/contracts?utm_source=openai
🌐 Web query:
OpenZeppelin Contracts fcbae53 commit security vulnerabilities
💡 Result:
I couldn't find any public OpenZeppelin commit with the short hash "fcbae53". Can you provide the repository (e.g., openzeppelin-contracts) or a full commit URL or longer hash? I can then look up that commit and check for any security advisories. (For reference, OpenZeppelin publishes security advisories and advisories list on GitHub and their Security Center.) [1]
References:
[1] OpenZeppelin security / advisories pages. https://github.com/OpenZeppelin/openzeppelin-contracts/security and https://contracts.openzeppelin.com/security.
Submodule uses OpenZeppelin Contracts v5.5.0, but pragma compatibility needs attention.
The commit corresponds to OpenZeppelin Contracts v5.5.0, a stable release published 2025-10-31. However, v5.5.0 updates the minimum pragma to 0.8.24 for many core contracts (ERC1155, ERC20Votes, ERC4626, ERC721 variants, EIP712, EnumerableMap, EnumerableSet, Strings, Votes, and others), while the project specifies Solidity ^0.8.20. Verify that your contracts using these OpenZeppelin libraries can compile and function with Solidity 0.8.20, or update the pragma to ^0.8.24 for full compatibility.
🤖 Prompt for AI Agents
In `@contracts/lib/openzeppelin-contracts` at line 1, The OpenZeppelin v5.5.0
submodule raises a Solidity pragma mismatch: update any project contracts that
import or inherit OpenZeppelin modules (e.g., ERC1155, ERC20Votes, ERC4626,
ERC721 variants, EIP712, EnumerableMap, EnumerableSet, Strings, Votes) to use a
compatible pragma (change "pragma solidity ^0.8.20" to "pragma solidity
^0.8.24"), or alternatively verify and pin OpenZeppelin imports to a version
compatible with ^0.8.20; locate files that import or inherit those symbols
(ERC1155, ERC20Votes, ERC4626, ERC721, EIP712, EnumerableMap, EnumerableSet,
Strings, Votes) and either bump their pragma to ^0.8.24 or adjust imports to an
older OZ release so the compiler pragma and library requirements match.
1 participant
Changes:
Usage:
docker-compose up -d --build
Access: http://localhost:5173
Summary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.