PANews berichtete am 17. Mai, dass laut On-Chain-Daten der pump.fun-Angreifer @STACCoverflow vor zwei Stunden den Token FSA (Flash Stacc Attack) auf der Solana-Kette veröffentlicht hat. Das aktuelle Handelsvolumen des Tokens liegt bei knapp 1,5 Millionen US-Dollar, mit einem Marktwert von fast 60 Millionen US-Dollar. FSA wird derzeit bei 0,0058 USDT gehandelt, was einem Anstieg von mehr als 24.788 % seit seiner Veröffentlichung entspricht.
Heute wurde berichtet, dass pump.fun einen Flash-Darlehensangriff erlitten hat. Der Vertrag ist derzeit sicher und das Team wird den betroffenen Token Liquidität hinzufügen.
Laut der Space-Zusammenfassung des Twitter-Benutzers @ciaobelindazhou erwähnte der neue Robin Hood im Währungskreis @STACCoverflow in der Space-Diskussion, dass der Betrag des Angriffs auf die Pumpfun-Plattform etwa 2 Millionen US-Dollar betrug, nicht 500.000 US-Dollar oder 80 Millionen US-Dollar online gemeldet.
Der Angreifer Stacc sagte, er habe den CTO von Pumpfun vor einigen Wochen vor möglichen Problemen gewarnt, das Team habe jedoch nicht darauf geachtet.
Stacc arbeitete einmal bei PumpFun. Er sagte, dass ihm die negativen Auswirkungen von PumpFun auf die Branche nicht gefielen. Es war nicht so, dass er mit dem Team unzufrieden war, sondern dass er mit der Vision, Umsetzung und dem Management von PumpFun unzufrieden war.
Das Publikum machte sich Sorgen um die persönliche Sicherheit und rechtliche Probleme von Stacc und hoffte, dass er in Kontakt bleiben und weiterhin ein gewissenhafter Entwickler sein würde.
Die Angriffssumme belief sich auf 2 Millionen US-Dollar, was kaum Auswirkungen auf Pumpfun hatte, das bereits einen Umsatz von 17 Millionen US-Dollar erwirtschaftet hatte, sondern sich eher auf sein öffentliches Image auswirkte. Dieser Vorfall offenbarte Probleme mit der Plattform, wie zum Beispiel hohe Gebühren, aber Spieler dürfen dadurch keine Nutzer verlieren. Das Verhalten von Stacc basiert eher auf persönlichen Überzeugungen als auf finanziellen Interessen. Seine Gefühle könnten durch die jüngsten familiären Veränderungen und Täuschungen beeinflusst werden.
Entscheidend ist, ob der Angriff aufgrund der vorherigen Position von stacc erfolgreich war oder ob andere Entwickler das gleiche Problem hätten entdecken können. Im ersteren Fall liegt die Verantwortung beim Entwickler; im letzteren Fall ist das Team schuld, schließlich hat es bereits jemand gewarnt.