@@ -581,3 +581,28 @@ The ERC20-K semantics is now complete, so we can close the module:
581
581
``` {.k}
582
582
endmodule
583
583
```
584
+
585
+ ## 4 How To Use ERC20-K
586
+
587
+ One way to use ERC20-K, illustrated in [ tests] ( tests ) , is to import it in
588
+ other programming language semantics and thus offer ERC20 support to those
589
+ languages.
590
+ In particular, this can be useful to test the ERC20-K specification
591
+ programmatically, as well as for producing tests that can be then used with
592
+ implementations of ERC20.
593
+
594
+ Another way to use ERC20-K is as a standard for ERC20 compliance.
595
+ That is, as an answer to * what* needs to be proved about a smart contract
596
+ claiming to implement an ERC20 token.
597
+ Each of the rules above is one reachability claim that needs to be proved.
598
+ Several of them have been proved as part of the
599
+ [ KEVM] ( https://github.com/kframework/evm-semantics ) project about
600
+ Solidity and Viper implementations of ERC20 tokens,
601
+ and all of them are planned to be proved for a forthcoming ERC20 token
602
+ implementation in [ IELE] ( https://github.com/runtimeverification/iele-semantics/ ) .
603
+ Indeed, note that the ERC20-K specification above, unlike the original ERC20
604
+ standard, is not bound to the EVM anymore.
605
+ Finally, since the programming languages in which the tokens are implemented
606
+ may have not been given a semantics in the same style as our [ tests/imp] ( tests/imp )
607
+ by importing the ERC20-K configuration, a mapping of ERC20-K configurations
608
+ into the target language configuration may need to be separately defined.
0 commit comments