diff --git a/documentation/trust b/documentation/trust
new file mode 100644
index 0000000..f623657
--- /dev/null
+++ b/documentation/trust
@@ -0,0 +1,40 @@
+Understanding Trust.
+
+A single metadata-file can come from various sources, each with its own
+trust level.
+
+A metadata-file that we get from a website (DNS based) has ultimate trust,
+the data is certainly published by that company.
+So, if you have an spacex.com, and they publish data on their website, this
+is most certainly theirs. And the company has a good reputation. The result
+is High trust.
+If, on the other hand, you download a metadata-file from some website with
+a name that is virtually unknown, we know they published the data, but
+there is no trust gained form that fact. The metadata represented doesn't
+have to be all that valuable. Or even truthful.
+
+What we learn from this thought process is that trust is a chained concept.
+A metadata file's can have ultimate trust, meaning we know for sure who
+wrote it.
+The origin itself may be trustworthy, or they may be scammers.
+
+**A trusted registry for bitcoin cash metadata (BCMR) takes this into
+account and helps user find trust in the data presented.**
+
+Roughly speaking there are two components here.
+
+1. An individual metadata file has high trust if the details it talks about
+are consistent.  The main ways to check this are  a) the website (DNS) it
+is taken from is renowned. Or  b) the metadata refers to an on-chain auth-base
+which we managed to verify to refer back to the metadata file.
+
+2. A category or auth-base can have human set trust.
+Even if 1 is high trust, the token or the on-chain authority may have been
+manually identified to be impersonating others or to push known spam/scam.
+The opposite is true too, a known company can have identified itself as the
+owner and that we can advertise the trust to be higher.
+
+
+In hour generated metadata this is reflected by the (token) category itself
+having a trust, and each metadata file linked having it's own specific
+trust.