If I understand the model you proposed correctly, it basically consists of making a payment to someone (whether an instance or a central authority), obtaining tokens in exchange, giving tokens to a content creator, and the content creator exchanging them to get their money back.

Having a central authority wouldn’t work because it goes against the principles of the Fediverse and most users would prefer that there not be a single point of failure. Having an instance exchange money for tokens wouldn’t work because there is no scarcity of tokens and no guarantee that an instance honours a request.

This method could instead be replaced by content creators adding links to receive payments with people giving money to them directly.

The problem is that there is nothing meaningful you can exchange this currency for. The Fediverse is fundamentally designed to allow anyone to start a server. There is no meaningful way to reward someone with anything of value except the satisfaction of having helped grow the instance they are supporting. There is no good way to boost someone without manipulating the vote count or changing the protocol itself. Many apps already offer customizability while simultaneously being free as in free beer and free as in free speech. The main reason many people move to the Fediverse is to escape an internet where everything is “enshittified,” and most Fediverse users wouldn’t want to shift to a proprietary model.

TL;DR: not possible with random cookies, too much work for too little gain with already-verified cookies

There is no such add-on because random cookies will not work. Whenever someone has been authenticated, Google decides the cookie the browser should send out with any subsequent requests. Google can either choose to assign and store a session id on the browser and store data on servers or choose to store the client browser fingerprint and other data in a single cookie and sign this data.

Additionally, even with a verified session, if you change your browser fingerprint, it may trigger a CAPTCHA, despite using a verified cookie. In the case of a session token, this will occur because of the server storing the fingerprint associated with the previous request. On the other hand, if using a stateless method, the fingerprint will not match the signed data stored inside the cookie.

However, this could work with authenticated cookies wherein users contribute their cookies to a database and the database further distributes these cookies based on Proof of Work. This approach, too, has numerous flaws. For instance, this would require trusting the database, this is a very over engineered solution, Google doesn’t mind asking verified users to verify again making this pointless, it would be more efficient to simply hire a team of people or use automated systems to solve CAPTCHAS, this approach also leaks a lot of data depending on your threat model, etc.

ASCII was interpreted as UTF because the function that checked whether the given text was Unicode checked the difference between bytes at even and odd positions. Many of the common phrases used to trigger this were in the 4-3-3-5 format (by letters), e.g., Bush hid the facts However, there was never any reason that this format of character placement was necessary for the bug (though even length was necessary)

The DKTB is a personal app. It is therefore assumed, that the User will not share it with other people, and that only the User can access and control their personal DKTB. Ultimately, this means that all attestations in a DKTB are expected to pertain to and only be presented by the same User. This is enforced by requiring the user to authenticate using biometry or PIN-code when using the app and only allowing the DKTB application to be installed on one device per user. (from the PDF)

This is a false assumption: PIN codes can be bypassed by sharing them with others. Devices can be faked unless using hardware attestation, which prohibits any modifications to the device which may be undertaken by those interested in rooting or installing a custom OS.

Users can initially acquire a DKTB on their smartphone or tablet via Google Play or the Apple App store. (from the PDF)

This method requires the use of a vanilla, unmodified device, effectively prohibiting modifications to devices that one might wish to alter.