In cardano-db-sync the field you are looking for is most likely ma_tx_mint.policy
Cardano scan may either be explicitly “un-hashing” the policy id, joining to the script table, or relying upon other oracles and databases such as Cardano-NFTs · GitHub to figure out the policy script raw JSON.
For more schema info check the readme: cardano-db-sync/schema.md at master · input-output-hk/cardano-db-sync · GitHub
Awesome! Thank you! running it now… 
Thank you also! Will look into this…
didn’t see before. I was probably still running one of the older releases.
For the record @bwbush is almost always more correct than me. I just wanted to add the possibility of an alternative based on your original inquiry 
The new version 0.5.1.1 extracts Plutus scripts (just the serialized bytes). Here are the unique ones that have run on mainnet so far; additionally, 435 unique Plutus scripts have run on testnet already.
@bwbush, that was a quick implementation. I had a deeper look at your code and I am amazed. How did you come up with all of this? For example the block chain walker function in chain.hs.How did you figure out that the node socket works this way? I guess you read the node source code? How does one go about setting up such endeavor? The node is a big project and navigation of the code is hard, you must have a good overview. You inspired me to read it as well, maybe I can make my own tool someday.
Regarding the blockchain walker, I knew this must be possible because cardano-db-sync needs to do something similar and saw that Cardano.Api.ChainSync probably is the API for that; search on the functions there led me to cardano-client-demo, which provides a skeletal example of iterating blocks. At the time I wrote the script-, address-, and coin-extraction functions, Cardano.API didn’t quite have the functionally to access compiled scripts deeply enough to decompile them, so I figured out how to use the type families to access the ledger spec implementations. In general, cardano-api is the best place to look first because it abstracts the details of modes and eras; under that are the various ledger spec implementations (Byron, Shelley, Allegra, ShelleyMA, Alonzo) that provide more direct access; and then the Ouroboros and Crypto packages are more foundational. Most of the work is navigating the type system, since each entity (like a script) lives as an “any era” type, an era-specific type, its underlying representation on the ledger, and perhaps with language (SimpleScript vs PlutusScript), version (SimpleScriptV1, SimpleScriptV2, PlutusV1), and capability (e.g., TimeLocksInSimpleScriptV2) types. Adding the Plutus-script extraction capability just involved navigating the types, which I was mostly familiar with from previous work.
For me, essential tools are (1) running hoogle locally on the whole Cardano codebase with hyperlinks to the source code, so I can easily search for functions, type signatures, or fragments and then read their implementation, (2) local (find, grep, etc.) or github searches in the Cardano codebase, and (3) Haskell Language Server within vim. Inevitably, one needs to read the source code and experiment a bit. Sometimes it’s possible to test things out in cabal repl or ghci. It’s very informative to read the source code for cardano-cli, cardano-wallet, and cardano-db-sync in addition to delving into the cardano-node, ledger spec, and ouroborous code.
I finally uses your plutus script module in the mantis lib. It neat and it allowed me to get the plutus script of an auction that I wanted to play around with! What I was wondering was what the name of the stored plutus scipts represents on chain, in the simple scripts it was the policy. I didn’t know how to interpret the name for plutus scripts so I just converted all these to an address and used that for further handling. I have another request. Now that I have the script I am also interested in the redeemer and datum format given in transaction that go with the script. I think that the watch functionality can be extend to this data since they handle the TxBody right?
Yes, you should be able to retrieve the redeemer and the datum from the view of TxBody. The format is just BuiltinData, but most contracts encode a Haskell or JSON-like data structure into that CBOR in a straightforward manner. (You can see the serialization of the redeemer and datum on cardanoscan.io, and you can manually decode the hex bytes to see what is in these payloads if you want to poke around to speculate on what current Plutus contracts are doing.)
I could add a feature to the tool to optionally extract datum and redeemer, filtered by script address or transaction ID. If you want to add it, please free free to fork the code and/or submit a pull request.
BTW, the serialized Plutus bytes are difficult to interpret. One could decompile the serialized Plutus bytes back into Plutus Core, but one would need to develop special tools and a lot of patience/perseverance to reverse-engineer the script into something readable. For example, the 30-line Haskell Plutus code for the oracle that I am running complies into 11k lines of pretty-printed Plutus Core.
Actually not anymore?! How can I check the iUSD (minting/burning) script for example?
Same as any other block explorer quest:
Note: It is not required to use a smart contract for fungible tokens!
Also note: I was unable to find any open source code other than what looks like a SOL/BNB scam so if Indigo chose a proprietary implementation there would be a lot more than smart contracts involved.
Final note: I have never used iUSD (or any “stable coins” on any network for that matter)