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
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
ContractNameclass: ergonomic read/write methods that encode calls and decode responsesA
ContractNameUtilshelper class: staticencodeX/decodeXhelpers per functionTuple classes for
tuple/structparams and returnsEvent classes
<EventName>Eventwith a staticdecode(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 codegenreadsmanifest.yamlinputs→src/types/index.tsabis→src/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,timestampOne method per ABI function. Read methods call
environment.contractCall; write methods return anEvmCallBuilderand 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 →
Addressbool →
boolstring →
stringbytes / bytesN →
BytesintN/uintN →
BigIntfor N ≥ 24;i8/u8/i16/u16/i32/u32/i64/u64for smaller widthsArrays 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
internalTypeincludes a struct name (e.g.,struct UserContract.UserInfo), that name is usedOtherwise it falls back to
Tuple<N>For functions with multiple outputs, a synthetic
<FunctionName>Outputsclass is created
Tuple classes provide:
static parse(data: string): <Class>to parse decoded stringstoEvmEncodeParams(): 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
functionandeventABI items are processed; others are ignoredOverloads are supported via numeric suffixes in method names
If a tuple class name cannot be inferred, a warning is emitted and
unknownmay appear in mapped typesGenerated files are meant to be committed; do not edit manually (they include a notice)
Last updated