Let's take a look at Djed on-chain

So, let’s look at one we can see of Djed in Cardanoscan:

The main contract is: https://cardanoscan.io/address/addr1z8ru2k4eqtwrf95fvmgxu04pugezz7xg8l3jrrq9mhgh5agm5kjdmrpmng059yellupyvwgay2v0lz6663swmds7hp0q4jak04

DJED and SHEN Tokens

There are almost a trillion of “DjedMicroUSD” and “ShenMicroUSD” in this contract. They have been pre-minted and are not minted and burned during the operation of Djed. So, if the Djed paper https://iohk.io/en/research/library/papers/djed-a-formally-verified-crypto-backed-pegged-algorithmic-stablecoin/ talks about “minting” and “burning”, in this implementation it is rather given out by the contract address and given back to the contract address.

If we look at their policy https://cardanoscan.io/tokenPolicy/8db269c3ec630e06ae29f74bc39edd1f87c819f1056206e879a1cd61, we see a very uninformative total supply of one trillion each. To get the real circulating DJED and SHEN we have to subtract the tokens residing on the contract address from this. And we arrive at roughly 750 000 DJED and roughly 9.2 million SHEN circulating at the time of writing (probably already more at the time of publishing).

There is also a “DjedStableCoinNFT”, minted under the same policy and also held by the contract address, which is probably a technicality needed by one of the Plutus scripts.

Stake Address

The contract address belongs to the stake https://cardanoscan.io/stakeKey/stake1uyd6tfxa3sae586zjvll7qjx8ywj9x8l3dddgc8dkc0tshssd5g6e, which is delegated to the pool WAV1 https://cardanoscan.io/pool/e985b5698de1386439e62b5b7ab2cc9f814b91b4a1fef5970f38694d. As announced in https://cotinetwork.medium.com/djed-update-economics-of-the-djed-stablecoin-and-delegation-rewards-53f732851b29 and https://cotinetwork.medium.com/djed-update-jan-30th-c64ed7099728, it is a pool managed by Wave.

Up to a few epochs ago, it was a private pool with 100% margin. Then, it was first set to 8% and then to 5% consistent with the announcements by COTI. I don’t know why they didn’t just use a private pool with a deal with the pool operator.

There are two more addresses with funds on them that belong to the same stake: https://cardanoscan.io/address/addr1q9qf60kgctthflcakjyufu2z39qcy80cr7lz3gk4uvf4f6qm5kjdmrpmng059yellupyvwgay2v0lz6663swmds7hp0q8v9ugf, which holds the collected operational fees which will be converted to COTI and put in their treasury from time to time, and https://cardanoscan.io/address/addr1q8sefdq99nlv0wefzprjvp5h9mw2l3jvhvgy4tl20kszdlcm5kjdmrpmng059yellupyvwgay2v0lz6663swmds7hp0q8dklg8, which pays for the updates of the oracle (I’d guess, they plan to refill this address from time to time, since the transaction fees will slowly deplete it).


The oracle lives on the contract address https://cardanoscan.io/address/addr1wxxx5uc8t8mphyyf7qmse7vx5fm469puha6uru06djfj4vql8unkl and is updated roughly every 12 minutes.

In such an update transaction, we see the datum living at the only UTxO of that address to be updated: https://cardanoscan.io/transaction/58b6e3ecc266b9e1e8cdd7f87aa3da3c519e7482e7eed6220c33c8f71721ce31?tab=contracts

In a quick analysis, I couldn’t find out what format this datum is in. Doesn’t seem to be ASCII, UTF-8, or CBOR, as far as I can see.

Orders and Batching

If you place an order on djed.xyz, you sign a transaction to the contract address https://cardanoscan.io/address/addr1wxy49hzx86ch868hr3uz98lqw8p7ef55j6x8ras7udy3a0gm8cdla which serves as an order queue, which is then processed by transactions involving the “real” reserve address.


In all of these examples you can see the changes on the main contract address as well as 100 ADA each operational fee going out to the contract address https://cardanoscan.io/address/addr1wx8vgeyxzyrm9qu6ju9fh4useecga8njlwtmqa2357luj3clkzzzx. From that address, they are periodically forwarded in transactions like https://cardanoscan.io/transaction/83af9af5cea65ecf258c344c5410a6c36bf124a6579a0acd0fda4c064be51de6?tab=utxo to the operational fee collection address we have seen earlier.

Further analysis of the involved contracts and datums should be really interesting.


Thanks alot for those infos here!

Do you see any problems or security issues that $DJED and $SHEN is already preminted and is not mint/burnt by demand?

Not really, just ugly.


Helpful and thorough analysis of DJED/SHEN, thanks for that.

Can you elaborate on what makes this implementation ‘ugly’ for you? Meaning, what long term negative effects might this implementation have.


“Ugly” does not necessarily mean long-term negative effects.

I don’t think that it’s very nice that the total supply of DJED and SHEN that you see on-chain is this fantasy number and that every mention of “minting” and “burning” in the paper would have to be amended with “well actually we are not minting and burning, we are just giving out and storing away again” to be precise.

There could be problems if this system continues running for a really long time and is successful enough that 1 trillion of either DJED or SHEN is not enough anymore. Rather theoretical and the updates are already planned that maybe remove it again, but I’d still prefer a system that does not have this arbitrary limit in there.

1 Like

I’m curious to inspect the minting policy. If it is not a one-time mint, then that’s a bit scary, because then technically the original minter could just re-mint more Djed, and then buy up all the Ada reserve with it. How to inspect the minting policy? I have been researching with no luck. Also, I’m trying to find how to audit the smart contract to ensure there are no backdoors for draining funds from the pool. Anyone know if there is available source code to compile and check that it matches the on-chain byte code?

I guess it would depend on how the minting policy was set up. I am not an expert but I imagine that the minting policy could be set up so that minted Djed was only delivered to the holding contract with the only way to get Djed out of it being governed by protocol rules?

Can someone please help me find how to inspect the minting policy? Are the policies downloaded from a central registry? All that appears to be stored on chain is the hash, but how to validate the minting transaction? Im guessing the script is offchain, but where to find it??

I figured out how to get started with the audit of Djed’s minting policy:
Reading plutus.readthedocs.io/simple-example.html I found that the compiled minting policy lives within the wallet whose address is the hash of the policy’s source code.

This means that you’d have to de-compile the byte found within address of Djed’s policyID: 8db269c3ec630e06ae29f74bc39edd1f87c819f1056206e879a1cd61

Yes, Coti needs to open-source the smart contracts that implement Djed. Apparently they do plan to do this, but when???

Not really. There are no wallets involved.

The policy ID is the hash of the minting script (much like the address of a spending script is built from its hash).

If a transaction wants to mint or burn tokens under that policy (if it wants to spend from a contract address in the case of spending scripts), it has to give the script in additional data of the transaction (or in a reference input).

Blockchain explorers like Cardanoscan do monitor transactions and can show you the bytecode of the script:

Aiken (https://aiken-lang.org/) can disassemble such bytecodes:

$ aiken uplc unflat -c djed-mint.hex

This results in 5460 lines of untyped Plutus core in djed-mint.uplc. Unfortunately much too complicated to really dig into what it is doing (at least for me).

1 Like

Yea I should have said it lives at the address, not wallet.

I was just about to start decompiling, thank you for providing the information! I will give it a try. I requested policy source from Coti in addition.

1 Like

Djed’s minting transaction contains the following datum on its UTxO.

Isn’t it this datum which is passed as the first argument to the minting policy validation script?