Disclosure: The author holds PAR. This article documents an investigation and a live interaction with a public onchain mechanism. It is not investment advice. The author paid the gas required to trigger the burn and received none of the collected fees.

On October 15, I used an ordinary wallet to call PAR’s fee-collection contract and burn 1,478,704.549850 PAR.

I am not part of the project team. I had no administrator privileges and was not on a whitelist. The wallet did not even have gas on Robinhood Chain before this test; I transferred 0.00004 ETH to it and ultimately spent about 0.00000536 ETH, or roughly 1.25 cents.

I received none of the fees. The contract followed the rules fixed at launch: it burned the protocol share and credited the other half to the creator’s fee account.

The transaction did not merely show that “the community helped the project burn some tokens.” It demonstrated something more important:

PAR’s direct-burn mechanism is permissionless and open to everyone. Any community member can trigger it. The project cannot block the caller or alter the distribution at execution time.

This is a live mainnet test that anyone can independently verify, not just a theoretical reading of the source code.

A mainnet transaction anyone can verify

The transaction that triggered the burn:

• Robinhood Chain Blockscout transaction
• Hoodscan transaction
• Stonkscan transaction

The transaction called:

collectFees(0x507b6f349a80114097a67b8b4677367acc15b220)

Relevant contracts and accounts:

• PAR token contract
• PairPadLaunchLocker
• Caller address
• PAR’s official live statistics

The transaction receipt shows the critical onchain records clearly:

1. PoolManager transferred 2,957,409.099700 PAR to the locker.
2. The locker transferred 1,478,704.549850 PAR to the zero address.
3. The remaining 1,478,704.549850 PAR went to the creator’s fee account.
4. pendingFees(PAR) fell to zero after the call.
5. Total recorded burns rose to 109,371,390.888664 PAR, equal to 10.94% of the initial one-billion-token supply.

The cumulative buyback-burn figure did not change across this transaction. The entire 1.4787 million increase therefore came from PAR-denominated trading fees, not a buyback.

What “permissionless” means here

Many projects describe their mechanisms as decentralized, but that word often conflates three separate questions:

• Who decides how much gets burned?
• Who is allowed to trigger the burn?
• Who can take the assets moving through the process?

PAR’s direct-burn path separates these questions.

The caller does not choose the burn amount. It comes from LP fees already generated by the Uniswap v4 pool but not yet collected.

There is no restriction on who may trigger it. collectFees(address token) is an external function with no onlyOwner modifier, no keeper whitelist, and no requirement that the caller hold PAR.

The caller cannot choose where the assets go either. The token, creator recipient, protocol share and creator share were fixed when the launch was created. A stranger calling the function can only collect fees for the predetermined beneficiaries and burn the protocol’s PAR share.

In other words, the caller can press the button but cannot rewrite what the button does.

That is the most important part of this test: an ordinary community wallet pressed the button, and the chain enforced the predetermined distribution exactly.

Why 1.47 million PAR had accumulated for burning

The investigation began with an apparent contradiction.

The PAR pool was active on October 14, and buyback burns were continuing, but subtracting the two official cumulative counters suggested that direct burns from PAR trading were zero.

My initial formula was:

Direct burns = total burned − buyback burned

That formula can separate historically executed burns, but it cannot answer how much burnable value trading generated yesterday. A swap and a burn are not the same action:

1. Users trade, leaving LP fees in the pool.
2. Someone calls collectFees.
3. The locker collects the fees.
4. The protocol’s PAR share is burned.
5. The creator share is credited to the fee escrow.

If nobody performs step two, the fees do not disappear. They continue to accumulate, but the token’s total supply does not immediately decrease.

The onchain trail: automated execution stopped on October 5

To bypass the indexer’s aggregation, I scanned PAR’s Transfer(from, 0x0, value) logs and classified them by the address initiating each burn.

Before my transaction, the old locker had last executed a direct burn at 12:27 UTC on October 5, 2026:

• Amount: 346,430.956 PAR
• Blockscout transaction

After that transaction, the buyback wallet continued burning tokens and the PAR pool continued trading, but the offchain keeper that had previously called collectFees stopped doing so.

During the October 14 Toronto calendar day, the main pool recorded 174 swaps: 68 buys and 106 sells. Sellers supplied about 26,528,253 PAR, generating approximately 133,000 PAR of protocol burn entitlement that remained in uncollected fees.

When I read the locker’s:

pendingFees(address token)

the pool had accumulated roughly 2.94 million PAR and 0.338 ETH in uncollected fees. An eth_call simulation of collectFees(PAR) succeeded and returned amounts consistent with pendingFees.

That ruled out several more serious possibilities:

• PAR’s burn function had not failed.
• The locker had not lost access.
• The fees were still collectable.
• The distribution path still executed correctly.
• What had stopped was the offchain caller, not the onchain burn mechanism.

Permissionless does not mean automatic—but it lets the community take over execution

This incident demonstrates both the strength and the boundary of a permissionless mechanism.

The boundary is that permissionless does not mean automatic. A contract does not spontaneously submit transactions. If the project keeper, community bots and outside observers all stop calling, burnable fees can remain in the pool indefinitely.

The strength is that the project does not monopolize execution. When the official keeper stops, the community does not need approval, a redeployment or a governance vote. Anyone can inspect the pending fees, simulate the transaction and trigger the same immutable distribution.

That provides an additional layer of verifiability beyond a team’s promise to conduct periodic buybacks and burns: the community can do more than observe. It can complete the final execution step when the normal operator is absent.

A better way to monitor the mechanism

Watching only the cumulative burn counter conflates “no fees were generated” with “fees were generated but nobody triggered collection.” Monitoring an open-execution system should include at least:

• the time of the locker’s latest collectFees call;
• the PAR and quote assets accumulating in pendingFees;
• generated-but-pending burns versus executed burns;
• an alert when the keeper exceeds its normal execution interval;
• whether independent community backup keepers exist.

The ideal system would not depend on one token holder noticing the discrepancy by chance. Multiple independent keepers could compete to execute the call. Because callers receive none of the fees, the protocol could also consider a small gas reimbursement to turn open access into reliable public infrastructure.

Conclusion

Burning 1.4787 million PAR is the visible outcome, but it is not the most important number in this story.

What matters is that PAR’s community execution path has now been tested on mainnet:

• An ordinary address can call it.
• No administrator approval is required.
• The caller cannot divert assets.
• The caller cannot change the distribution.
• The burn amount comes from real accumulated fees.
• The community can complete execution when the official keeper stops.

The source code says that anyone can call the function in theory. This transaction turned that theory into evidence: a token holder identified an execution gap, independently verified the pending fees, and spent about 1.25 cents in gas to complete an onchain burn of 1.4787 million PAR.