On cardanoscan.io, they are able to show the policy script for any token:
In db-sync however, we can’t find this information. (I could be wrong here)
So I’m assuming this can be resolved/derived from the hashes stored on chain. Can anyone point me to the right direction on how to do this?
Yes, the full script is stored on chain along with the transaction that it witnesses. Here are a couple of approaches to retrieving these:
Thanks for this! …Although Haskell is not very useful to me as of now. still have to learn it.
By any chance, has there been an implementation of the same or a similar process in Python or JS perhaps?
scratch that… I guess I can just compile this tool and make a wrapper for it in JS… 
I don’t know of non-Haskell libraries/tools that read and parse blocks according to the ledger specification, but I imagine that developers are working on such.
Yes, but the tool walks the chain from Epoch 0 to the present (and optionally keeps watching new blocks for scripts). It sounds like your use case requires random access to arbitrary transactions of interest. The tool would have to populate a database or at least an index if you want on-demand fetching of a script from any past transaction.
P.S. The totality of scripts on mainnet so far amounts to about 204 MB of data.
I’ll likely have to do it this way.
Quick question about this:
$ mantra watch-scripts --help
Usage: mantra watch-scripts CONFIG_FILE [--output OUTPUT_DIR]
Download scripts used as transaction witnesses.
Available options:
CONFIG_FILE Path to configuration file.
--output OUTPUT_DIR Output directory for script files.
--continue Whether to continue when the current tip of the chain
is reached.
-h,--help Show this help text
– what happens if I have to stop the app after it has already reached the tip and just watching for new ones; will it go back to epoch 0 when I restart it?
If so, is there a way to make it continue from where it left off?
Yes, a restart will begin at epoch 0.
If you use the --continue flag, the tool will just idle (once it reaches the tip) until new blocks are produced and then output the scripts in those new blocks.
I’m actively improving the tool, so please feel free to suggest even major changes or additions. One feature that I’m planning to add soon is an option to start walking the chain at a slot other than slot 0.
FYI, depending on the machine that you’re running the tool on, it may take about 45 minutes for it to walk through all of the Byron blocks before it starts processing Shelley blocks that have script witnesses. Once it catches up to the tip of the chain, it outputs in real time.
Yes, this is what I mean to ask. Looking forward to this! 
I’ll try to add that restart feature today, and post here when it is ready.
Thank you!
Would be great also to have pre-compiled binary releases… Some of us find the haskell.nix build system a bit too much for quickly trying out these tools.
I’ve been trying to build it with cabal install also. But for some reason, it keeps on giving me this error:
cabal: The program 'ghc-pkg' is required but the version of
/usr/local/bin/ghc-pkg could not be determined.
even though if I manually run /usr/local/bin/ghc-pkg --version, it says it’s at 8.10.4 as expected.
@bwbush You are a legend! The quality of your code and contributions is uncanny! Thank you for sharing this awesome code to the public. Kudos to you sir!
I just released a new version, which includes a --restart flag: it will record the progress of watching and let one restart at that point.
The pre-compilation will take more work and testing because of dependencies on dynamic libraries and the different flavors of Linux distributions—I’ll need to force a completely static build. Meanwhile, there is a small chance that the binary in this tar file might work.
Awesome! thank you so much for this quick addition. 
not a big deal at all… I’ll just figure out the build. 
@bwbush Again I want to thank you this tool, really helpful. I just the watch-script flag and noticed it only records multi sig scripts that mint/burn native assets. Is there also the possibilty to add plutus scripts? I guess its a good meassure of how the progress/adoption of the new era is moving along.
What I like about the tool is its speed. One can of course use the cardano-db-sync to have a sync with the chain but I noticed that this takes up a great deal of resources as it has to use the node-socket continuously. Your tool is streamlined and why store the db twice if you can parse the db of the cardano node.
You’re very welcome. Yes, I’m considering having it export Plutus scripts, too, but these would either be the compiled bytes, which would have limited usefulness since they aren’t human-readable, or Plutus Core, which would be tedious to understand and somewhat opaque (more like assembly language). I might try this just out of curiosity to see how understandable reverse-engineered scripts running on mainnet are.
I agree that it’s not functional to read such scripts but I think it is of value to have a possibility to get scripts directly from the chain. For example, if I want to automate auctioning nfts that are listed on a certain website for others to buy. I want to send bulk transaction via the cli and not the pab. For that you need the script that is not necessary shared by the creator of the script. And via other transactions data the format of the redeemer/datum can be deduced. I hope that this works 
These use cases make sense—I’ll put this on the to-do list for this tool. I think that it would also be convenient to extract the datum, datum hash, and redeemer that have been used with the script in past transactions, but I’ll probably hold off on implementing that.
BTW, I’d want to read the script before purchasing an NFT that was minted with Plutus. I suspect that only the simplest Plutus Core would be easy to quickly understand, however.
Here is a precompiled executable that is very likely to work on Ubuntu systems where libsodium is installed.