Nothing-up-my-sleeve numbers standard Premise
Several cryptographic primitives employ randomized numerical constants. To avoid suspicious that the designer selected such constants in order to plant a backdoor, &quot;nothing-up-my-sleeve numbers&quot; are used. These are numbers constructed from the first digits of some important constants, like $\pi$, $e$, $\sqrt{2}$, ... so that they do not appear to be well-crafted to hide a backdoor.
The Problem
However, designers of different systems use different constants. Below some examples copied from the wikipedia's page:

Small roots of small integers (SHA-1, SHA-2)

$\sin 1, \sin 2, \dots$ (MD5)

$e$ (DFC)

$\pi$ (Blowfish and many other)

$1/\pi$ (ARIA)

0x123456789ABCDEFFEDCBA9876543210 (KASUMI)

ASCII string &quot;expand 32-byte k&quot; (Salsa20)


But with enough degrees of freedom, it is clear that nothing-up-my-sleeve numbers lose their purpose. For example, who does guarantee that the sentence &quot;expand 32-byte k&quot; was not selected among thousands of similarly innocent ones (&quot;expanding 32-byte k&quot;, &quot;expansion of 32-byte k&quot;, &quot;32-byte expanded k&quot;, ...) in order to hide a backdoor? Likewise for numerical constants.
The Question
In light of the previous considerations, was a &quot;nothing-up-my-sleeve numbers standard&quot; ever proposed? If not, why not?
A very simple standard could be: &quot;A cryptographic primitive employing a randomized constant $C$ (if there are more randomized constants, $C$ is their binary concatenation) must fix $C$ to be the first digits of the binary representation of $\pi$.&quot;
A (probably weak) reason not to use a standard is that some nothing-up-my-sleeve numbers may serve some sort of purpose.  As an example, you cannot change Salsa20's constants to anything, it must be sufficiently asymmetric.  It's feasible to presume that another cipher may have a different set of requirements
As per this answer:

Salsa20 has strong rotational symmetry. The main point of these constant is that they're not invariant under rotations, introducing an asymmetry. The precise value isn't very important, as long as it's sufficiently asymmetric.

The answer goes into further detail, quoting DJB himself on the matter.
This answer also details several cryptographic constants, and the padding constant for HMAC is similarly designed to be asymmetric:

The padding constants for HMAC, 0x36 for ipad and 0x5C for opad, are repeated (for the hash function's block size) and XORed with the key to generate the prefixes for the two hashing steps. 0x36 = 0b00110110 and 0x5C = 0b01011100 - these two values are about &quot;as different as possible&quot;, to avoid any attacks which rely on a similar hash state after the key block for inner and outer hash. This is mainly a heuristic, as far as I understand.