Deniz Mert Edincik

> it allows us to create a contract dependency graph, for example, which we can use to optimize things like program caches to improve performance I don't have much info...

> If we have a dependency graph though @dsainati1 I think you mean dependency graph of all contracts on chain, not the contract got updated right?

> We would only need to know which contracts are downstream of the one that was updated So we only care about the descendants of the contract. ( contracts that...

@SupunS Very good example with passive invalidation, thanks. Btw I still think programs should be cached separately and linked at runtime. And program cache should be something bounded like LRU...

@dsainati1 @SupunS To prevent this kind of contracts is sufficient benefit alone for me: https://flowscan.org/account/0xeb8cb4c3157d5dac

@turbolent I implemented this ( I hope ), should I make a PR for it and then go over FLIP ? or go over FLIP and then make the PR...

I am pretty noob in this area but tried to make something working. I may have some huge misunderstanding or mistakes there. https://github.com/onflow/cadence/pull/1934

This is very important and was a big security issue. But I think better to reach out people to fix implementations on mainnet before disclosing this ? I am sure...

In my opinion Stack to Stack should be invalid. ( if I understood stack correct, owner=nil ) Though I think they can be valid in the same stack depth.

@SupunS Imagine simple purchase scenario, implemented naively like: ``` pub fun purchase(ftVault: @FT.Vault, receiver: Capability){ pre{ ftVault.balance = self.sellprice } var NFT