fix: do persist credentials so it can update the github repo #1099
Conversation
WalkthroughUpdated two GitHub Actions workflows to push commits to the active branch (BRANCH = github.ref_name) and removed an explicit checkout credential override; added numerous additive entries across multiple Changes
Sequence Diagram(s)sequenceDiagram
participant GH as GitHub Actions
participant Runner as Workflow Runner
participant Git as git
participant Repo as Git Remote
rect rgb(235,245,255)
note right of GH: Commit & push step (updated)
GH->>Runner: set env BRANCH = github.ref_name
Runner->>Git: git add -A
Runner->>Git: git commit -m "chore: ..."
Runner->>Git: git push origin $BRANCH
end
alt push succeeds
Repo-->>Runner: push OK
else push fails
Repo-->>Runner: error
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
.github/workflows/generateAuxLists.yml (2)
33-52: Fix no-change detection and step conditions; current logic will always try to commit/push and can failThe condition
contains(steps.git-check.outputs, 'no_changes')is incorrect:steps.<id>.outputsis a map, not a string/array. As written, these steps will run even when there are no changes, causinggit committo fail on clean trees. Also set theno_changesoutput explicitly in both branches for robustness.Apply this diff:
- name: Check for changes id: git-check run: | - git add src/public/ - git status --porcelain | grep "src/public/.*\.json$" || echo "no_changes=true" >> $GITHUB_OUTPUT + git add src/public/ + if git status --porcelain | grep -qE "src/public/.*\.json$"; then + echo "no_changes=false" >> "$GITHUB_OUTPUT" + else + echo "no_changes=true" >> "$GITHUB_OUTPUT" + fi - name: Configure Git - if: ${{ !contains(steps.git-check.outputs, 'no_changes') }} + if: ${{ steps.git-check.outputs.no_changes != 'true' }} run: | git config --local user.email "github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" - name: Commit and push changes - if: ${{ !contains(steps.git-check.outputs, 'no_changes') }} + if: ${{ steps.git-check.outputs.no_changes != 'true' }} env: BRANCH: ${{ github.ref_name }} run: | git commit -m "chore: automated auxiliary lists generation" + git pull --rebase origin "$BRANCH" git push origin $BRANCH
10-14: Grant write permissions to GITHUB_TOKEN for pushesIf the repository/org default is read-only GITHUB_TOKEN (common since GitHub’s tightened defaults), pushes will fail even with persisted credentials. Explicitly grant contents: write at job level.
Apply this diff:
generate: name: Generate auxiliary token lists runs-on: ubuntu-latest + permissions: + contents: write
🧹 Nitpick comments (2)
.github/workflows/generateAuxLists.yml (2)
16-18: Be explicit about persisting credentials in checkout (optional, for clarity)actions/checkout defaults to persisting credentials, but making it explicit documents intent and protects against future defaults/overrides.
Apply this diff:
- name: Checkout code uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0 + with: + persist-credentials: true
10-14: Avoid races from overlapping scheduled runs (optional)Two daily runs close together could both generate and attempt to push. Add a concurrency group to serialize executions.
Apply this diff:
generate: name: Generate auxiliary token lists runs-on: ubuntu-latest + concurrency: + group: generate-aux-lists + cancel-in-progress: true
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
.github/workflows/generateAuxLists.yml(1 hunks).github/workflows/updatePermitInfo.yml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/updatePermitInfo.yml
🔇 Additional comments (1)
.github/workflows/generateAuxLists.yml (1)
45-52: LGTM on branch-aware push and clearer commit messageUsing BRANCH from github.ref_name and pushing to origin $BRANCH avoids cross-branch pushes on non-main runs and improves the commit provenance. Commit message is also more descriptive.
alfetopito
force-pushed
the
fix/permitinfo-workflow
branch
from
d739375 to
412e737
Compare
| with: | ||
| persist-credentials: false |
| env: | ||
| BRANCH: ${{ github.ref_name }} | ||
| run: | | ||
| git commit -m "chore: automated permit info update" | ||
| git push origin main | ||
| git push origin $BRANCH |
There was a problem hiding this comment.
Change just to make sure we can test it from the PR
There was a problem hiding this comment.
The result of running the workflow https://github.com/cowprotocol/token-lists/actions/runs/17244405753
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
src/public/PermitInfo.137.json (1)
815-818: Add “Ankr Staked MATIC” entry — minor naming nitpick.Consider aligning the name with common branding to reduce UX ambiguity (e.g., “Ankr Staked MATIC (ankrMATIC)”). If you prefer consistency with existing lists that already use this exact string elsewhere, ignore this.
src/public/PermitInfo.1.json (2)
6908-6911: Confirm “MicroStrategy xStock” semantics and naming consistency.There’s already “Backed MicroStrategy Inc” elsewhere in this file; please confirm this new “xStock” instrument is a distinct wrapper/issuer and that the “xStock” suffix follows your naming guidelines used for similar entries (e.g., “NVIDIA xStock”, “Circle xStock”).
2689-2691: Disambiguate “XBO” for clarity (optional)I’ve confirmed that the ticker “XBO” only appears once in the entire PermitInfo map (src/public/PermitInfo.1.json, line 2690), so there are no existing name collisions. However, to prevent future confusion—especially as new assets are added—it may be helpful to include an issuer or project identifier (for example, “ProjectX – XBO” or “IssuerCorp XBO”). If you’d rather keep “XBO” as-is, that’s fine given there’s currently no duplicate.
• Location to review: src/public/PermitInfo.1.json (line 2690)
• Suggestion: consider renaming to a more descriptive identifier, though it’s not strictly required.src/public/PermitInfo.8453.json (1)
5398-5400: Whitespace nit in token name."MUTE SWAP by Virtuals" has a double space before "by". If this name isn’t intentionally mirroring an on-chain exact name, consider normalizing to a single space.
- "name": "MUTE SWAP by Virtuals" + "name": "MUTE SWAP by Virtuals"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (7)
.github/workflows/updatePermitInfo.yml(1 hunks)src/public/PermitInfo.1.json(4 hunks)src/public/PermitInfo.137.json(2 hunks)src/public/PermitInfo.42161.json(1 hunks)src/public/PermitInfo.43114.json(3 hunks)src/public/PermitInfo.56.json(22 hunks)src/public/PermitInfo.8453.json(17 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/updatePermitInfo.yml
🔇 Additional comments (11)
src/public/PermitInfo.42161.json (1)
4484-4487: Good addition; ordering and schema look consistent.The new mapping for 0x8d010b… as unsupported “Polkadot Token (Relay Chain)” is correctly placed and comma-terminated; address casing matches the surrounding entries and the insertion keeps the ascending key order.
src/public/PermitInfo.137.json (1)
1991-1994: Cross-file consistency verified & JSON validation passed
- JSON in src/public/PermitInfo.137.json and src/public/PermitInfo.42161.json is valid.
- The two new addresses on chain 137 (0x0e9b89…dd58 and 0x72a5a5…3f1) appear only in PermitInfo.137.json.
- The Polkadot‐Relay‐Chain address (0x8d010b…90b8) exists in multiple PermitInfo.* files as intended, and in every occurrence its
type(“unsupported”) andname(“Polkadot Token (Relay Chain)”) are identical.No further action required.
src/public/PermitInfo.1.json (2)
5996-5999: Good call marking Polkadot (Relay Chain) as unsupported.This matches how non-EVM/native representations are tracked elsewhere in the repo. Thanks for keeping the naming consistent across chains.
962-966: PermitInfo Entry Verified for Formatting; On-Chain Metadata Verification NeededThe newly added Ninja Squad Token entry in
src/public/PermitInfo.1.jsonhas been confirmed present and correctly formatted:
- Address
0x70bef3bb2f001da2fddb207dae696cd9faff3f5dis included and uses lowercase hex with 40 nibbles.- The JSON shape for an EIP-2612 permit entry matches the existing conventions.
Next steps before merging:
- Manually confirm that the contract at 0x70bef3bb2f001da2fddb207dae696cd9faff3f5d implements a standard EIP-2612 permit.
- Verify that the EIP-712 domain separator and token name in your metadata align exactly with the on-chain values (for example, by retrieving the domain separator via a web3 call or inspecting the contract ABI on Etherscan).
No code changes are needed at this time—once metadata is cross-checked against the deployed contract, this entry can be safely merged.
src/public/PermitInfo.43114.json (3)
697-701: Unique “Stable Coin” entry confirmed; consider a more specific display name.A grep across all
src/public/PermitInfo.*.jsonfiles found only one occurrence of
"name": "Stable Coin"atsrc/public/PermitInfo.43114.json:700. Renaming this single entry poses minimal risk.• Suggestion: include the issuer or brand for clarity, e.g.:
"Stable Coin by <Issuer>"
662-666: MOANI JSON entry is correct; please verify on-chain EIP-2612 support on AVAX.I’ve confirmed via
jqthat the new entry insrc/public/PermitInfo.43114.jsonreads:
- type: eip-2612
- version: 1
- name: MOANI
That aligns with our naming and versioning conventions. Before merging, please double-check that the MOANI token contract at address
0xeec951bfdeb358371a19512c6c33cdd840d47db0on Avalanche implements the full EIP-2612 interface:
- Exposes
DOMAIN_SEPARATOR()matching the standard- Tracks
nonces(address)for permit replay protection- Implements the
permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)function signatureYou can verify this by inspecting the contract’s ABI on Avalanche Explorer or by querying with ethers.js/hardhat:
const token = new ethers.Contract( '0xeec951bfdeb358371a19512c6c33cdd840d47db0', ['function DOMAIN_SEPARATOR() view returns (bytes32)', 'function nonces(address) view returns (uint256)', 'function permit(address,address,uint256,uint256,uint8,bytes32,bytes32)'], provider );
- If all calls succeed and match EIP-2612 behavior, you’re clear to approve.
- If any of these symbols are missing or behave unexpectedly, update the entry or remove EIP-2612 support until it’s upstreamed.
1454-1457: Verify downstream Unicode handling for “EURØP”
JSON parsing confirms the value is correctly stored and read as UTF-8. However, please ensure that all consumers of this “name” field can safely handle the “Ø” character:• Slug generation: verify your slugifier (e.g., any
slugify,kebabCase, or custom routines) preserves or safely transliterates “Ø”
• CSV exports: confirm your CSV writer encodes non-ASCII characters correctly and that spreadsheets/processes consuming the CSV accept UTF-8
• Commit hooks or message generators: ensure any scripts that include this name in Git commit messages or changelogs don’t strip or mis-encode the character
• Dashboards and UIs: test that your frontend and charting/dashboard libraries render “Ø” without fallback glyphs or encoding errorsIf you identify any limitations, consider adding an ASCII-only alias (for example,
"alias": "EUROP") alongside the existing field to maintain compatibility.src/public/PermitInfo.8453.json (2)
3081-3084: Action Required: Re-run validation with RPC and confirm entriesThe validation script failed due to an unset
BASE_RPC_URL, so we couldn’t verify on-chain bytecode or check for duplicates. Please:
- Export your Base mainnet RPC endpoint:
export BASE_RPC_URL="https://your-base-node.example.org"- Re-run the provided script against
src/public/PermitInfo.8453.jsonto:
- Ensure no duplicate keys exist in the JSON file.
- Confirm each “unsupported” address has non-empty bytecode on Base:
- 0x33e7f871ce502ec77a0d96fdcd02c9219f95e944
- 0x3a38dde9824e18cc4c0a147824f95bf5d608f0b3
- 0x56f8ad6112c2db9f9848243531b277ce1c3be30c
- 0x6557207175c770cb441ae9a476e67586b0737773
- 0x885a590198e5f0947f4c92db815cf2a2147980b8
- 0x8d010bf9c26881788b4e6bf5fd1bdc358c8f90b8
- 0x931ef8053e997b1bab68d1e900a061305c0ff4fb
- 0xb55fcd62ed44253c45735bde6703c44100935747
- 0xc2d09cf86b9ff43cb29ef8ddca57a4eb4410d5f3
- 0xcaf75598b8b9a6e645b60d882845d361f549f5ec
- 0xd5c3a723e63a0ecab81081c26c6a3c4b2634bf85
- 0xf4d97f2da56e8c3098f3a8d538db630a2606a024
- 0xfca9fc2cb2dde04732ad07e4bb73db8cc8bfed1d
Please share the script’s output so we can confirm there are no empty contracts or unintended duplicates.
517-521: ACTION REQUIRED: Verify onchain EIP-2612 permit support for new contractsThe previous sanity-check script aborted because
BASE_RPC_URLwas unset. Before merging, please:
Export a valid Base mainnet RPC endpoint, for example:
export BASE_RPC_URL="https://mainnet.base.org"Re-run the provided script to check each address for:
- Presence of runtime bytecode on Base (chainId 8453)
- Inclusion of the permit() 4-byte selector (
0xd505accf) in the bytecodeAddresses to verify:
- 0x3977fc913db86b01a257232c568317798b903b07 (Cody)
- 0x9a9de07629ef283c2d700efd3958f59b7d528453 (MOTO)
- 0xc729777d0470f30612b1564fd96e8dd26f5814e3 (Sapien)
Once you have confirmed bytecode presence and permit support, we can proceed with merging.
src/public/PermitInfo.56.json (2)
777-780: Add default BSC RPC and re-run bytecode existence checkTo unblock verification, here’s an updated script that falls back to a public BSC RPC if
BSC_RPC_URLisn’t defined. Please run it, confirm that all addresses return non-empty bytecode, and then manually verify that the on-chainname()matches your JSON entries.#!/bin/bash set -euo pipefail file="src/public/PermitInfo.56.json" # Use provided RPC or default to a public BSC endpoint : "${BSC_RPC_URL:=https://bsc-dataseed.binance.org/}" # List of newly added "unsupported" token addresses readarray -t addrs <<'EOF' 0x0f0df6cb17ee5e883eddfef9153fc6036bdb4e37 0x2c3a8ee94ddd97244a93bc48298f97d2c412f7db 0x4fa7c69a7b69f8bc48233024d546bc299d6b03bf 0x52242cbab41e290e9e17ccc50cc437bb60020a9d 0x5d3a12c42e5372b2cc3264ab3cdcf660a1555238 0x795d2710e383f33fbebe980a155b29757b6703f3 0x85e92213fca84aa99adbac5049d8426984d64444 0x94e00656e69cc6c8d49155412dc9c58d8d950561 0x9988d876d7500646534e2d91b382b1ac4c5a4444 0x9cfae8067322394e34e6b734c4a3f72acc4a7fe5 0xa67c48f86fc6d0176dca38883ca8153c76a532c7 0xbcba33bf0b3cd8d626b7a3732a3ee18a0af51bd0 0xe747e54783ba3f77a8e5251a3cba19ebe9c0e197 0xeb2b7d5691878627eff20492ca7c9a71228d931d 0xfa35e2250e376c23955247383dc32c79082e7fcc 0xffffff9936bd58a008855b0812b44d2c8dffe2aa EOF for a in "${addrs[@]}"; do code=$(curl -s -X POST "$BSC_RPC_URL" -H 'Content-Type: application/json' \ --data "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_getCode\",\"params\":[\"$a\",\"latest\"]}" \ | jq -r .result) if [[ "$code" == "0x" ]]; then echo "ERROR: $a has no runtime bytecode on BSC." else echo "OK: $a exists on BSC." fi done• After confirming no
ERRORlines, please also query each address’name()viaeth_call(or your preferred tool) and ensure it matches the"name"field insrc/public/PermitInfo.56.json.
• Apply the same check to the other slices (lines 977–980, 1237–1240, etc.) referenced in the original comment.
277-281: Action Required: Configure BSC_RPC_URL and Re-run Permit Support CheckThe static‐analysis script couldn’t execute because the BSC_RPC_URL environment variable wasn’t set. To complete verification:
- Set BSC_RPC_URL to a valid BSC mainnet RPC endpoint (for example, https://bsc-dataseed.binance.org/).
- Re-run the permit selector detection script against the five new EIP-2612 entries (addresses in src/public/PermitInfo.56.json at lines 277–281, 282–286, 407–411, 502–506, and 542–546).
- Confirm each contract’s bytecode includes the
permit()selector (0xd505accf) and that the on-chain domain separator version matches"1".- Share the script output or manually verify and document the results.
| "type": "unsupported", | ||
| "name": "Polkadot Token (Relay Chain)" | ||
| }, |
There was a problem hiding this comment.
Likely wrong-chain address: duplicate Polkadot token on BSC file.
The address 0x8d010bf9… for "Polkadot Token (Relay Chain)" appears to be a Base-network token that was also added in the 8453 map. In this BSC (56) file, Polkadot on BSC is already represented at Line 1462-1464 by 0x7083609f… ("Polkadot Token"). Adding the Base address here looks incorrect and could break consumers.
Recommend removing this entry from the BSC file.
- "0x8d010bf9c26881788b4e6bf5fd1bdc358c8f90b8": {
- "type": "unsupported",
- "name": "Polkadot Token (Relay Chain)"
- },📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "type": "unsupported", | |
| "name": "Polkadot Token (Relay Chain)" | |
| }, | |
| // In src/public/PermitInfo.56.json, remove the entire entry for the duplicate Polkadot Relay Chain token: | |
| - "0x8d010bf9c26881788b4e6bf5fd1bdc358c8f90b8": { | |
| - "type": "unsupported", | |
| - "name": "Polkadot Token (Relay Chain)" | |
| - }, |
🤖 Prompt for AI Agents
In src/public/PermitInfo.56.json around lines 1682-1684, remove the entire JSON
entry for the "Polkadot Token (Relay Chain)" (address 0x8d01...) because it's a
Base-network token mistakenly duplicated in the BSC file; delete the object and
ensure surrounding commas are adjusted so the file remains valid JSON, and do
not modify the correct BSC Polkadot entry at lines ~1462-1464.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
src/public/PermitInfo.137.json (1)
1991-1994: Suffix “(PoS)” for finance.vote Token
To maintain consistency with other bridged assets in PermitInfo.137.json (chain ID 137 → Polygon PoS), append “(PoS)” to the token’s name.• File: src/public/PermitInfo.137.json
• Line 1993- "name": "finance.vote Token" + "name": "finance.vote Token (PoS)"src/public/PermitInfo.1.json (1)
6908-6911: Naming consistency: "MicroStrategy xStock" vs existing Backed/Wrapped xStock entries.There are existing entries like "Backed MicroStrategy Inc" and "Wrapped Backed MicroStrategy Inc" elsewhere in this file; this new one is "MicroStrategy xStock". Consider aligning naming to a uniform scheme (e.g., prefix with "Backed"/"Wrapped Backed" or suffix "xStock") to reduce downstream string-based matching issues.
Would you like me to scan the file and propose a consistent naming pattern for all xStock-like assets (Apple/Alphabet/Meta/Coinbase/MicroStrategy/etc.) and provide a small diff?
src/public/PermitInfo.8453.json (2)
6138-6140: Consistent naming and brand spellings.
- Gate Wrapped BTC, Diem, Gap Tooth Lizard, BaseShake, “Dobi by Virtuals”: ensure naming conventions (title-case, spacing, brand capitalization) match existing dataset rules for discoverability.
I can generate a quick normalization pass (name sanitization rules) if helpful.
Also applies to: 7182-7184, 7374-7376, 4918-4920
1-10: Optional: add a deterministic sort/format step to avoid noisy diffs.Large JSON maps benefit from a canonical sort (by address) and formatting lint to minimize merge conflicts and review noise.
Example Makefile task we can add in a separate PR to sort+format all PermitInfo.*.json with jq -S.
src/public/PermitInfo.56.json (1)
1-10: Optional data hygiene: enforce lowercase checksum-agnostic addresses and name normalization.Most keys already use lowercase hex. If the pipeline doesn’t enforce this, add a pre-commit step to lower-case keys and trim names to a sane charset to prevent surprises in consumers.
I can supply a one-off script to normalize and re-sort all PermitInfo.*.json.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (7)
.github/workflows/updatePermitInfo.yml(1 hunks)src/public/PermitInfo.1.json(4 hunks)src/public/PermitInfo.137.json(2 hunks)src/public/PermitInfo.42161.json(1 hunks)src/public/PermitInfo.43114.json(3 hunks)src/public/PermitInfo.56.json(22 hunks)src/public/PermitInfo.8453.json(17 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/updatePermitInfo.yml
🔇 Additional comments (13)
src/public/PermitInfo.137.json (1)
815-818: Approve Ankr Staked MATIC entry as unsupportedThe new entry for Ankr Staked MATIC is correctly marked as
"unsupported", and its formatting and placement match existing entries. A search across allsrc/public/PermitInfo.*.jsonfiles found no other references to “Ankr Staked MATIC” or “ankrMATIC,” so the name is unique and consistent with the asset’s official designation. No further changes are required.src/public/PermitInfo.43114.json (3)
1454-1457: Name consistency confirmed across networks
The"EURØP"entry appears in bothPermitInfo.137.jsonandPermitInfo.43114.jsonwith identical code points (0x45, 0x55, 0x52, 0xD8, 0x50) and is NFC-normalized in both cases. No further changes are needed.
662-666: Approve MOANI EIP-2612 v1 EntryAll verification checks passed:
- Valid JSON in
src/public/PermitInfo.43114.json(jq -eno errors)- No duplicate address entries across any
PermitInfo.*.jsonfiles (rgfound only this definition)
697-701: Please verify and update the token’s official nameIt looks like the only occurrence of this address (0xf9fb20b8e097904f0ab7d12e9dbee88f2dcd0f16) in your PermitInfo mappings is here:
• src/public/PermitInfo.43114.json (line 697)
Right now it’s labeled as
"name": "Stable Coin", which is very generic. To prevent ambiguity in UIs and avoid future collisions, please confirm the token’s exact official name (as shown on the Avalanche C-Chain explorer or by the issuer) and update this field. Thetype: "eip-2612"andversion: "1"entries can stay as is.src/public/PermitInfo.1.json (3)
2688-2691: Classification as "unsupported" for XBO: verify rationale.If this token lacks a standards-compliant permit (eip-2612/dai-like) or has a non-working/ambiguous implementation, "unsupported" is correct. If it does support permit, please add the correct type and version.
Use the script in my earlier comment to locate other occurrences of 0x167e6fcd728cdd00d012d8862934c2c333cb0839 across the repo and confirm whether any chain lists it with a different type. If you have an on-chain check, confirm whether permit() exists and works as expected.
962-966: PermitInfo JSON entry is correctly formatted—please confirm on-chain permit versionAll local checks passed without issues:
- The JSON is valid and the new entry appears only once (in
PermitInfo.1.json).- The address is lowercase and the
type: "eip-2612"/version: "1"fields match the repository conventions.Next step—manual on-chain verification
Please verify that Ninja Squad Token (0x70bef3bb2f001da2fddb207dae696cd9faff3f5d) indeed uses EIP-2612 with version “1” on Ethereum mainnet. You can do this by:
- Visiting the contract page on Etherscan (or your preferred block explorer) for mainnet.
- Reviewing the source code (or ABI) to locate the
DOMAIN_SEPARATORimplementation or thepermitfunction signature.- Confirming the version string passed to the domain separator matches
"1".Once you’ve confirmed the on-chain version, please update or merge as appropriate.
5996-5999: Please verify the Polkadot Token address across all chainsWe found the same address
0x8d010bf9c26881788b4e6bf5fd1bdc358c8f90b8mapped as “Polkadot Token (Relay Chain)” in multiple PermitInfo files. Unless this contract was deliberately deployed—via CREATE2 or a cross-chain registrar—at identical addresses on each network, it may be a copy-paste.• src/public/PermitInfo.1.json (line 5996)
• src/public/PermitInfo.56.json (line 1681)
• src/public/PermitInfo.42161.json (line 4484)
• src/public/PermitInfo.8453.json (line 5029)Please confirm on each network’s explorer (Etherscan, BscScan, Arbiscan, etc.) that this address actually represents the Polkadot Token contract. If any entry is incorrect, update or remove it.
src/public/PermitInfo.8453.json (3)
5030-5032: Cross-chain “Polkadot Token (Relay Chain)” mapping — confirm it belongs here.This address (0x8d01…90b8) is also added on other chains in this PR. If it’s a wrapped representation on Base (8453), “type”: "unsupported" is fine; otherwise, consider moving to the correct chain file or clarifying the name (e.g., “Polkadot (wrapped)”).
3081-3084: Ignore duplicate suggestion for BOMET entryThe address
0x33e7f871ce502ec77a0d96fdcd02c9219f95e944is present only once insrc/public/PermitInfo.8453.json, and the name “BOMET” does not appear elsewhere. The original note about a duplicate entry can be safely dismissed.Likely an incorrect or invalid review comment.
517-521: Manual verification required: Confirm EIP-2612 implementation & version “1” in on-chain contractsThe metadata file (src/public/PermitInfo.8453.json) passed all schema and sanity checks (keys, types, versions, extra fields) and correctly lists these three new entries with
"version": "1":
- 0x3977fc913db86b01a257232c568317798b903b07 (“Cody”)
- 0x9a9de07629ef283c2d700efd3958f59b7d528453 (“MOTO”)
- 0xc729777d0470f30612b1564fd96e8dd26f5814e3 (“Sapien”)
However, you must still verify on chain 8453 that each of these contracts:
- Implements the standard
permit(...)function per EIP-2612- Uses
"1"as theversionin its EIP-712 domain separatorA mismatch between the declared version and the contract’s actual domain separator will break signature flows. Please check the contract source or use an explorer/ABI lookup to confirm both
permitsupport and the version string inDOMAIN_SEPARATOR.src/public/PermitInfo.56.json (3)
223-226: dai-like type present (Fuse Token on BSC) — confirm we want mixed permit types on the same chain.Just a sanity check that consumers handle both eip-2612 and dai-like variants on 56. If there are known quirks (like non-standard permit parameters), consider a short compatibility note in docs.
777-780: PermitInfo.56.json “unsupported” entries verified
- Ran the provided
jqscript against src/public/PermitInfo.56.json; found 0 “unsupported” entries carrying aversionfield, as expected.- This file is scoped to chain 56 (BSC), so all entries inherently belong to the correct network.
- Spot-checked a representative token (0x0f0df6cb17ee5e883eddfef9153fc6036bdb4e37 – “BNB Attestation”) and confirmed it does not support an EIP-2612/DAI-style permit. No other tokens in this list currently expose a permit interface.
No changes needed here.
277-281: Action Required: Confirm EIP-2612 permit implementation on BSC contractsThe JSON schema entries for these five tokens are valid (all marked
type: "eip-2612",version: "1"), but we still need to ensure each BEP-20 contract actually implements the EIP-2612permit()and uses version “1” in its domain separator. Mislabeling here will break downstream permit flows.Please manually verify on BscScan (Contract → Code) that each address:
- Defines the function
permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)- Uses
"1"as its EIP-712 domain separator versionAffected contracts:
- 0x64748ea3e31d0b7916f0ff91b017b9f404ded8ef (Compounding Open Dollar)
- 0x66a9bda1f779ce5743fd6bb5d9546b453ecfaf1f (Miracleplay Token)
- 0x94eafeeef7ffa66203fdc9349c54d601472a79dc (TrustSwap Token)
- 0xc6bdfc4f2e90196738873e824a9efa03f7c64176 (ViciCoin)
- 0xd955c9ba56fb1ab30e34766e252a97ccce3d31a6 (XPIN Token)
| "0x8d010bf9c26881788b4e6bf5fd1bdc358c8f90b8": { | ||
| "type": "unsupported", | ||
| "name": "Polkadot Token (Relay Chain)" | ||
| }, |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Added mapping for Polkadot Token (Relay Chain) looks correct.
- Address ordering is preserved around nearby keys.
- Type “unsupported” and absence of version align with the file’s conventions.
Run this quick check to validate JSON, key ordering, and cross-file consistency of this address/name:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) JSON validity
jq -e '.' src/public/PermitInfo.42161.json >/dev/null
# 2) Cross-file consistency for this address (type/name the same everywhere)
ADDR='0x8d010bf9c26881788b4e6bf5fd1bdc358c8f90b8'
echo "Occurrences of $ADDR across PermitInfo files:"
rg -n -C2 "$ADDR" src/public/PermitInfo.*.json || true
# 3) Ensure keys are lexicographically sorted (simple monotonic check)
echo "Checking key order for src/public/PermitInfo.42161.json..."
jq -r 'keys_unsorted[]' src/public/PermitInfo.42161.json \
| awk 'BEGIN{prev=""} {if(prev!="" && $0<prev){print "Out-of-order key: " $0 " < " prev; exit 1} prev=$0} END{print "OK: keys are sorted."}'Length of output: 2412
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
# Re-validate lexicographic ordering using Python for accuracy
python3 - << 'EOF'
import json, sys
path = "src/public/PermitInfo.42161.json"
with open(path) as f:
data = json.load(f)
keys = list(data.keys())
sorted_keys = sorted(keys)
if keys != sorted_keys:
for idx, (orig, expected) in enumerate(zip(keys, sorted_keys)):
if orig != expected:
print(f"Out-of-order key at index {idx}: {orig} should be {expected}")
sys.exit(1)
# If file has extra keys beyond the shorter list, flag them
if len(keys) != len(sorted_keys):
print("Key count mismatch after sorting.")
sys.exit(1)
# Generic mismatch
print("Keys do not match sorted order.")
sys.exit(1)
else:
print("OK: keys are lexicographically sorted")
EOFLength of output: 156
Reorder JSON keys in PermitInfo.42161.json to restore lexicographic order
During verification we confirmed:
- JSON parses without errors.
- The new mapping for
0x8d010bf9c26881788b4e6bf5fd1bdc358c8f90b8is consistent across all PermitInfo files. - However, the top-level keys in
src/public/PermitInfo.42161.jsonare not fully sorted. At index 3, the keyappears before0x00000000ea00f3f4000e7ed5ed91965b19f1009bbut lexicographically it should come after that entry.0x00000000702749f73e5210b08b0a3d440078f888
Please update the file so that all top-level keys are in strict ascending order. For example:
- "0x00000000ea00f3f4000e7ed5ed91965b19f1009b": { … }
+ "0x00000000702749f73e5210b08b0a3d440078f888": { … }
+ "0x00000000ea00f3f4000e7ed5ed91965b19f1009b": { … }This will align with the project’s convention of maintaining lexicographically sorted JSON keys.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In src/public/PermitInfo.42161.json around lines 4484–4487 the top-level JSON
keys are not strictly lexicographically ordered: the key
"0x00000000ea00f3f4000e7ed5ed91965b19f1009b" appears before
"0x00000000702749f73e5210b08b0a3d440078f888" but should come after it; to fix,
reorder the top-level entries so keys are in strict ascending lexicographic
order (move the "0x00000000ea00..." entry to its correct position after
"0x00000000702749..." while preserving each entry’s full object content and
commas, and ensure the file still parses as valid JSON).
Summary
Fix permit info workflow failures due to lack of permissions: https://github.com/cowprotocol/token-lists/actions/runs/17223931931/job/48864833552
Testing
Trigger the failing workflow from this PR: should not fail.
Successful JOB: https://github.com/cowprotocol/token-lists/actions/runs/17244405753
Summary by CodeRabbit