MetroGnomo – FAQs

How does your “mutual distributed ledger technology” differ from Bitcoin’s blockchain?

Bitcoin blockchains are a complicated form of MDL (“mutual distributed ledger”) which are necessary in an environment of minimal trust and non-existent law; this, however, is not the environment of typical business. Unlike the complex cryptographic algorithms of Bitcoin which require intensive, expensive and power-hungry computation, the Z/Yen approach is transparent, easily understood and requires only modest computer power. MetroGnomo is an example of Z/Yen’s quest to build and demonstrate simple, practical MDLs in business environments in which reasonable trust is a given. This contrast demonstrates the flexibility of MDL technology to face the challenges of different environments.

Z/Yen MDL software suite, ChainZy, provides the basic architecture for wide variety of MDL services. One of these services is a persistent, distributed immutable table of timestamps of data, called MetroGnomo. Z/Yen's MDLs are equivalent to blockchains, but do not rely upon an expensive mining approach, but uses what we call “agnostic broadcasting”. Agnostic broadcasting provides persistence and resiliency at low-cost and high speed (over two hundred transactions per second have been demonstrated).

What is the goal of the MetroGnomo experiment? How long will it last?

MetroGnomo is a success if it demonstrates that the simplest, leanest MDL can be useful and work with other MDLs. Because it is so minimalistic, it is feasible for Z/Yen to envision running indefinitely as a public service. If participants decide, over time, to provide their own transmitters and receivers, MetroGnomo may run for decades in a mode analogous to Bitcoin, but without the large-scale costs (it has been estimated that each Bitcoin now costs hundreds of pounds of electricity to generate).

What is MetroGnomo Beta?

The version of MetroGnomo currently available online is known as MetroGnomo Beta. As the title implies, we are actively working to improve by responding to user feedback. MetroGnomo Barebones will remain its settled core. is an open-source timestamping service utilising Z/Yen's agnostic broadcast distributed ledger technology, do alternative versions of MetroGnomo exist that integrate public proof existence with private content chains?

Yes. Z/Yen has developed additional versions of MetroGnomo which:

  1. Link MetroGnomo timestamps to permission ledgers holding the underlying files
  2. Hold no central registry of MetroID's
  3. Encrypt all entries in the public ledger
  4. Allow the timestamp owner to grant permission for other parties to view their entries without disclosing their MetroID
  5. Allow parties to easily extract those entries they have permission to view

For more information please contact us.

Who is currently using MetroGnomo?

Several commercial clients - within both the insurance and clinical trials spaces - are already employing versions of the mutual distributed ledger. SafeShare Global - an insurance firm specialising in the Sharing Economy - is using MetroGnomo to provide a trusted record of insured parties, and are actively exploring opportunities to "coordinate the provision of products between counter-parties in near real-time and to radically cut the cost of this coordination". Blem Information Management Ltd's XLRAS reinsurance administration system uses the MetroGnomo timestamping and document retrieval system to "increase trust in reinsurance records".

MetroGnomo is also handling over 60,000 clinical interactions each working day. These are derived from several different clinical trials from a variety of research areas across the globe (see live).

How does the original creator of the file provide others with proof-of-existence?

MetroGnomo can be used to prove the existence of a piece of information at the time the timestamp was issued. The timestamp contains 3 elements – a MetroTime, a UUID (unique universal identifier) and a 500 character tag. By including a hash of the file or idea in the tag a user can prove that the file or idea was in existence at time of stamping. MetroGnomo provides an online utility that enables another user to find the times at which a document was previously timestamped if he has either the file or the MetroGnomo generated file hash. A previous timestamp can also be located using its UUID or MetroTime.

What are the potential real-world use cases for this technology?

  • Book, music and patent registration
  • Insurance contracts
  • Settlement
  • Medical and clinical trials recording (see heat map)
  • Patient prescriptions
  • Time sensitive submissions, imagery and CCTV
  • Compulsory employee e-learning certification
  • Proof of attendance (e.g. visits by security guards or care workers)

Basically MetroGnomo can be employed for any application where it would be useful to have third party proof that a given piece of information was in existence at a point in time and to give it a unique identity code.

For example, in the same way that scientists, such as Newton, concealed their theorems in anagrams, an author can use MetroGnomo to prove that he had possession of a book’s contents at a given time while concealing the content itself and the identity of the author. To achieve this, a user simply timestamps the hash of the book using his private MetroID (which ultimately is linked to his email address).

Are there any plans for an app?

A prototype application has been developed to provide proof of physical visits to locations (for care workers, security guards etc.). This will be available shortly with MetroGnomo at its core.

How does MetroGnomo help coordinate information from different MDLs or blockchains?

MetroGnomo timestamps provide the MetroTime (timestamp) and unique universal identifiers. The MetroTime is the time MetroGnomo issued the timestamp, not the time the timestamp was requested. The MetroTime is guaranteed to be unique and greater than the preceding MetroTime, so it can also act as a unique identifier. In a world where there are multitudes of MDLs in existence, MetroGnomo’s third party validated time and unique identifiers can provide trusted connections between entries on different ledgers. For example, MetroGnomo could be used to link an identity ledger to a transaction ledger.

