fix(bap578-scanner): correct ABI shapes + add spec/reference compatibility - #70
fix(bap578-scanner): correct ABI shapes + add spec/reference compatibility#70BORT-AGENTS wants to merge 5 commits into
Conversation
…ibility Testing the scanner against a live BAP-578 collection surfaced a few signatures that do not match BAP578.sol: - getAgentMetadata returns (AgentMetadata, string), not six flat values; the scanAgent example read metadata.persona off the wrong level - AgentFunded / AgentWithdraw / MetadataUpdated were documented with extra params (funder, owner, newURI) the contract does not emit - LogicAddressUpdated was missing Also adds a Deployment compatibility section: some deployments implement the BAP-578 spec shape (getState / State / Status enum) rather than the reference, so the scanner shows a getState-then-getAgentState fallback and notes the Status enum ordinal is deployment-specific. Verified against BAP578.sol on main and a live mainnet collection.
Greptile SummaryThe PR corrects the documented reference ABI shapes and makes the ethers scanner examples compatible with both reference- and spec-shaped BAP-578 deployments.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains; the three previously reported compatibility paths are addressed by the combined ABI,
|
| Filename | Overview |
|---|---|
| skills/bap578-scanner/SKILL.md | Corrects reference signatures and fully routes the documented ethers scanning flow through spec/reference-compatible state, metadata, enumeration, and status handling. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[scanAgent tokenId] --> B{getState succeeds?}
B -->|Yes| C[Normalize spec State]
B -->|No| D[getAgentState]
D --> E[Normalize reference AgentState]
C --> F[Raw getAgentMetadata call]
E --> F
F --> G{Decode reference return}
G -->|Success| H[Metadata plus metadataURI]
G -->|Failure| I[Decode spec metadata tuple]
H --> J[Return normalized agent]
I --> J
Reviews (5): Last reviewed commit: "fix(bap578-scanner): build the combined ..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Review feedback: scanAgent still called the reference-only getAgentState directly, so it failed on the spec-shape deployments the compatibility section documents. It now reads state via readState (spec first, reference fallback), reports which shape answered, and returns the union of both shapes' fields. isFreeMint is reference-only, so it is wrapped in a try/catch and reported as undefined on spec deployments instead of aborting the scan.
Review feedback: the getState/getAgentState fallback silently fails when the contract instance is built from the reference ABI alone. contract getState is undefined in that case, so the call throws a TypeError before reaching the chain and the fallback then reverts on a spec deployment. Documents the combined ABI and shows the spec fragment to append.
Follows the review thread to its conclusion. getAgentMetadata shares a selector across shapes but returns different values, so it is now decoded from the raw call data with a reference-then-spec fallback (readMetadata); decoding a spec return with the reference shape throws, and the bulk scanner was swallowing that as token-not-found and dropping valid agents. scanAllAgents falls back from getTotalSupply to ERC-721 totalSupply, and scanOwnerPortfolio falls back from tokensOfOwner to balanceOf plus tokenOfOwnerByIndex, so both entry points run on spec deployments. Liveness is resolved through one isActive(agent, activeStatus) helper used by computeMetrics, scoreAgentHealth, the at-risk pattern and the CSV export, instead of reading the reference-only active flag. The viem example and event-indexing sections remain reference-only by design: spec deployments emit different event signatures, which the compatibility section now states explicitly.
…only getters The compatibility section described the combined ABI but the Setup block still constructed the contract from the reference ABI alone, so contract.getState was undefined and every fallback threw before reaching the chain. Setup is now the single source and also carries the enumerable fragments the supply and portfolio fallbacks call. The view-function list marks which getters are reference-only and which return a different shape under the spec, so the divergences are visible where the functions are introduced rather than only in the compatibility section. Also corrects a pre-existing mismatch: indexAllEvents emits eventName while mintTimeSeries and fundingFlow read event.name, so both silently returned empty results.
|
Tested the corrected skill against a live spec-shaped BAP-578 collection on BSC mainnet before opening this. One contract instance covers both deployment shapes. Single agent read
The metadata line is the one worth noting. Both shapes share the selector Status is reported as the raw integer with the label withheld, since the enum ordinal is fixed at deploy time and cannot be assumed. Bulk and portfolio paths
Both entry points previously threw on their first call against this deployment, so Every signature in the diff was checked against |
1 participant
While testing the BAP-578 On-Chain Scanner skill against a live BAP-578 collection, a few signatures did not line up with
BAP578.sol:getAgentMetadatareturns(AgentMetadata, string), not six flat values. ThescanAgentexample readmetadata.personaoff the wrong level (now destructured).AgentFunded,AgentWithdrawandMetadataUpdatedwere documented with extra params (funder,owner,newURI) that the contract does not emit.LogicAddressUpdatedwas missing.I also added a short Deployment compatibility section. Some deployments implement the BAP-578 spec shape (
getState/State/Statusenum) rather than the reference, so the scanner now shows agetState-then-getAgentStatefallback and notes that the Status enum ordinal is deployment-specific (mapping the integer with a hard-coded array can silently mislabel status).All signatures verified against
BAP578.solonmainand a live mainnet collection. Bumps the skill to v1.1.0.