Consider the function execution of BuyerAgent::purchase
The key thing to note is that the success of calling the entire transaction depends on the success of each individual purchase.
Consider what happens when you call `Swan::purchase'.
This point in the process of performing the purchase function is a key place. Asset transfers from listing.seller to buyer.
The key assumption of the protocol here is that the asset belongs to listing.seller (ie to the one who called the ' Swan::list'
However, it is obvious that the asset may not belong to listing.seller, at least listing.seller can intentionally or accidentally just transfer it to another address.
The limitation of this behavior is not provided in the implementation of SwanAsset
.
Because the success of the purchase call depends on the success of the purchase of individual assets => it is evident that if such an accidental/intentional user behavior (will send their asset to another address) will DoS the entire purchase function for this round of Buyer Agent.
Of course, it can send a request to the LLM for generating new assets for purchase, but it is not certain that models are sufficiently intelligent to exclude assets by such a principle.
I would say that in 99.99% of the cases the round will never be closed, which means everyone who paid a listing commission in this round will be forced to relist. So they’re just gonna lose money on the commission.
The impact of this problem is DoS in one round and loss of funds to the listing commission - Severity: Medium
Manual Review
Block all possible asset owner behaviour in AssetManager
realization. At least override transfer function.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.