MetroGnomo is open-source?

MetroGnomo currently provides open-source distributed timestamps. At this point, users can obtain as many timestamps as they wish at no cost. If Z/Yen decide to charge or to charge too much, users can create and operate their own versions.

What is the likelihood that a MetroGnomo timestamp would be legally admissible?

At the moment we don’t know. We are discussing with lawyers how this might be admissible. We expect it is likely to be, but first we have to experiment with a variety of applications to ensure robustness.

What is to stop someone timestamping a file that is not theirs? Is there a conflict resolution system?

MetroGnomo timestamps prove that a given requester had the information provided in the tag at the time the timestamp was requested. It is practically impossible for anyone, including Z/Yen, to alter or corrupt the entry once it has left MetroGnomo.

Can someone else stamp a document with my MetroID?

Yes, however MetroID's are not broadcast by MetroGnomo to receivers. MetroGnomo simply issues a MetroID and emails it directly to the address you provide. In the open-source version available at, MetroGnomo maintains a list of MetroID's that have been issued to a given email address at a secure central location. This enables MetroGnomo to remind users of their MetroID's on request.

Alternative versions of MetroGnomo are in use for applications, such as clinical trials, which do not record MetroID's. They simply authenticate a user using the hash of their MetroID. In these versions, the information included in each ledger row is also indecipherable unless the hash of the timestamper's MetroID is known. Consequently, a user can allow a cooperating party to "read" their timestamps without providing the capacity to "write" new timestamps to the ledger.

What is the incentive for people to become independent nodes and hold a copy of the ledger themselves? How do additional nodes affect system integrity?

By becoming a node/receiver, cooperating organisations can hold a copy of the ledger themselves. This allows them to not only to add their own hashing information, but to retrieve this information at a later point independently – for example, if they are worried about the service ceasing. Companies can integrate the proof of existence MetroGnomo provides into existing applications by implementing MetroGnomo Barebones (e.g. to automatically request a stamp when a contract is issued/settled) in combination with their own receivers (e.g. to collect stamps issued by all employees and form an audit trail). Commercial versions of MetroGnomo allow companies to automatically extract their own timestamps from the complete ledger.

Furthermore, users mutually benefit from the addition of more receivers as every receive strengthens resilience and proof of validity. This is because the more copies of the ledger there are, the more difficult it becomes to corrupt or alter the system in its entirety.

How can MetroGnomo be integrated into existing applications? What is MetroGnomo Barebones?

Users interact with MetroGnomo in four core ways: they request MetroIDs, they request timestamps using a MetroID, they can request an email listing their current MetroIDs and advanced users can run a receiver (allowing them to hold a copy of the ledger). None of these basic interactions require the use of the MetroGnomo website. Although, the website’s “Check Stamp” and “Retrieve File” functionality utilise Z/Yen’s publicly accessible storage facility, similar tools can easily be built around a user’s independent receiver.

MetroGnomo Barebones simply refers to the three API’s required to accomplish the first three above mentioned basic interactions with MetroGnomo. These are:

  1. Request a MetroID:
  2. Request a timestamp:
  3. Request a list of MetroIDs attached to an email address:

These three API can be integrated into existing applications, providing third party proof that a given action occurred or slice of information existed. The action itself, described in the timestamp’s tag, need not be disclosed (e.g. through hashing). For example, an application could automatically request a MetroGnomo timestamp whenever a new insurance contract is agreed, or when a payment is made to settle a financial contract.

Those wishing to host a receiver should contact the MetroGnomo team.

MetroGnomo utilises a “light, fast, and inexpensive system”, what does this mean?

MetroGnomo’s underlying ChainZy Technology allows for an agnostic broadcasting based validation mechanism. When a user requests a timestamp, MetroGnomo simply broadcasts the timestamp to any receivers that are ‘listening’. MetroGnomo neither knows nor cares which receivers are listening. In combination with the very limited size (number of bytes) of each timestamp, this reduces the amount of computing power required to run the system.

MetroGnomo’s underlying code is also incredibly simple – approximately 100 lines. This makes it easy and cheap to audit by an interested party, as well as helping to increase the speed of the system.

What happens if a server goes down?

We run multiple receivers in different locations that collect ledger entries. If one server goes down for a period any ledger entries can be collected from the other receivers. MetroGnomo guarantees that MetroTimes and UUID will not collide. Independent receivers add to robustness.

What is a hash?

A hash function takes any arbitrary binary data (text, image, audio, video file or anything else stored on a computer) and maps it to a value of a certain length (called a hash value or hash). Whilst the same file should always generate the same hash, a file cannot be regenerated from its hash.

MetroGnomo uses SHA256 hashes, as defined in FIPS 180-4.

What is type of Unique Universal Identifier (UUID) does MetroGnomo employ?

MetroGnomo utilises standard version 4 UUIDs based on RFC 4122. A version 4 UUID is a 128 bit value comprising of blocks of hexadecimal digits separated by hyphens.