ilyar

Electronic Passport (eMRTD) NFC CHIP01-52CN Chip

Application Software Developer Guide

Version: 1.0
Date: 2026-03-23
Based on: ICAO Doc 9303, 8th Edition (2021), Parts 9, 10, 11, 12 incorporating Amendments No.1 (2024) and No.2 (2026)

Table of Contents

ilyar

#!/usr/bin/env bash

# Install llama.cpp prebuilt binaries from GitHub releases https://github.com/ggml-org/llama.cpp/releases
#
# curl -fsSL <URL_RAW> | bash
#
# Supports:
# - macOS (arm64/x64)
# - Linux Ubuntu (x64/s390x, cpu/vulkan/rocm7.2)
# - Windows (cpu/cuda12.4/cuda13.1/vulkan/sycl/hip/opencl-adreno)

ilyar

name	prd
description	Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.

PRD Generator

Create detailed Product Requirements Documents that are clear, actionable, and suitable for implementation.

---

ilyar

Draft

Improved signature verification for TON L2 networks

The appearance of new networks in which a user can reuse the same key for the same contracts carries new risks. The proposed solution allows using same keys and contracts across different L2 networks without worrying about new replay attacks, as the signatures themselves will be different everywhere and will depend on a unique network ID (later referred to as global_id).

Most contracts verify the signature of external message with CHKSIGNU or CHKSIGNS. Therefore, to minimize the number of any changes, we propose adding new behavior for these opcodes (enabled/disabled via capability). Fow now, this new behavior can only be implemented on the L2 side, however, it requires at least the reservation of three additional opcodes, which are needed for explicit verification of signatures with other ids.

VM state changes

ilyar

Cell research

benchmark @ton/core vs @incubare/cell

> @incubare/[email protected] benchmark
> npx tsx benchmark.ts

=== @incubare/cell ===

Iterations: 100,000

ilyar

// npx ts-node hex-to-boc.ts

import { BitReader, BitString, Builder, Slice } from "@ton/core";

async function main() {
    const data = Buffer.from('000000000000000000000000000000000000000000000000000000000000002a', 'hex');
    const bs = new BitString(data, 0, data.length * 8);
    const r = new BitReader(bs);
    const s = new Slice(r, []);
    const b = new Builder();

ilyar

Tutorial collect contract gas metric

PR: ton-community/ton-docs#1294

When writing contracts for the TON blockchain, it's important to consider how efficiently gas is consumed when executing the logic you implement, in addition, unlike other blockchains, in the TON blockchain you need to pay for storing contract data and for forward messages between contracts

Therefore, when developing a contract, it's important to pay attention to how data size changes and how gas consumption changes after you modify the contract's behavior or add new functionality

ilyar

#!/usr/bin/env bash

# tonup - TON toolchain versions manager
# INSTALL
# wget -O tonup.sh https://gist.githubusercontent.com/ilyar/ec7f560d4632cb09a319d60f75a518a2/raw/6ad10f2e33dad7f138cefee441c0ba2dcb83d182/tonup.sh
# cp tonup.sh ~/bin/tonup && chmod +x ~/bin/tonup
# SETUP
# export PATH="$HOME/bin-ton/current:$PATH"

set -eo pipefail # https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_pipefail/

ilyar

{
  "comment": "Some label",
  "createdAt": "2025-05-07T19:07:22.277Z",
  "items": [
    {
      "address": "EQBiA46W-PQaaZZNFIDglnVknV9CR6J5hs81bSv70FwfNTrD",
      "codeHash": "0xd992502b94ea96e7b34e5d62ffb0c6fc73d78b3e61f11f0848fb3a1eb1afc912",
      "contractName": "TreasuryContract",
      "methodName": "send",
      "receiver": "external-in",

ilyar

Sample parsing a payload via TL-B

Short

Create schema.tlb

a a: int256 = A;
b b: MsgAddressInt = B;