Good job, bro! I suggest to host it on explorer.grin.mw as it’s the best explorer for Grin atm.
And will be cool to create some JSON API, so we can provide it to CMC to fix total supply here:

I had contact with them, they said link to “official” domain is needed

yes, it’s an assumption that the cryptography in grin works (you can’t get rid of that assumption, you can only be a bit more sure if you use a different rangeproof/EC code and get the same results, but explorer will never, and shouldn’t have to, do this imo).

imo supply is always uncertain when the amounts are blinded, you just can’t fully verify it no matter what you do (even if you formally verify rangeproof/EC code you just can never guarantee that there’s no bug in code/verification).

Not sure how it is proven that each coinbase is 60 grin. Probably via the range proof. @tromp for a Coinbase output, is it proven to be 60 grin exact, or anything up to 60 grin. Just wondering if there could be something like hidden non-inflation😛.

@trab, @vegycslol is correct. In grin it is verified that the sum of all inputs +outputs (excluding Coinbase) sum to zero.
Calculating supply is as simple as multiplying the number of blocks with 60. However, grin completely relies on the assumption that range proofs (bullet proofs) are correct.
Hence the conservativeness in upgrading to bulletproof++ since it needs to be proven secure.

Rangeproof doesn’t prove exact value, only that it’s > 0 and < 2^64. So miner could create 60 outputs where each contains 1 grin and the block should still be considered valid because I - O still equals 0.

Interesting. So you could create 60 coinbase outputs as long as it does not exceed 60 grin total? Do I understand that correctly?
A yes, I am mixing things, the value is blinded and the range proof only proofs no negative value outputs are created.

The formula to verify grin’s current total supply is Σ UTXO = Σ kernel + offset*G + (height+1)*60e9*H.

I’m assuming monero has some other way to achieve the same, but the point is that supply verification always assumes that the used cryptography code (and its assumptions) work as expected.

It’s probably worthwhile to consider what code is being assumed to be correct. Like this reply here, are we assuming that the math is right? If so, how much math? How complicated is the math? Not all assumptions require equal leaps of faith.