Implement a maximum minting cap or require multi-signature approval for bulk mints.#36
Implement a maximum minting cap or require multi-signature approval for bulk mints.#36aniket866 wants to merge 3 commits intoStabilityNexus:mainfrom
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughAdds a configurable on-chain max mint cap and enforces it end-to-end: contract state/error and admin setter, factory & TNT ABIs updated to accept/expose the cap, and frontend changes to pass, display, enforce, and persist the cap during deployment and minting flows. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Frontend
participant TNTFactory
participant Blockchain
participant Decoder
participant LocalStorage
User->>Frontend: submit create form (name,symbol,revokable,imageURL,maxMintCap)
Frontend->>TNTFactory: createTNT(..., maxMintCap)
TNTFactory->>Blockchain: send tx
Blockchain-->>Frontend: txReceipt (logs)
Frontend->>Decoder: decodeEventLog(txReceipt.logs, TNTCREATED)
Decoder-->>Frontend: { tntAddress }
Frontend->>LocalStorage: saveTransaction({tntAddress, maxMintCap, txHash})
LocalStorage-->>Frontend: success/failure
Frontend-->>User: show success or error toast
sequenceDiagram
participant User
participant Frontend
participant TNTContract
participant Blockchain
User->>Frontend: request mint(recipient)
Frontend->>TNTContract: read maxMintCap(), read getAllParticipantsCount()
TNTContract-->>Frontend: maxMintCap, totalMinted
alt cap reached
Frontend-->>User: show "Cap Reached" toast / disable form
else allowed
Frontend->>TNTContract: issueToken(recipient)
TNTContract->>Blockchain: mint tx
Blockchain-->>Frontend: txConfirmed
Frontend->>Frontend: totalMinted += 1
Frontend-->>User: show success toast
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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: 1
🧹 Nitpick comments (1)
contracts/src/TNT.sol (1)
63-67: Confirm intended “max supply” semantics (lifetime minted vs. active supply).
The check uses_nextTokenId, so revokes/burns won’t free capacity. If you want a cap on circulating supply, track active supply instead and compare that inissueToken.If active-supply cap is the goal, one approach is:
- Add
uint256 public totalSupply;- Increment in
issueToken, decrement inrevokeTokenandburnToken- Check
if (maxSupply > 0 && totalSupply + 1 > maxSupply) revert MaxSupplyReached();Please confirm which behavior you want.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@contracts/src/TNT.sol` around lines 63 - 67, The current maxSupply check in issueToken uses _nextTokenId, so burned/revoked tokens do not free capacity; if you intend maxSupply to limit circulating (active) tokens instead of lifetime-minted tokens, introduce a uint256 public totalSupply, increment totalSupply in issueToken and decrement it in revokeToken and burnToken, and change the guard in issueToken to check if (maxSupply > 0 && totalSupply + 1 > maxSupply) revert MaxSupplyReached(); otherwise confirm you want lifetime-minted semantics and keep the existing _nextTokenId check.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@contracts/src/TNT.sol`:
- Around line 59-61: The setter setMaxSupply currently allows lowering maxSupply
below already minted tokens (tracked by _nextTokenId), which can block minting;
update setMaxSupply to require the new _maxSupply is at least the number of
tokens already minted (use _nextTokenId to compute minted count) and revert
otherwise, and emit a MaxSupplyChanged (or MaxSupplyUpdated) event with old and
new values for auditability; add the event declaration (e.g.,
MaxSupplyChanged(uint256 old, uint256 updated)) and use it in setMaxSupply while
preserving the onlyRole(DEFAULT_ADMIN_ROLE) guard.
---
Nitpick comments:
In `@contracts/src/TNT.sol`:
- Around line 63-67: The current maxSupply check in issueToken uses
_nextTokenId, so burned/revoked tokens do not free capacity; if you intend
maxSupply to limit circulating (active) tokens instead of lifetime-minted
tokens, introduce a uint256 public totalSupply, increment totalSupply in
issueToken and decrement it in revokeToken and burnToken, and change the guard
in issueToken to check if (maxSupply > 0 && totalSupply + 1 > maxSupply) revert
MaxSupplyReached(); otherwise confirm you want lifetime-minted semantics and
keep the existing _nextTokenId check.
Zahnentferner
left a comment
Zahnentferner
left a comment
There was a problem hiding this comment.
This PR is interesting, but corresponding changes in the frontend are needed. Could you do the frontend changes? Please add screenshots of before and after the frontend changes.
aniket866
force-pushed
the
fixing-minting-limit
branch
from
0f73fa9 to
29d6ad4
Compare
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
web/src/app/create/page.tsx (1)
167-173:⚠️ Potential issue | 🔴 CriticalCritical: Contract call will fail due to ABI/contract parameter mismatch.
This call passes 5 arguments including
BigInt(maxMintCap), but as noted in theTNTFactory.tsreview, the actualFactory.solcontract'screateTNTfunction only accepts 4 parameters. This transaction will revert with a function selector mismatch or ABI decoding error.This must be fixed in conjunction with the
TNTFactory.tsABI correction. Either:
- Remove
maxMintCapfrom the call and set it post-deployment viasetMaxSupply(), or- Update the Solidity contract to accept the parameter.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/app/create/page.tsx` around lines 167 - 173, The createTNT call is passing BigInt(maxMintCap) but Factory.sol's createTNT only takes 4 params, causing ABI mismatch; update the call site in writeContract (symbols: writeContract, createTNT, TNTFactoryAbi, factoryAddress, maxMintCap) to remove BigInt(maxMintCap) from the args array so you pass only [tokenName.trim(), tokenSymbol.trim(), revokable, cleanImageURL], then after the deployment tx completes call the factory's setMaxSupply (or the deployed TNT contract's setMaxSupply) via a separate writeContract call passing BigInt(maxMintCap); also ensure TNTFactory.ts ABI matches the 4-arg createTNT signature to keep ABI and callsite consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@web/src/app/create/page.tsx`:
- Around line 146-149: The current validation allows non-integer strings like
"1.5" which will cause BigInt(maxMintCap) to throw; update the check around
maxMintCap to ensure it is an integer string before converting to BigInt by
validating either with a regex (e.g. /^\d+$/) or
Number.isInteger(Number(maxMintCap)) and rejecting values containing a decimal
point; if validation fails call toast.error("Max Mint Cap must be a positive
integer") and return. Apply this to the same code path that currently checks
maxMintCap (the variable maxMintCap and the subsequent BigInt(maxMintCap)
conversion) so you prevent the conversion error.
In `@web/src/app/token-actions/page.tsx`:
- Line 299: The optimistic increment using setTotalMinted((prev) => prev + 1n)
can desync with on‑chain state; remove that optimistic update and instead, after
a successful issueToken transaction confirmation, call the contract/read method
getAllParticipantsCount (or the existing helper that queries _allUsers) and
setTotalMinted to the returned value (BigInt) to reflect the true on‑chain
count; ensure this fetch occurs after the transaction is mined/confirmed in the
same flow that calls issueToken so the UI always matches
getAllParticipantsCount.
- Around line 119-137: The UI is calling a non-existent contract function
maxMintCap and misinterpreting getAllParticipantsCount as total minted; update
the readContract call to read the public state variable "maxSupply" (replace
functionName: "maxMintCap" with functionName: "maxSupply") and setMintCap with
that result, and either (A) if you want to show participants rename the UI
state/labels from totalMinted to totalParticipants and keep using
getAllParticipantsCount, or (B) if you need actual minted token count add a new
public accessor in the contract (e.g., expose _nextTokenId or a totalMinted()
view) and read that new function from the UI (update the readContract
functionName and setTotalMinted accordingly). Ensure the symbols referenced are
maxSupply, getAllParticipantsCount, setMintCap, setTotalMinted (or
setTotalParticipants) and adjust UI labels to match the chosen metric.
In `@web/src/utils/contractsABI/TNT.ts`:
- Around line 35-40: Update the TNT.ts ABI to match the Solidity contract:
remove the constructor parameter named "_maxMintCap" so the constructor
parameters match the 6-arg TNT.sol constructor, rename the view/state entry
"maxMintCap" to "maxSupply" (and any corresponding function ABI entry) so
callers read the public variable correctly, and replace the error name
"MintCapReached" with "MaxSupplyReached" to match the contract's custom error;
adjust any related references in the ABI object to these exact symbols
(constructor, maxSupply, MaxSupplyReached).
- Around line 425-437: The ABI in TNT.ts uses incorrect names (maxMintCap and
MintCapReached) that don't match the Solidity contract symbols; replace
occurrences of "maxMintCap" with "maxSupply" and "MintCapReached" with
"MaxSupplyReached" in the ABI so the JSON keys for the function and custom error
match the contract (ensure the function entry name "maxSupply" and the error
entry "MaxSupplyReached" are used where currently "maxMintCap" and
"MintCapReached" appear, including at the locations around the current
maxMintCap block and the error block near lines 946-950).
In `@web/src/utils/contractsABI/TNTFactory.ts`:
- Around line 26-31: ABI and frontend disagree with the contract: TNTFactory.ts
declares a fifth parameter "maxMintCap" (uint256) while Factory.sol's createTNT
function only accepts (name, symbol, revokable, imageURL), and page.tsx
currently calls createTNT with five args; fix by either removing "maxMintCap"
from the ABI (TNTFactory.ts) and stop passing it from page.tsx (remove
BigInt(maxMintCap) and any ABI entries for maxMintCap), OR update the smart
contract createTNT signature and the TNT constructor to accept and store
maxMintCap, recompile and redeploy the contract and then update TNTFactory.ts
ABI to match the new createTNT(name,symbol,revokable,imageURL,maxMintCap)
signature so the function selector and call arguments align.
---
Outside diff comments:
In `@web/src/app/create/page.tsx`:
- Around line 167-173: The createTNT call is passing BigInt(maxMintCap) but
Factory.sol's createTNT only takes 4 params, causing ABI mismatch; update the
call site in writeContract (symbols: writeContract, createTNT, TNTFactoryAbi,
factoryAddress, maxMintCap) to remove BigInt(maxMintCap) from the args array so
you pass only [tokenName.trim(), tokenSymbol.trim(), revokable, cleanImageURL],
then after the deployment tx completes call the factory's setMaxSupply (or the
deployed TNT contract's setMaxSupply) via a separate writeContract call passing
BigInt(maxMintCap); also ensure TNTFactory.ts ABI matches the 4-arg createTNT
signature to keep ABI and callsite consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 94a1fb0f-0a75-42ea-8b7e-1f6b7ca46d2a
📒 Files selected for processing (6)
web/src/app/create/page.tsxweb/src/app/token-actions/page.tsxweb/src/utils/contractsABI/TNT.tsweb/src/utils/contractsABI/TNTFactory.tsweb/src/utils/roleManager.tsweb/tsconfig.json
|
|
||
| // read mint cap and total minted from contract | ||
| const publicClient = getPublicClient(config as any, { chainId }); | ||
| if (publicClient) { | ||
| const [cap, minted] = await Promise.all([ | ||
| publicClient.readContract({ | ||
| address: contractAddress, | ||
| abi: TNTAbi, | ||
| functionName: "maxMintCap", | ||
| }) as Promise<bigint>, | ||
| publicClient.readContract({ | ||
| address: contractAddress, | ||
| abi: TNTAbi, | ||
| functionName: "getAllParticipantsCount", | ||
| }) as Promise<bigint>, | ||
| ]); | ||
| setMintCap(cap); | ||
| setTotalMinted(minted); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if TNT.sol has totalSupply or a token counter that tracks actual minted count
echo "=== Looking for totalSupply or token counter ==="
rg -n "totalSupply|tokenId|_nextTokenId|_tokenIdCounter" -g "TNT.sol"
echo ""
echo "=== Check issueToken function to see how tokens are counted ==="
rg -n "function issueToken" -g "TNT.sol" -A 20Repository: StabilityNexus/TNT
Length of output: 3793
🏁 Script executed:
#!/bin/bash
# Check for getter functions that expose token count or supply
echo "=== Looking for public getter functions in TNT.sol ==="
rg -n "function.*\(.*\).*public.*view.*returns" contracts/src/TNT.sol | head -30
echo ""
echo "=== Check the full file to see all public read methods ==="
rg -n "public.*view" contracts/src/TNT.solRepository: StabilityNexus/TNT
Length of output: 1616
🏁 Script executed:
#!/bin/bash
# Check if maxMintCap exists in TNT.sol
echo "=== Searching for maxMintCap in TNT.sol ==="
rg -n "maxMintCap" contracts/src/TNT.sol
echo ""
echo "=== Looking for max supply related variables ==="
rg -n "maxSupply|max_.*supply|supply" contracts/src/TNT.sol | head -20Repository: StabilityNexus/TNT
Length of output: 398
Critical: maxMintCap function does not exist on the contract.
The code attempts to call publicClient.readContract() with functionName: "maxMintCap", but TNT.sol only exposes a public state variable maxSupply (line 32), not a function. This will cause a runtime error. Use the public state variable maxSupply instead.
Additionally, getAllParticipantsCount() counts unique recipients, not total tokens minted. The contract's actual token count is tracked by the private _nextTokenId variable (incremented per issuance), but this is not exposed publicly. Using getAllParticipantsCount as the "totalMinted" metric is semantically incorrect—a user receiving multiple tokens still counts as one participant. If the intent is to enforce a token supply cap, consider whether the contract should expose _nextTokenId or if the metric should track participants instead.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@web/src/app/token-actions/page.tsx` around lines 119 - 137, The UI is calling
a non-existent contract function maxMintCap and misinterpreting
getAllParticipantsCount as total minted; update the readContract call to read
the public state variable "maxSupply" (replace functionName: "maxMintCap" with
functionName: "maxSupply") and setMintCap with that result, and either (A) if
you want to show participants rename the UI state/labels from totalMinted to
totalParticipants and keep using getAllParticipantsCount, or (B) if you need
actual minted token count add a new public accessor in the contract (e.g.,
expose _nextTokenId or a totalMinted() view) and read that new function from the
UI (update the readContract functionName and setTotalMinted accordingly). Ensure
the symbols referenced are maxSupply, getAllParticipantsCount, setMintCap,
setTotalMinted (or setTotalParticipants) and adjust UI labels to match the
chosen metric.
| toast.success("Token issued successfully!"); | ||
| console.log("Issue token tx:", tx); | ||
| setIssueRecipient(""); | ||
| setTotalMinted((prev) => prev + 1n); |
There was a problem hiding this comment.
Optimistic update may desync from actual on-chain state.
The optimistic increment setTotalMinted((prev) => prev + 1n) assumes every successful issueToken call increases getAllParticipantsCount. However, if the recipient already exists in _allUsers, the on-chain count doesn't change, causing the UI to show a higher "minted" count than reality.
Consider re-fetching getAllParticipantsCount after a successful transaction, or remove the optimistic update:
Suggested fix
toast.success("Token issued successfully!");
console.log("Issue token tx:", tx);
setIssueRecipient("");
- setTotalMinted((prev) => prev + 1n);
+ // Re-fetch actual count from contract
+ const publicClient = getPublicClient(config as any, { chainId });
+ if (publicClient) {
+ const minted = await publicClient.readContract({
+ address: contractAddress,
+ abi: TNTAbi,
+ functionName: "getAllParticipantsCount",
+ }) as bigint;
+ setTotalMinted(minted);
+ }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@web/src/app/token-actions/page.tsx` at line 299, The optimistic increment
using setTotalMinted((prev) => prev + 1n) can desync with on‑chain state; remove
that optimistic update and instead, after a successful issueToken transaction
confirmation, call the contract/read method getAllParticipantsCount (or the
existing helper that queries _allUsers) and setTotalMinted to the returned value
(BigInt) to reflect the true on‑chain count; ensure this fetch occurs after the
transaction is mined/confirmed in the same flow that calls issueToken so the UI
always matches getAllParticipantsCount.
| }, | ||
| { | ||
| "name": "_maxMintCap", | ||
| "type": "uint256", | ||
| "internalType": "uint256" | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify TNT.sol constructor parameters and maxMintCap/maxSupply naming
echo "=== TNT.sol constructor ==="
rg -n "constructor\(" -g "TNT.sol" -A 15
echo ""
echo "=== Check for maxMintCap or maxSupply variable ==="
rg -n "maxMintCap|maxSupply" -g "TNT.sol"
echo ""
echo "=== Check for MintCapReached or MaxSupplyReached error ==="
rg -n "MintCapReached|MaxSupplyReached" -g "TNT.sol"Repository: StabilityNexus/TNT
Length of output: 1554
ABI contains multiple mismatches with actual TNT contract implementation.
The TNT.ts ABI file has three interconnected inconsistencies with the actual contract:
-
Constructor parameter mismatch: The ABI declares a 7-parameter constructor with
_maxMintCap, but the actual TNT.sol constructor (lines 43–57) has only 6 parameters and no_maxMintCapparameter. -
State variable naming mismatch: The ABI declares a
maxMintCap()view function, but the contract has a public state variable namedmaxSupply(line 32). -
Error naming mismatch: The ABI declares a
MintCapReachederror, but the contract definesMaxSupplyReached(line 19).
These inconsistencies will cause issues with contract verification tools, block explorers, and any frontend code attempting to read the maxMintCap or call the MintCapReached error. Update the ABI to reflect the actual contract: use maxSupply instead of maxMintCap and MaxSupplyReached instead of MintCapReached, and remove _maxMintCap from the constructor parameters.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@web/src/utils/contractsABI/TNT.ts` around lines 35 - 40, Update the TNT.ts
ABI to match the Solidity contract: remove the constructor parameter named
"_maxMintCap" so the constructor parameters match the 6-arg TNT.sol constructor,
rename the view/state entry "maxMintCap" to "maxSupply" (and any corresponding
function ABI entry) so callers read the public variable correctly, and replace
the error name "MintCapReached" with "MaxSupplyReached" to match the contract's
custom error; adjust any related references in the ABI object to these exact
symbols (constructor, maxSupply, MaxSupplyReached).
| { | ||
| "type": "function", | ||
| "name": "maxMintCap", | ||
| "inputs": [], | ||
| "outputs": [ | ||
| { | ||
| "name": "", | ||
| "type": "uint256", | ||
| "internalType": "uint256" | ||
| } | ||
| ], | ||
| "stateMutability": "view" | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check exact function/variable and error names in TNT.sol
echo "=== Public variables and functions containing 'mint' or 'supply' ==="
rg -n "public.*max|function.*max" -g "TNT.sol" -i
echo ""
echo "=== Error definitions ==="
rg -n "^error " -g "TNT.sol"Repository: StabilityNexus/TNT
Length of output: 323
🏁 Script executed:
#!/bin/bash
# Search for error definitions with broader patterns
echo "=== Search for error/Error patterns in TNT.sol ==="
rg -n "error|Error|revert|Revert" -g "TNT.sol" -i | head -30
echo ""
echo "=== Check ABI file lines 946-950 ==="
sed -n '946,950p' web/src/utils/contractsABI/TNT.tsRepository: StabilityNexus/TNT
Length of output: 1267
ABI naming mismatches will cause contract interaction failures.
The ABI declares maxMintCap and MintCapReached, but the contract uses maxSupply (line 32 in TNT.sol) and MaxSupplyReached (line 19 in TNT.sol). Frontend readContract calls will fail with "function not found" and "error not found" errors. Update the ABI to match the contract's actual function and error names.
Applies to lines 425-437 and 946-950.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@web/src/utils/contractsABI/TNT.ts` around lines 425 - 437, The ABI in TNT.ts
uses incorrect names (maxMintCap and MintCapReached) that don't match the
Solidity contract symbols; replace occurrences of "maxMintCap" with "maxSupply"
and "MintCapReached" with "MaxSupplyReached" in the ABI so the JSON keys for the
function and custom error match the contract (ensure the function entry name
"maxSupply" and the error entry "MaxSupplyReached" are used where currently
"maxMintCap" and "MintCapReached" appear, including at the locations around the
current maxMintCap block and the error block near lines 946-950).
| }, | ||
| { | ||
| "name": "maxMintCap", | ||
| "type": "uint256", | ||
| "internalType": "uint256" | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the Factory.sol createTNT function signature
echo "=== Factory.sol createTNT function signature ==="
rg -n "function createTNT" --type solidity -A 3 || rg -n "function createTNT" -g "*.sol" -A 3
echo ""
echo "=== TNT.sol constructor signature ==="
rg -n "constructor\(" -g "*.sol" -A 10 | head -30Repository: StabilityNexus/TNT
Length of output: 1251
🏁 Script executed:
# Check the frontend call in create/page.tsx
echo "=== Frontend createTNT call ==="
rg -n "createTNT\|maxMintCap" web/src/app/create/page.tsx -B 2 -A 2
echo ""
echo "=== Look for setMaxSupply or maxMintCap in TNT.sol ==="
rg -n "setMaxSupply\|maxMintCap" -g "*.sol" -A 3
echo ""
echo "=== Check full ABI structure in TNTFactory.ts ==="
head -50 web/src/utils/contractsABI/TNTFactory.tsRepository: StabilityNexus/TNT
Length of output: 1646
🏁 Script executed:
# Find files related to token creation
echo "=== Find create-related files ==="
fd -t f "create" web/src --type f | head -20
echo ""
echo "=== Search for TNTFactory usage ==="
rg -n "TNTFactory" web/src -A 2
echo ""
echo "=== Look for maxSupply in TNT contract ==="
rg -n "maxSupply\|_maxSupply\|maxMint" contracts/src/TNT.sol -B 2 -A 2
echo ""
echo "=== Check if there are any external function calls to createTNT ==="
rg -n "\.createTNT\|createTNT\(" web/srcRepository: StabilityNexus/TNT
Length of output: 3102
🏁 Script executed:
# Show the complete createTNT function from Factory.sol
rg -n "function createTNT" contracts/src/Factory.sol -A 10Repository: StabilityNexus/TNT
Length of output: 668
Critical: ABI declares maxMintCap parameter but Factory.sol does not accept it.
The createTNT function in contracts/src/Factory.sol (line 24) accepts only 4 parameters: name, symbol, revokable, and imageURL. However, the ABI in web/src/utils/contractsABI/TNTFactory.ts declares 5 parameters, adding maxMintCap as a uint256.
The frontend code in web/src/app/create/page.tsx (line 171) calls this function with 5 arguments: args: [tokenName.trim(), tokenSymbol.trim(), revokable, cleanImageURL, BigInt(maxMintCap)]. Because the function selector is computed from the ABI signature (5 parameters), it will not match the actual contract function signature (4 parameters), causing token creation transactions to fail.
Required fix: Either:
- Remove
maxMintCapfrom the ABI and handle it separately (if needed via a separate contract method), OR - Update
Factory.soland the TNT constructor to accept and handlemaxMintCapas a parameter.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@web/src/utils/contractsABI/TNTFactory.ts` around lines 26 - 31, ABI and
frontend disagree with the contract: TNTFactory.ts declares a fifth parameter
"maxMintCap" (uint256) while Factory.sol's createTNT function only accepts
(name, symbol, revokable, imageURL), and page.tsx currently calls createTNT with
five args; fix by either removing "maxMintCap" from the ABI (TNTFactory.ts) and
stop passing it from page.tsx (remove BigInt(maxMintCap) and any ABI entries for
maxMintCap), OR update the smart contract createTNT signature and the TNT
constructor to accept and store maxMintCap, recompile and redeploy the contract
and then update TNTFactory.ts ABI to match the new
createTNT(name,symbol,revokable,imageURL,maxMintCap) signature so the function
selector and call arguments align.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
2 participants
Addressed Issues:
Closes #35
See issue #35 for more details
Checklist
AI Usage Disclosure
Check one of the checkboxes below:
I have used the following AI models and tools: TODO
We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact.
@Zahnentferner
Summary by CodeRabbit