We want to clarify events related to
$ticker and specifically what happened using our product, Party:
- The
$ticker Party crowdfunded 975 ETH with an abnormally high 90% creator split. 877 ETH went to the creator’s EOA, 98 ETH went to the Party to be controlled by members.
- From their personal EOA, the creator deployed the
$ticker token with a supply of 1B.
- 590M tokens were sent to the Party and distributed to Party members.
- 240M tokens and 870 ETH were used to create an LP position from the creator’s EOA.
- 150M tokens were sent from the creator’s EOA to another EOA. According to the creator, the stated goal of this transfer was to facilitate an airdrop. The 2nd EOA then sold 130M tokens.
- Next, the creator made a proposal to use the Party’s 98 ETH to buy
$ticker. Because over 50% of Party members had delegated their votes to the creator, this proposal passed instantly, and was executed.
- Also, the creator locked the LP position forever, then transferred control to the Party, which now earns fees from this LP position.
- LP fees earned prior to transfer (27 WETH and 28.4M
$ticker) are still in the creator’s EOA.
The creation and sale of
$ticker happened entirely outside of
Party.app. Party’s default settings are that 100% of ETH and all core actions are controlled by Party members. In the case of this Party, which used a 90% creator split, core actions and control of funds happened outside of the Party. No exploits happened within the Party Protocol. Moving forward, we’re making immediate changes to our UI to better prevent this from happening in the future. Party’s UI already warns users of the creator split and delegating to members with high voting power. Now, we are disabling high creator splits, and the Party UI will not let users delegate votes to a creator who already has a high amount of voting power.
Our reputation for security and protecting our users is our top priority, and we’ll continue to improve our product so that it is even more aligned with user’s expectations.