# Ic-py Development and Ongoing Maintenance

**URL:** <https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455>\
**Category:** Developers\
**Tags:** Discussing, agent\
**Created:** [May 8, 2025, 8:54am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455 "2025-05-08T08:54:35Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [September 9, 2025, 3:33pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/41 "2025-09-09T15:33:06Z")

</div>

📢 **icp-py-core Release Update**

After community discussion, the new Python SDK repository has been officially named **icp-py-core** to align with the style of icp-js-core and unify developer tooling across ecosystems.

The first release, **v1.0.0** , will soon be published on PyPI. Over time, the project will be restructured into a modular format (candid, identity, agent), mirroring the organization of icp-js-core for better maintainability and consistency.

Stay tuned for the PyPI release announcement! 🚀

---

<div class="post-metadata">

**Author:** ![icpp](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpp/32/9310_2.png) [@icpp](https://forum.dfinity.org/u/icpp)\
**Post date:** [September 15, 2025, 2:21pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/42 "2025-09-15T14:21:45Z")

</div>

@C-B-Elite ,  
I have a question about the two different approaches available:

1. Define a canister instance
2. Define an agent instance

The canister instance approach is very convenient and I typically prefer that, but I ran into some problems sometimes and had to fall back to the agent approach.

What approach do you recommend?

Will the canister instance capability be further maintained? I once tried to understand how it was created but it is very complicated…

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [September 15, 2025, 2:52pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/43 "2025-09-15T14:52:29Z")

</div>

> [@icpp](#):
>
> Will the canister instance capability be further maintained? I once tried to understand how it was created but it is very complicated…

Thank you for your question,

1. In icp-py-core, both Agent and Canister forms of interaction with the Internet Computer will be kept.
2. Currently, the implementation of Canister (inherited from ic-py) is very minimal, and there are known bugs when importing Candid and interacting with canisters. Because of this, for the upcoming release of icp-py-core this week, I recommend prioritizing the use of Agent for canister interaction.
3. In the next stages of maintenance, I will first focus on fixing the bugs related to using **Canister** as an instance to interact with the IC. After that, I will expand the feature set, including but not limited to more complete support for canister status and other IC functionalities.

By the way, I’m currently in the process of reorganizing the ic-py project structure into the proper base framework for icp-py-core. This restructuring work will be completed within this week, after which I will publish icp-py-core to PyPI.

---

<div class="post-metadata">

**Author:** ![icpp](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpp/32/9310_2.png) [@icpp](https://forum.dfinity.org/u/icpp)\
**Post date:** [September 16, 2025, 8:44pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/44 "2025-09-16T20:44:04Z")

</div>

Regarding the Canister instance, I have one particular issue that I like to submit. What is the best place to do that?

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [September 17, 2025, 8:08am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/45 "2025-09-17T08:08:08Z")

</div>

Submit your issue here:

> **[eliezhao/icp-py-core](https://github.com/eliezhao/icp-py-core/issues)**
>
> Contribute to eliezhao/icp-py-core development by creating an account on GitHub.

It’s best to include the relevant code snippet that demonstrates the problem.

---

<div class="post-metadata">

**Author:** ![marc0olo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/marc0olo/32/17290_2.png) [@marc0olo](https://forum.dfinity.org/u/marc0olo)\
**Post date:** [September 17, 2025, 8:45am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/46 "2025-09-17T08:45:09Z")

</div>

once the new release is published on PyPi, please also provide a PR to [GitHub - dfinity/awesome-internet-computer: A curated list of awesome projects and resources relating to the Internet Computer Protocol](https://github.com/dfinity/awesome-internet-computer) 🙏

I think it would be reasonable to replace the old agent and give the original author some credit in the readme of your new repo 🙂

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [September 25, 2025, 9:27am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/47 "2025-09-25T09:27:01Z")

</div>

While working on icp-py-core, I found that refactoring the original project structure has taken more time than I initially expected, which caused the release to be delayed. Based on the current progress, I should be able to complete the refactoring and publish icp-py-core this week.

I’ve also renamed some of the original ic-py API interfaces in icp-py-core to better align with icp-js-core and Rust’s agent-rs. This is to reduce the risk of major breaking changes to the interface in the future.

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [October 10, 2025, 4:14am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/48 "2025-10-10T04:14:50Z")

</div>

I took a short break last week (I probably should have posted this before taking the break). I’m now back from vacation and will be pushing forward with progress as quickly as possible.

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [October 20, 2025, 3:37pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/49 "2025-10-20T15:37:15Z")

</div>

# 🎉 Release Announcement: icp-py-core v1.0.0 — First Stable Version

**Release Date:** 2025-10-20  
**Author:** Elie Zhao

> `icp-py-core` is a modernized and actively maintained fork of `ic-py`, fully compatible with **Internet Computer Boundary Node v3** endpoints and offering a more developer-friendly Python Agent API.

* * *

## 🚀 Overview

This is the **first stable release** (`v1.0.0`) of `icp-py-core`.  
It introduces a modular architecture, improved reliability, optional BLS certificate verification, and full API parity with the Rust/TypeScript IC Agents.

**Highlights:**

- Modular architecture (`src/` with separate subpackages: agent / identity / candid / principal / certificate)
- Unified import entrypoint `icp_core`
- Updated BN v3 endpoint `/api/v3/canister/.../call`
- New `Agent.update()` and `Agent.query()` with auto Candid encoding
- Optional **certificate verification** via `blst` (recommended for production)

* * *

## 📦 Installation

```bash
pip install icp-py-core

```

> Requires Python 3.9+.  
> To enable certificate verification, follow the `blst` installation guide in the README.

* * *

## ✨ Quick Start Example

```python
from icp_core import Agent, Client, Identity, Types

iden = Identity() # or from private key: Identity(privkey="hex...")
client = Client("https://ic0.app")
agent = Agent(iden, client)

# Update: auto Candid encoding for non-bytes arguments
agent.update("wcrzb-2qaaa-aaaap-qhpgq-cai", "set", [{'type': Types.Nat, 'value': 2}],
             verify_certificate=True)

# Query: auto-encodes empty args when None or []
res = agent.query("wcrzb-2qaaa-aaaap-qhpgq-cai", "get", None, return_type=[Types.Nat])
print(res)

```

> Setting `verify_certificate=True` performs BLS verification on the response — recommended for production.

* * *

## 🧩 Key Improvements

### 1) Modular Architecture

```auto
src/
├── icp_agent/ # Agent & HTTP client
├── icp_identity/ # Identity (ed25519, secp256k1)
├── icp_candid/ # Candid encoder/decoder & parser
├── icp_principal/ # Principal utilities (strict DER mode)
├── icp_certificate/ # Certificate verification (BLS12-381)
├── icp_core/ # Unified import facade

```

### 2) Unified Facade: `icp_core`

```python
from icp_core import Agent, Client, Identity, Principal, Certificate, encode, decode, Types

```

### 3) Agent API Modernization

- New `Agent.update()` and `Agent.query()` methods (aligned with Rust/TS IC Agents)
- Automatic Candid encoding (non-bytes args auto-encoded, bytes passed through directly)

### 4) Enhanced Identity Management

- Unified support for Ed25519 and Secp256k1
- Added SLIP-10 deterministic derivation (replacing legacy derivation)
- Improved PEM/DER handling and added comprehensive tests

### 5) Strict Principal Validation

- `Principal.self_authenticating()` now **accepts only DER format** for stronger compliance and security

### 6) Improved Polling and Error Handling

- Added exponential backoff with configurable delay, max interval, and timeout
- `poll()` and `poll_and_wait()` now mirror Rust Agent semantics
- Enhanced error messages and handling for malformed or partial responses

### 7) Candid Parser Fixes

- Pinned `antlr4-python3-runtime==4.9.3` to resolve ATN version mismatch
- Updated parser imports for compatibility

### 8) Packaging Modernization

- Adopted PEP 621-compliant `pyproject.toml` (replacing setup.py)
- Clean `MANIFEST.in` (excludes `.venv-test`, `tests`, `.git`)
- Runtime deps: `httpx`, `cbor2`, `leb128`, `ecdsa`, `PyNaCl`
- Optional dependency: `blst` (for certificate verification)

* * *

## 🔄 Migration from ic-py

- Unified entrypoint:  
`from icp_core import Agent, Client, Identity, encode, decode, Types, Principal, Certificate`
- Subpackage imports also supported: `icp_agent`, `icp_identity`, `icp_candid`, `icp_principal`, `icp_certificate`
- `update()` and `query()` now automatically Candid-encode arguments (no manual `encode()` required)

See **MIGRATION.md** in the repository for detailed mapping.

* * *

## 🧪 Stability and Security

- Certificate verification is **optional** but strongly recommended for production use (`verify_certificate=True`)
- Verification uses the **BLS12-381** cryptographic scheme via `blst` bindings

* * *

## 🗺 Roadmap

**Completed:**

- ✅ Milestone 1 — v3 Endpoint Migration & Polling Stability
- ✅ Milestone 2 — BLS Certificate Verification

**Next Steps:**

- 🧠 Candid type-system enhancements
- 🔁 Dynamic routing between boundary nodes
- 💱 ICRC helpers and token canister wrappers

Full roadmap available in **ROADMAP.md**.

* * *

## 🔗 Links

- **PyPI** : [https://pypi.org/project/icp-py-core/](https://pypi.org/project/icp-py-core/)
- **Release (v1.0.0)**: [https://github.com/eliezhao/icp-py-core/releases/tag/v1.0.0](https://github.com/eliezhao/icp-py-core/releases/tag/v1.0.0)
- **GitHub** : [https://github.com/eliezhao/icp-py-core](https://github.com/eliezhao/icp-py-core)

* * *

## 🙌 Acknowledgments

Thanks to the **DFINITY community** , original **ic-py** contributors, and everyone supporting this ongoing project.  
`icp-py-core` aims to provide a modern, secure, and Pythonic SDK for the Internet Computer.

**Feedback, issues, and PRs are warmly welcome!**

---

<div class="post-metadata">

**Author:** ![icpp](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpp/32/9310_2.png) [@icpp](https://forum.dfinity.org/u/icpp)\
**Post date:** [November 17, 2025, 1:15pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/50 "2025-11-17T13:15:03Z")

</div>

@C-B-Elite  
I reported an issue related to Authenticated Query calls that are not working.  
Also mentioning it here for visibility.

> <https://github.com/eliezhao/icp-py-core/issues/2>
>
> I got errors when trying to use icp-py-core for making authenticated query calls….
> 
> I had Claud Code analyze it, and this is it's conclusion.
> 
> Does this make sense, or am I doing something wrong?
> 
> \---
> 
> \# Bug Report: secp256k1 Signature Format Incorrect
> 
> \## Summary
> The \`icp-py-core\` library incorrectly produces DER-encoded signatures for secp256k1 identities, but the Internet Computer expects raw 64-byte signatures (r||s concatenation). This causes all authenticated query and update calls using secp256k1 identities to fail with "Invalid signature" errors.
> 
> \## Environment
> \- \*\*icp-py-core version\*\*: v1.0.0
> \- \*\*Python version\*\*: 3.12
> \- \*\*Identity type\*\*: secp256k1 (loaded from PEM file exported by \`dfx identity export\`)
> 
> \## Steps to Reproduce
> 
> 1. Create a secp256k1 identity using dfx:
> \`\`\`bash
> dfx identity new test-identity
> dfx identity export test-identity \> identity.pem
> \`\`\`
> 
> 2. Load the identity in Python and attempt to make an authenticated query call:
> \`\`\`python
> from icp\_core import Agent, Client, Identity
> from pathlib import Path
> 
> # Load secp256k1 identity from PEM
> pem\_content = Path('identity.pem').read\_text()
> identity = Identity.from\_pem(pem\_content)
> 
> # Create agent and make query call
> client = Client(url='https://ic0.app')
> agent = Agent(identity, client)
> 
> # Try to call any canister method
> result = agent.query('canister-id', 'method\_name', None)
> \`\`\`
> 
> 3. Observe the error:
> \`\`\`
> HTTP/1.1 400 Bad Request
> Invalid signature: Invalid basic signature: Malformed EcdsaSecp256k1 signature:
> \[3044...\] error: 'SECP256K1 signature must have 64 bytes, got 70.'
> \`\`\`
> 
> \## Expected Behavior
> The signature should be 64 bytes (raw r||s concatenation) and the call should succeed.
> 
> \## Actual Behavior
> The signature is 70-71 bytes (DER-encoded) and the IC rejects it with:
> \`\`\`
> SECP256K1 signature must have 64 bytes, got 70.
> \`\`\`
> 
> \## Root Cause
> In \`/src/icp\_identity/identity.py\`, line 203, the \`sign()\` method uses \`sigencode\_der\_canonize\`:
> 
> \`\`\`python
> if self.key\_type == "secp256k1":
> sig = self.sk.sign(
> msg,
> hashfunc=hashlib.sha256,
> sigencode=ecdsa\_util.sigencode\_der\_canonize, # ❌ WRONG - produces DER encoding
> )
> return (self.\_der\_pubkey, sig)
> \`\`\`
> 
> According to the \[IC Interface Specification\](https://internetcomputer.org/docs/references/ic-interface-spec):
> 
> \> \*\*ECDSA signatures\*\*: The signatures are encoded as the concatenation of the 32-byte big endian encodings of the two values \_r\_ and \_s\_.
> 
> This means secp256k1 signatures must be \*\*64 bytes\*\* (32 bytes for r + 32 bytes for s), not DER-encoded.
> 
> \## Proposed Fix
> Change line 203 from \`sigencode\_der\_canonize\` to \`sigencode\_string\_canonize\`:
> 
> \`\`\`python
> if self.key\_type == "secp256k1":
> sig = self.sk.sign(
> msg,
> hashfunc=hashlib.sha256,
> sigencode=ecdsa\_util.sigencode\_string\_canonize, # ✅ CORRECT - produces 64-byte raw r||s
> )
> return (self.\_der\_pubkey, sig)
> \`\`\`
> 
> The docstring on line 190 should also be updated:
> 
> \*\*Before:\*\*
> \`\`\`python
> """
> Returns (der\_pubkey, signature).
> - Ed25519: 64-byte signature over raw message.
> - secp256k1: DER-encoded ECDSA signature over SHA-256(message), canonical low-S.
> """
> \`\`\`
> 
> \*\*After:\*\*
> \`\`\`python
> """
> Returns (der\_pubkey, signature).
> - Ed25519: 64-byte signature over raw message.
> - secp256k1: 64-byte raw ECDSA signature (r||s) over SHA-256(message), canonical low-S.
> """
> \`\`\`
> 
> \## Verification
> After applying the fix, the signature length becomes 64 bytes and authenticated calls succeed:
> 
> \`\`\`python
> \# Test the signature format
> test\_msg = b'test message'
> der\_pubkey, sig = identity.sign(test\_msg)
> print(f'Signature length: {len(sig)} bytes') # Should print: 64 bytes
> \`\`\`
> 
> \## Additional Context
> \- The \`sigencode\_string\_canonize\` function still enforces canonical low-S signatures (required by IC)
> \- Ed25519 signatures are already correctly formatted (64 bytes)
> \- This bug affects all secp256k1 identities, which are the default type created by \`dfx identity new\`
> \- The verify() method (line 209-228) likely has a corresponding issue with \`sigdecode\_der\` that should be changed to \`sigdecode\_string\`
> 
> \## Impact
> This is a \*\*critical bug\*\* that prevents the library from working with secp256k1 identities on the Internet Computer mainnet. Since secp256k1 is the default identity type created by dfx, this affects most users trying to use this library with dfx-generated identities.
> 
> \## References
> \- \[IC Interface Specification - Signatures\](https://internetcomputer.org/docs/references/ic-interface-spec)
> \- \[Python ecdsa library - sigencode functions\](https://github.com/tlsfuzzer/python-ecdsa)
> \- \[@dfinity/identity-secp256k1\](https://www.npmjs.com/package/@dfinity/identity-secp256k1) - Reference implementation using raw signatures

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [November 18, 2025, 8:37am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/51 "2025-11-18T08:37:33Z")

</div>

If everything in the PR looks good, the fix will be included in the next release. I’m currently working on some other features as well.

Thanks for your contribution!

---

<div class="post-metadata">

**Author:** ![icpp](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpp/32/9310_2.png) [@icpp](https://forum.dfinity.org/u/icpp)\
**Post date:** [November 20, 2025, 1:51am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/52 "2025-11-20T01:51:41Z")

</div>

Hey @C-B-Elite ,  
I want to thank you again for taking up this project and shoutout to the first release.

We have successfully upgraded a part of our off-chain monitoring service for funnAI from using a wrapped dfx command via subprocess to using an Agent via icp-py-core. This is a django/celery based application, so having a maintained python agent was really important.

It interacts with some really complex interfaces (variants of records with complex opt fields) and it all works great.

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [November 24, 2025, 9:39am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/53 "2025-11-24T09:39:32Z")

</div>

Hi, thank you for submitting the two PRs, and thanks for your recognition and contributions to icp-py-core.

There are still a few issues in the detailed implementation of the PRs, and since my local changes have diverged quite a bit from the remote repository, I’ve decided to merge your PRs into the main repo first. I’ll further refine and optimize the modified parts afterward.

Thanks again for your contribution!

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [December 1, 2025, 12:12pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/54 "2025-12-01T12:12:22Z")

</div>

# **🚀 Announcing**

# **icp-py-core v2.0.0**

We are pleased to announce the release of **icp-py-core v2.0.0** , a significant update that brings stronger default security and important reliability fixes for Python developers building on the ICP.

This release includes a breaking change, two critical bug fixes, and several improvements contributed by the community.

A special thanks to **@icpp** for reporting issues, proposing improvements, and contributing to this release.

* * *

## **🔒 Breaking Change: Certification Verification Enabled by Default**

Starting from **v2.0.0** , response **certification verification is now enabled by default** for all query calls.

Previously, certification checks were disabled by default, which meant unverified responses could be consumed without warning. Enabling verification by default ensures that developers receive trusted, certified data unless they explicitly opt out.

If you need the previous behavior (e.g., testing or compatibility):

```auto
client = IcpClient(..., verify_certification=False)

```

Because this change may cause existing code to fail when interacting with canisters that do not provide certified responses, this update is released as a **major version bump**.

* * *

## **🐞 Bug Fixes**

### **1.**

### **Fixed: Missing flag byte in Principal decoding**

An issue where Principal decoding failed due to a missing flag byte has been resolved.

This improvement aligns Principal parsing with expected IC specifications.

Thanks to **@icpp** for reporting the issue.

### **2.**

### **Fixed: Authenticated query calls failing**

An issue causing authenticated query calls to fail unexpectedly has been fixed, restoring correct behavior for identity-based or certified queries.

This problem was also identified with the help of **@icpp**.

* * *

## **📦 Installation & Upgrade**

Upgrade via PyPI:

```auto
pip install --upgrade icp-py-core

```

Or install explicitly:

```auto
pip install icp-py-core==2.0.0

```

PyPI: [Client Challenge](https://pypi.org/project/icp-py-core/)  
Github: [Release v2.0.0 · eliezhao/icp-py-core · GitHub](https://github.com/eliezhao/icp-py-core/releases/tag/v2.0.0)

* * *

## **🤝 Community Acknowledgment**

Once again, thank you @icpp for identifying issues and contributing to the security and correctness of this release.

Community feedback has been essential in moving this library forward.

* * *

## **📚 Feedback & Contributions**

If you encounter any issues or have feature requests, please feel free to open an issue or PR on GitHub.

---

<div class="post-metadata">

**Author:** ![marc0olo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/marc0olo/32/17290_2.png) [@marc0olo](https://forum.dfinity.org/u/marc0olo)\
**Post date:** [December 2, 2025, 8:57am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/55 "2025-12-02T08:57:50Z")

</div>

thanks for the update! 🙂

I just observed that v1.0.0 is still marked as `latest` on GitHub. you might want to tag v2.0.0 as `latest` 😉

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [December 2, 2025, 11:56am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/56 "2025-12-02T11:56:11Z")

</div>

Good catch! I’ve updated it. Thank you!

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [December 10, 2025, 5:27am UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/57 "2025-12-10T05:27:46Z")

</div>

**Update:**

Based on feedback from icp-py-core users, I’m prioritizing improvements to the robustness and stability of the **Candid parser** , as well as enhancements to the **Canister class** implementation.

I’ve been working on fixing vulnerabilities in the current Candid parser, but the existing design is based on a rather fragile approach. Continuing to patch it may make future maintenance increasingly difficult. Because of this, I’m considering adopting a different technical solution. Over the coming days, I’ll be exploring whether this new approach can make the parser more reliable and structurally sound.

This work is expected to take about a week to complete.

---

<div class="post-metadata">

**Author:** ![icpp](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpp/32/9310_2.png) [@icpp](https://forum.dfinity.org/u/icpp)\
**Post date:** [December 16, 2025, 12:56pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/58 "2025-12-16T12:56:31Z")

</div>

Thank you for the focus on the **Canister** class.

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [December 16, 2025, 2:45pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/59 "2025-12-16T14:45:43Z")

</div>

A new and important release is coming very soon — featuring a solid and reliable Candid parser for icp-py-core.

---

<div class="post-metadata">

**Author:** ![C-B-Elite](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/c-b-elite/32/34356_2.png) [@C-B-Elite](https://forum.dfinity.org/u/C-B-Elite)\
**Post date:** [December 16, 2025, 3:22pm UTC](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455/60 "2025-12-16T15:22:18Z")

</div>

# 🚀 icp-py-core v2.1.0 Released

I’m pleased to announce **icp-py-core v2.1.0** , a major release with performance improvements, new features, and comprehensive examples for Python developers building on the Internet Computer.

## 🎯 Most Important Update

The long-standing issue that has troubled developers - where Candid content could not be correctly read and Canister classes could not be properly created - has been completely resolved. The underlying Candid parsing modules have been completely rewritten using a more rigorous approach that fully complies with the Candid specification.

## 📦 Quick Start

```bash

pip install icp-py-core

# or upgrade from v2.0.0:

pip install --upgrade icp-py-core

```

## ⚡ Performance Breakthrough: Rust-Based Candid Parser

**Problem Solved:** The previous Python ANTLR4-based Candid parser was slow and memory-intensive, causing delays when parsing complex DID files.

**Solution:** Migrated to a **Rust-based implementation** using the `candid-parser` crate:

- **Multiple times faster parsing** - Dramatically improved DID file parsing performance

- **Reduced memory usage** - More efficient resource consumption

- **Faster startup** - Quicker canister interface initialization

- **Pre-built binary wheels** - No Rust compiler required for installation

- **Zero breaking changes** - Full backward compatibility with v2.0.0

## 🎯 New Features & Enhancements

### Production-Ready Example Library

**Problem Solved:** Developers needed practical, working examples for common IC operations.

**Solution:** Added a comprehensive set of production-ready examples:

- **`ledger_example.py`** - ICP transfers, balance queries, transaction history

- **`governance_example.py`** - Neuron management, proposals, voting

- **`cycles_wallet_example.py`** - Cycles transfers, wallet operations, canister creation

- **`management_example.py`** - Canister lifecycle management

- **`simple_counter_example.py`** - Basic query/update patterns with error handling

- **`helpers.py`** - Common utility functions and formatted output helpers

All examples include proper error handling and can be used as templates for your projects.

### Complete NNS Governance Implementation

**Problem Solved:** Limited governance functionality made it difficult to interact with NNS programmatically.

**Solution:** Expanded the Governance module from ~218 to **1510 lines** with full NNS interface coverage:

- Complete proposal creation and management

- Full voting functionality with type-safe operations

- Comprehensive neuron management and configuration

- All governance operations now available via Python API

### Improved DID Loader & Canister Module

**Problem Solved:** Complex, hard-to-maintain codebase with unclear error messages.

**Solutions:**

- **New `DIDLoader` class** - Cleaner API with better error messages, recursive type support, and complete service interface parsing

- **Canister module refactored** - Reduced from 1322 to ~112 lines (90%+ reduction) while maintaining full backward compatibility

- Better error handling and dynamic method binding

### Enhanced Testing

- New comprehensive test files: `test_did_loader_comprehensive.py`, `test_parser.py`

- Enhanced `test_candid_comprehensive.py` with 186 new lines

- All 56 tests passing with ~7.3 seconds test duration

## 🔧 Fixes & Improvements

### Enhanced Documentation

**Problem Solved:** Users struggled with `blst` installation for certificate verification.

**Solution:** Added comprehensive installation guide (150+ lines) covering:

- Prerequisites for macOS, Linux (Ubuntu/Debian, Fedora/RHEL), and Windows

- Three installation methods: development, production, and virtual environment

- Complete troubleshooting section

- Installation verification examples

### Critical Bug Fixes

- Fixed `AccountIdentifier` length validation

- Fixed `verify_certificate` default to `True` (matching `Agent.update()` for security)

- Fixed `verify_certificate` extraction from kwargs in Canister methods

- Fixed `pyproject.toml` module-name matching wheel installation

## 📊 What This Release Delivers

- ⚡ **Performance** : Multiple times faster Candid parsing with Rust backend

- 📚 **Examples** : Complete production-ready code library (6 examples)

- 🏛 **Governance** : Full NNS Governance interface implementation (1510 lines)

- 🧹 **Code Quality** : 90%+ reduction in Canister module complexity

- 📖 **Documentation** : Comprehensive installation and usage guides

- ✅ **Reliability** : All 56 tests passing, full backward compatibility

**Technical Highlights:**

- Rust extension with PyO3 bindings (pre-built wheels, no Rust compiler needed)

- Removed ~2000+ lines of legacy ANTLR code

- Net: +1212 lines (41 files changed, +5951 added, -4739 deleted)

## 🔄 Migration from v2.0.0

**No breaking changes!** v2.1.0 is fully backward compatible with v2.0.0. All existing code will continue to work without modification. The performance improvements and new features are additive.

## 🔗 Resources

- **GitHub Releases** : [Releases · eliezhao/icp-py-core · GitHub](https://github.com/eliezhao/icp-py-core/releases)

- **PyPI Package** : [icp-py-core · PyPI](https://pypi.org/project/icp-py-core/)

- **GitHub Repository** : [GitHub - eliezhao/icp-py-core: Python Agent Library for the DFINITY Internet Computer](https://github.com/eliezhao/icp-py-core)

- **Full Changelog** : [icp-py-core/CHANGELOG.md at master · eliezhao/icp-py-core · GitHub](https://github.com/eliezhao/icp-py-core/blob/master/CHANGELOG.md)

- **Examples** : [icp-py-core/examples at master · eliezhao/icp-py-core · GitHub](https://github.com/eliezhao/icp-py-core/tree/master/examples)

## 🙏 Thank You

Thanks to the IC community and all contributors. We’re committed to maintaining a modern, performant Python SDK for the Internet Computer.

[Previous page](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455.md?page=2)

[Next page](https://forum.dfinity.org/t/ic-py-development-and-ongoing-maintenance/47455.md?page=4)
