Send a Correction to the Desk

Where to write

One address handles everything: [email protected]. There is no form on this page, because a form would collect more than the desk needs and an email address is easier for everyone to keep a record of.

Corrections

This is the message the desk most wants. Solana moves, limits are raised through network proposals, client defaults change, and an entry that was accurate when written can quietly stop being accurate. If something here is wrong, the useful message names three things.

• The entry, by title or URL, so there is no ambiguity about which page is being discussed.
• The sentence or claim that is wrong, quoted rather than paraphrased.
• What the current behaviour actually is, with a pointer to documentation, a signature, or a reproduction anyone can run.

With those three, a correction usually takes one exchange. Without them it takes several, and some of them never resolve. A correction that arrives with a transaction signature attached is the strongest form available, because it can be checked directly rather than argued about.

Corrections are made in the entry itself and the modification date moves when they are. Where a change is substantive, the text says what changed rather than presenting the new version as though it had always been there.

Technical questions

Questions about the mechanisms described here are welcome, particularly the ones that reveal an entry explained something badly. A question that keeps arriving usually means a section is unclear, and it will get rewritten rather than answered privately forever.

What the desk cannot do is debug a specific setup. There is not enough context in an email to diagnose someone else's sender, and an answer built on guesses about a system nobody here can see would be worse than no answer. Questions about the general behaviour are answerable; questions of the form why is my run doing this are not.

Documentation pointers

If a mechanism described here is documented somewhere the desk has not cited, that pointer is worth sending. Entries are stronger when a claim can be traced to a public source, and a better source will usually replace a weaker one in the text.

What will not get a useful reply

Being direct about this saves everyone time.

• Requests to review, rank or endorse a product. The desk does not audit platforms and will not publish an opinion it cannot support with something a reader could check.
• Offers of paid placement, sponsored entries or link insertion. Entries are written for the subject and not around a link, and that does not change for a fee.
• Requests for runnable automation, private code or a configuration to copy. The site explains mechanisms and stops there, deliberately.
• Requests for a landing rate, latency figure or performance number to quote. The desk does not publish those because it cannot establish them honestly, which is stated throughout the log.
• Anything asking for help misrepresenting activity to other market participants. Describing how the send path works is not a service for making a market look like something it is not.

What happens to a message

Mail is read by the desk and nothing else is done with it. Addresses are not added to a list, are not shared, and are not used to send anything the sender did not ask for. There is no newsletter to be enrolled in, which removes the question entirely.

A message that leads to a change in an entry may be acknowledged in the text if the sender wants that, and will not be if they do not. The default is no attribution, because most corrections arrive from people who care more about the page being right than about being named on it.

Response times

The desk does not promise one, because promising a response time it might not meet would be the same kind of unverifiable claim the rest of this site refuses to publish. Corrections with a signature or a documentation link attached tend to be handled first, since they need the least work to verify.