Audit Project
POST https://shield-api.quillai.network/api/v1/projects/audit
POST https://shield-api.quillai.network/api/v1/projects/audit
You can initiate an audit by performing a GET request and passing in your userId and projectId details to the request. Depending upon the size of the project, an audit can take anywhere between 10 seconds to even a minute.
const fetchAuditDetails = async (projectId, userId, apiKey) => {
const url = `https://shield-api.quillai.network/api/v1/projects/audit`;
try {
const response = await fetch(url, {
method: 'POST',
headers: {
'x-api-key': apiKey
},
body: JSON.stringify({uploadId={uploadId}&userId=${userId}})
});
if (!response.ok) {
throw new Error(`HTTP error! Status: ${response.status}`);
}
const auditData = await response.json();
// Log the details from the response
console.log("Total Lines of Code:", auditData.totalLines);
console.log("Audited Files:", auditData.auditedFiles);
console.log("Security Score:", auditData.securityScore);
console.log("Vulnerability Count:", auditData.vulnerabilityCount);
console.log("Vulnerabilities:", auditData.vulnerabilities);
// Log the project report link
console.log("Project Report Link:", auditData.projectReportLink);
} catch (error) {
console.error("Failed to fetch audit details:", error);
}
};
// Example usage:
const projectId = 'your-project-id';
const userId = 'your-user-id';
const apiKey = 'your-api-key';
fetchAuditDetails(projectId, userId, apiKey);
{
"totalLines": 707,
"auditedFiles": 5,
"securityScore": "97.69",
"vulnerabilityCount": {
"high": 0,
"medium": 0,
"low": 2,
"informational": 0,
"optimization": 0
},
"vulnerabilities": {
"high": [],
"medium": [],
"low": [
{
"name": "Local Variables Being Shadowed",
"severity": "low",
"snippet": "function owner() public view returns (address) {\r\n return _owner;\r\n }",
"lineNumbers": [
64,
66
],
"confidence": "high",
"recommendation": "To resolve this issue, the local variable 'owner' in the 'increaseAllowance' and 'decreaseAllowance' functions should be renamed to avoid shadowing the 'owner' function of the 'Ownable' contract. This can prevent confusion and potential bugs that may arise from the overloading of the 'owner' function. For instance, the local variable 'owner' could be renamed to 'functionOwner' or something similar.",
"explanation": "The issue reported is a shadowing of the 'owner' function within the 'Ownable' contract by the 'owner' variable within the 'increaseAllowance' and 'decreaseAllowance' functions of the 'GrinchCoin' contract. In Solidity, a function can be overloaded within the same contract, but this can lead to confusion and potential bugs if not used carefully. In this case, the 'owner' function in the 'Ownable' contract is a public function that returns the owner's address, and the 'owner' variable within the 'increaseAllowance' and 'decreaseAllowance' functions of the 'GrinchCoin' contract is a local variable that shadows the 'owner' function, which is not intended.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
},
{
"name": "Local Variables Being Shadowed",
"severity": "low",
"snippet": "function owner() public view returns (address) {\r\n return _owner;\r\n }",
"lineNumbers": [
64,
66
],
"confidence": "high",
"recommendation": "To resolve this issue, the variable declaration 'address owner = _msgSender();' in the 'transfer' function should be renamed to avoid shadowing the 'owner()' function. A common convention is to use a prefix like 'msgSender' for variables that represent the message sender, which would make the intention clearer and avoid shadowing conflicts.",
"explanation": "The 'owner()' function in the 'Ownable' contract is being shadowed by a variable declaration with the same name in the 'transfer' function of the 'GrinchCoin' contract. This can lead to confusion and potential bugs when the 'owner()' function is intended to be called, but the compiler or reader interprets it as a reference to the 'owner' variable declared in the 'transfer' function. This issue is confirmed by the static analysis report which identifies the 'shadowing-local' vulnerability.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
}
],
"informational": [],
"optimization": []
},
"projectReportLink": "https://quillshield-git-dev-front-qa.vercel.app/testzip/shareablelink/819824988da830d72be8519a9d2887773b9608be27c901f01598a2a9588a199a?type=3&projectID=11"
}Query Parameters
This route takes three query parameters, 'uploadId', 'userId' and 'name'. 'uploadId' is the id of the uploaded project, and can be taken from the upload project api. UserId is helpful in mapping users of your platform to QuillShield and maintaining their separate audit history, it can be any unique Identifier (wallet address, email etc). The 'name' parameter is an optional param, which is used to name the project.
Parameter
Description
Data Type
Requirement
uploadId
Project Id created
String
Required
userId
User Identifier
String
Required
name
Project Name
String
Optional
Response Codes
Responses
Description
🟢 200
Success
🟠400
Error
🔴 401
Unauthorised
Sample Response
{
"totalLines": 707,
"auditedFiles": 5,
"securityScore": "97.69",
"vulnerabilityCount": {
"high": 0,
"medium": 0,
"low": 9,
"informational": 0,
"optimization": 0
},
"vulnerabilities": {
"high": [],
"medium": [],
"low": [
{
"name": "Local Variables Being Shadowed",
"severity": "low",
"snippet": "function owner() public view returns (address) {\r\n return _owner;\r\n }",
"lineNumbers": [
64,
66
],
"confidence": "high",
"recommendation": "To resolve this issue, the local variable 'owner' in the 'increaseAllowance' and 'decreaseAllowance' functions should be renamed to avoid shadowing the 'owner' function of the 'Ownable' contract. This can prevent confusion and potential bugs that may arise from the overloading of the 'owner' function. For instance, the local variable 'owner' could be renamed to 'functionOwner' or something similar.",
"explanation": "The issue reported is a shadowing of the 'owner' function within the 'Ownable' contract by the 'owner' variable within the 'increaseAllowance' and 'decreaseAllowance' functions of the 'GrinchCoin' contract. In Solidity, a function can be overloaded within the same contract, but this can lead to confusion and potential bugs if not used carefully. In this case, the 'owner' function in the 'Ownable' contract is a public function that returns the owner's address, and the 'owner' variable within the 'increaseAllowance' and 'decreaseAllowance' functions of the 'GrinchCoin' contract is a local variable that shadows the 'owner' function, which is not intended.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
},
{
"name": "Local Variables Being Shadowed",
"severity": "low",
"snippet": "function owner() public view returns (address) {\r\n return _owner;\r\n }",
"lineNumbers": [
64,
66
],
"confidence": "high",
"recommendation": "To resolve this issue, the variable declaration 'address owner = _msgSender();' in the 'transfer' function should be renamed to avoid shadowing the 'owner()' function. A common convention is to use a prefix like 'msgSender' for variables that represent the message sender, which would make the intention clearer and avoid shadowing conflicts.",
"explanation": "The 'owner()' function in the 'Ownable' contract is being shadowed by a variable declaration with the same name in the 'transfer' function of the 'GrinchCoin' contract. This can lead to confusion and potential bugs when the 'owner()' function is intended to be called, but the compiler or reader interprets it as a reference to the 'owner' variable declared in the 'transfer' function. This issue is confirmed by the static analysis report which identifies the 'shadowing-local' vulnerability.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
},
{
"name": "Local Variables Being Shadowed",
"severity": "low",
"snippet": "function owner() public view returns (address) {\r\n return _owner;\r\n }",
"lineNumbers": [
64,
66
],
"confidence": "high",
"recommendation": "To resolve this issue, the local variable 'owner' in the 'decreaseAllowance' and 'increaseAllowance' functions should be renamed to avoid shadowing the 'owner()' function from the 'Ownable' contract. It is a best practice to use a naming convention that clearly differentiates between state variables and local variables, such as prefixing state variables with '_' or 'this'.",
"explanation": "The warning 'shadowing-local' indicates that a variable or function within the contract has the same name as a variable or function in a parent contract, which could lead to confusion and potentially cause bugs. In this case, the 'owner()' function in the 'Ownable' contract is being shadowed by the 'owner' local variable within the 'decreaseAllowance' and 'increaseAllowance' functions. This is due to the fact that in Solidity, local variables take precedence over state variables with the same name.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
},
{
"name": "Local Variables Being Shadowed",
"severity": "low",
"snippet": "function owner() public view returns (address) {\r\n return _owner;\r\n }",
"lineNumbers": [
64,
66
],
"confidence": "high",
"recommendation": "To resolve this issue, the local variable 'owner' in the 'decreaseAllowance' function should be renamed to avoid shadowing the 'owner' function from the 'Ownable' contract. For example, the variable could be renamed to 'sender' to reflect its purpose more clearly.",
"explanation": "The issue reported is a shadowing of the 'owner' function within the 'Ownable' contract by the 'owner' variable in the 'decreaseAllowance' function of the 'GrinchCoin' contract. This means that the local variable 'owner' in 'decreaseAllowance' is hiding the 'owner' function of the 'Ownable' contract, which can lead to confusion and potential bugs when attempting to access the 'owner' function.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
},
{
"name": "Local Variables Being Shadowed",
"severity": "low",
"snippet": "function owner() public view returns (address) {\r\n return _owner;\r\n }",
"lineNumbers": [
64,
66
],
"confidence": "high",
"recommendation": "To resolve this issue, the variable in the 'approve' function should be renamed to something that does not conflict with the 'owner()' function, such as 'ownerAddress'. This will prevent the shadowing and make the code clearer and less error-prone.",
"explanation": "The function 'owner()' in the Ownable contract is being shadowed by a variable with the same name in the approve function of the GrinchCoin contract. This can lead to confusion and potentially to errors if the 'owner' variable were to be used instead of the 'owner()' function, as it would refer to the shadowed variable within the scope of the 'approve' function.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
},
{
"name": "Local Variables Being Shadowed",
"severity": "low",
"snippet": "function owner() public view returns (address) {\r\n return _owner;\r\n }",
"lineNumbers": [
64,
66
],
"confidence": "high",
"recommendation": "To resolve this issue, the parameter name 'owner' in the '_spendAllowance' function should be changed to a name that does not conflict with the function names or variable names of the 'Ownable' contract, such as 'ownerAddress'. This change will clarify the intention of the parameter and avoid any potential shadowing issues.",
"explanation": "The static analysis report indicates that there is a function 'owner()' in the 'Ownable' contract that is being shadowed by a variable with the same name in the '_spendAllowance' function of the 'GrinchCoin' contract. This is a legitimate finding, as within the '_spendAllowance' function, the parameter 'owner' has the same name as the 'owner()' function in the 'Ownable' contract. This can be potentially confusing and may lead to errors when the contract is being interacted with, as the 'owner' variable within the function will take precedence over the 'owner()' function of the contract.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
},
{
"name": "Local Variables Being Shadowed",
"severity": "low",
"snippet": "function owner() public view returns (address) {\r\n return _owner;\r\n }",
"lineNumbers": [
64,
66
],
"confidence": "high",
"recommendation": "To resolve this issue, the local variable in the 'approve' function should be renamed to avoid shadowing the 'owner' function from the Ownable contract. For example, the local 'owner' variable in the 'approve' function could be renamed to 'sender' to make it clear that it's referring to the sender of the message.",
"explanation": "The 'owner' function in the Ownable contract is being shadowed by a local variable with the same name within the 'approve' function of the GrinchCoin contract. This means that within the 'approve' function, any reference to 'owner' is resolved to the locally declared variable, which can lead to unexpected behavior and potential security risks if not used properly.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
},
{
"name": "Missing Zero Address Validation",
"severity": "low",
"snippet": "v2Pair = _v2Pair;",
"lineNumbers": [
147,
147
],
"confidence": "medium",
"recommendation": "To mitigate this issue, the setUniswapPair function should include a requirement that the '_v2Pair' parameter is not the zero address before assigning it to 'v2Pair'. This is commonly done using the 'require' statement to enforce a condition. For example: require(_v2Pair != address(0), 'setUniswapPair: v2Pair cannot be the zero address');",
"explanation": "The provided smart contract code for GrinchCoin's setUniswapPair function does not include a check to ensure that the '_v2Pair' parameter is not the zero address. The 'v2Pair' state variable is assigned the value of '_v2Pair' without any validation that the address is not the zero address (0x0000000000000000000000000000000000000000). Assigning a critical functionality address or token pair to the zero address could lead to a loss of funds or make the contract unusable.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
},
{
"name": "Missing Zero Address Validation",
"severity": "low",
"snippet": "tokenPairAddress = _tokenPairAddress;",
"lineNumbers": [
146,
146
],
"confidence": "medium",
"recommendation": "To ensure that the '_tokenPairAddress' is not the zero address, the function should include a check that the address is not equal to the zero address before assigning it to 'tokenPairAddress'.",
"explanation": "The provided smart contract code for GrinchCoin's 'setUniswapPair' function does not include a zero-address check for the '_tokenPairAddress' parameter before assigning it to the 'tokenPairAddress' state variable. This means that if the '_tokenPairAddress' passed to the function is the zero address (0x000...000), the contract will accept it as a valid Uniswap pair address, which is not a valid or intended behavior in the context of setting an actual token pair.",
"file": "GrinchCoin/src/backend/contracts/FeesHiddenV13/GrinchCoin.sol"
}
],
"informational": [],
"optimization": []
},
"projectReportLink": "https://quillshield-git-dev-front-qa.vercel.app/testzip/shareablelink/819824988da830d72be8519a9d2887773b9608be27c901f01598a2a9588a199a?type=3&projectID=11"
}Requesting Data in Markdown Formatting
If you intend on integrating onchain agents with our platform, the QuillShield API can make the process quite comfortable by providing you the data in markdown Format. To get data in a markdown format, you can simple add a 'format' parameter to the above request. Here's a more clear example:
POST https://shield-api.quillai.network/api/v1/projects/audit?format=MD
And that's it, by adding that parameter you can query data in markdown format. The request data would follow the same response schema as shown previously with an addition of the 'markdown' attribute which contains the audit report in the markdown format
The response would be structured like this
{
"totalLines": <number>,
"auditedFiles": <number>,
"markdown": <string>,
"securityScore": <string>,
"vulnerabilityCount": {
"high": <number>,
"medium": <number>,
"low": <number>,
"informational": <number>,
"optimization": <number>
},
"vulnerabilities": {
"high": [
{
"name": <string>,
"severity": <string>,
"snippet": <string>,
"lineNumbers": [<number>, <number>],
"confidence": <string>,
"recommendation": <string>,
"explanation": <string>,
"file": <string>
}
],
"medium": [
{
"name": <string>,
"severity": <string>,
"snippet": <string>,
"lineNumbers": [<number>, <number>],
"confidence": <string>,
"recommendation": <string>,
"explanation": <string>,
"file": <string>
}
],
"low": [
{
"name": <string>,
"severity": <string>,
"snippet": <string>,
"lineNumbers": [<number>, <number>],
"confidence": <string>,
"recommendation": <string>,
"explanation": <string>,
"file": <string>
}
],
"informational": [
{
"name": <string>,
"severity": <string>,
"snippet": <string>,
"lineNumbers": [<number>, <number>],
"confidence": <string>,
"recommendation": <string>,
"explanation": <string>,
"file": <string>
}
],
"optimization": [
{
"name": <string>,
"severity": <string>,
"snippet": <string>,
"lineNumbers": [<number>, <number>],
"confidence": <string>,
"recommendation": <string>,
"explanation": <string>,
"file": <string>
}
]
},
"projectReportLink": <string>
}
Last updated