Library

The Mimic Protocol Library (@mimicprotocol/lib-ts) is a lightweight standard library for building blockchain automation tasks. It provides typed primitives and safe bindings to create deterministic tasks to interact with multiple blockchain networks.

Why AssemblyScript?

Tasks are written in AssemblyScript (which compiles to WebAssembly) to ensure:

  • Deterministic execution: Same inputs always produce same outputs

  • Portability: Runs consistently across different environments

  • Security: Sandboxed execution with no system access

  • Performance: Near-native execution speed

We're planning to expand language support beyond AssemblyScript to include other WebAssembly-compatible languages like Rust. This will bring more flexibility in how tasks can be written while maintaining all the security and deterministic execution benefits of WebAssembly.


1. Core Concepts

1.1. Intents

Intents are declarations of what you want to happen. Instead of executing transactions directly, you create intents that describe your desired outcome. The protocol then finds the best way to fulfill them.

Three types of intents are available:

  • Call: Execute smart contract functions

  • Swap: Exchange tokens across DEXs

  • Transfer: Move tokens between addresses

1.2. Environment

The Environment provides access to external data and execution capabilities:

  • Price feeds and oracles

  • Token information

  • Contract interactions

  • Intent execution


2. Getting Started

2.1. Installation

2.2. Basic task structure

Every task follows this structure:

2.3. Project setup

Create a basic task project:


3. API Reference

3.1. Core types

3.1.1. Primitives

3.1.2. Tokens and Amounts

3.2. Queries

3.2.1. Price queries

Price queries allow you to retrieve token prices in USD. Results are represented with 18 decimals:

3.2.2. Relevant tokens

The relevant tokens query allows you to find all the token balances for a specific account. Handful filters are provided to restrict chains, tokens allow or deny lists, or minimum USD value:

3.2.3. Contract calls

Contract calls allow you to read contract information from the chain:

Note: there is an easier way to read contract information. See 4.5. Read calls.

3.2.4. Subgraph queries

Subgraph queries allow you to read information from subgraphs:

3.2.5. Context

The context query tells the current execution context for the task. This includes user, settler, timestamp, and config ID:

3.3. Intent builders

3.3.1. Transfer

Move tokens between addresses:

3.3.2. Swap

Exchange tokens across DEXs:

3.3.3. Call

Execute smart contract functions:

3.4. EVM Utilities


4. Using generated ABI wrappers

If you are using mimic codegen to generate contract wrappers, refer to the ABI wrappers guide for how read/write methods, tuple classes, arrays, and events are produced and used:

mimic codegen generates strongly-typed AssemblyScript wrappers for your contract ABIs. For every ABI declared in your manifest.yaml, it emits a file src/types/<ContractName>.ts that includes:

  • A ContractName class: ergonomic read/write methods that encode calls and decode responses

  • A ContractNameUtils helper class: static encodeX/decodeX helpers per function

  • Tuple classes for tuple/struct params and returns

  • Event classes <EventName>Event with a static decode(topics, data)

The generated code targets @mimicprotocol/lib-ts primitives and utilities: Address, BigInt, Bytes, environment, evm, EvmCallBuilder, EvmEncodeParam, EvmDecodeParam.

4.1. When it runs

  • mimic codegen reads manifest.yaml

    • inputssrc/types/index.ts

    • abissrc/types/<ContractName>.ts

Example manifest excerpt:

4.2. Generated class layout

Every contract file exports export class <ContractName> with:

  • Constructor: (address: Address, chainId: ChainId, timestamp: Date | null = null)

  • Getters: address, chainId, timestamp

  • One method per ABI function. Read methods call environment.contractCall; write methods return an EvmCallBuilder and never call the environment directly.

Additionally, export class <ContractName>Utils exposes encode<Fn> and decode<Fn> helpers used by the main class.

4.3. Type mapping rules

  • address → Address

  • bool → bool

  • string → string

  • bytes / bytesN → Bytes

  • intN/uintN → BigInt for N ≥ 24; i8/u8/i16/u16/i32/u32/i64/u64 for smaller widths

  • Arrays preserve depth: address[][]Address[][]

  • Tuples generate classes; arrays of tuples become arrays of those classes

Unknown or unextracted tuple types are conservatively mapped to unknown (and a warning may be emitted during generation).

4.4. Method naming and overloading

  • Functions keep their ABI name; reserved words are suffixed with _ (e.g., constructor_).

  • Overloads are suffixed incrementally: _1, _2, ...

  • Capitalized names are used in helpers: encodeGetBalance, decodeGetBalance.

4.5. Read calls

Read methods perform: encode → environment.contractCall → decode.

Void-returning reads just perform the call without decoding.

4.6. Write calls

Write methods return an EvmCallBuilder so you can compose multiple calls and send them via intents later.

Encoding converts primitives as needed:

4.7. Tuples and structs

The generator extracts tuple/struct definitions from inputs, outputs, and multi-return functions.

  • If internalType includes a struct name (e.g., struct UserContract.UserInfo), that name is used

  • Otherwise it falls back to Tuple<N>

  • For functions with multiple outputs, a synthetic <FunctionName>Outputs class is created

Tuple classes provide:

  • static parse(data: string): <Class> to parse decoded strings

  • toEvmEncodeParams(): EvmEncodeParam[] for encoding

4.8. Arrays and nested arrays

Arrays are supported at any depth for both params and returns. Encoding/decoding uses JSON strings under the hood for nested structures and handles empty arrays.

4.9. Events

For each event, <EventName>Event is generated with a static decode(topics: string[], data: string).

Indexed parameters are decoded from topics[1..]; non-indexed parameters are decoded from data. For multiple non-indexed params, the data is treated as an encoded tuple.

4.10. Imports and dependencies

Imports are automatically deduplicated and sorted based on what your ABI requires. Typical imports include:

You do not need to manage these imports manually; they are generated with the file.

4.11. Example

Given this ABI excerpt:

You can write:

4.12. Notes and limitations

  • Only function and event ABI items are processed; others are ignored

  • Overloads are supported via numeric suffixes in method names

  • If a tuple class name cannot be inferred, a warning is emitted and unknown may appear in mapped types

  • Generated files are meant to be committed; do not edit manually (they include a notice)

Last updated