### FV Resources These are few and far between. My paper on it is soup to nuts for how we do it in Pact which, while technical, should be somewhat approachable for most devs to grasp (I tried at least -- representing a program as equations is just an abstract concept). Until it comes out, the best one I've found as an entry point was the approach they use in Cryptol: ▶ this video . Cryptol, generally is a great project to look to for guidance. We're not going with the interactive approach. An EDSL in the docstrings is our approach so that you can pull a contract from the chain (pact is interpreted so the code on chain is the code that executes... well after it gets inlined and validated) and do the verification for yourself. Pact inlines at module creation/update time as a safety feature -- this way if a dep upgrades the code your contract runs doesn't change though the dep can revoke your code's right to access its tables/data until you update your contract. The "no leftpad" approach to deps. All the imported code that's pure, however, still works. This way, when you are building a module, you know that the code you formally verified/tested against is the only code that will ever run (until you update it). ### Whitepapers Thanks for the offer but I've already got enough people looking at them currently and we're keeping them confidential for now... a glaring stupid mistake would be embarrassing. Subscribe to the mailing list on kadena.io and you'll get updated with them the secon
in “Show HN: Dharma – Programmable Peer-To-Peer Loans Using Ethereum Smart Contracts” · View on HN