> For the complete documentation index, see [llms.txt](https://docs.kimlikdao.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kimlikdao.org/lib/ethereum/evm.md).

# evm

Our ethereum module comes with an end to end integrated, fully typed EVM assembler. Using `kimlikdao-lib` one can interact deeply with the ethereum network:

* synthesize and execute one-off EVM scripts (init code) on the fly
* synthesize contracts and deploy them on the fly
* interact with preexisting or freshly deployed contracts

Just like regular programs are composed of functions, in our assembler, programs are composed of `Fragment`s. `Fragment`s are pieces of code which start with some type prerequisites on the EVM stack and provides detailed guarantees on the effects of it on the stack.

For instance the `gas()` method has no prerequisites on the stack, emits a single `Word` without consuming anything from the stack. In our assembler, this is denoted with the type signature

```typescript
gas(): () → Word|0
```

Here are signatures of a few other built-ins:

```typescript
ret(offset, size): (Locn, Size) → |2
sload(key): (Word) → Word|1
sstore(key, value): (Word, Word) → |2
call(gas, address, value, argsOffset, argsSize, retOffset, retSize):
  (Word, Addr, Word, Locn, Size, Locn, Size) → Bool|7
```

So far `Fragment`s may be looking just like functions. The differences start when we start composing `Fragment`s. For instance `call` may behave like the following:

```typescript
call(gas, address, value, 0, 32, retOffset, retSize):
  (Word, Addr, Word, , , Locn, Size) → Bool, Locn|7
```