The Solidity compiler automatically generates a JSON file, the
contract metadata, that contains information about the current contract.
It can be used to query the compiler version, the sources used, the ABI
and NatSpec documentation in order to more safely interact with the contract
and to verify its source code.

The compiler appends a Swarm hash of the metadata file to the end of the
bytecode (for details, see below) of each contract, so that you can retrieve
the file in an authenticated way without having to resort to a centralized
data provider.

Of course, you have to publish the metadata file to Swarm (or some other service)
so that others can access it. The file can be output by using solc--metadata
and the file will be called ContractName_meta.json.
It will contain Swarm references to the source code, so you have to upload
all source files and the metadata file.

The metadata file has the following format. The example below is presented in a
human-readable way. Properly formatted metadata should use quotes correctly,
reduce whitespace to a minimum and sort the keys of all objects to arrive at a
unique formatting.
Comments are of course also not permitted and used here only for explanatory purposes.

Note the ABI definition above has no fixed order. It can change with compiler versions.

Note

Since the bytecode of the resulting contract contains the metadata hash, any change to
the metadata will result in a change of the bytecode. Furthermore, since the metadata
includes a hash of all the sources used, a single whitespace change in any of the source
codes will result in a different metadata, and subsequently a different bytecode.

Because we might support other ways to retrieve the metadata file in the future,
the mapping {"bzzr0":<Swarmhash>} is stored
CBOR-encoded. Since the beginning of that
encoding is not easy to find, its length is added in a two-byte big-endian
encoding. The current version of the Solidity compiler thus adds the following
to the end of the deployed bytecode:

0xa10x65'b''z''z''r''0'0x580x20<32bytesswarmhash>0x000x29

So in order to retrieve the data, the end of the deployed bytecode can be checked
to match that pattern and use the Swarm hash to retrieve the file.

The metadata is used in the following way: A component that wants to interact
with a contract (e.g. Mist) retrieves the code of the contract, from that
the Swarm hash of a file which is then retrieved.
That file is JSON-decoded into a structure like above.

The component can then use the ABI to automatically generate a rudimentary
user interface for the contract.

Furthermore, Mist can use the userdoc to display a confirmation message to the user
whenever they interact with the contract.

Additional information about Ethereum Natural Specification (NatSpec) can be found here.

In order to verify the compilation, sources can be retrieved from Swarm
via the link in the metadata file.
The compiler of the correct version (which is checked to be part of the “official” compilers)
is invoked on that input with the specified settings. The resulting
bytecode is compared to the data of the creation transaction or CREATE opcode data.
This automatically verifies the metadata since its hash is part of the bytecode.
Excess data corresponds to the constructor input data, which should be decoded
according to the interface and presented to the user.