diff --git a/polkadot-opengov/README.md b/polkadot-opengov/README.md
new file mode 100644
index 0000000..07beaa8
--- /dev/null
+++ b/polkadot-opengov/README.md
@@ -0,0 +1,406 @@
+# Python Libraries Maintenance & Development
+
+## One Page Executive Summary
+- **Topic**: OpenGov Treasury Discussion & Soft Commitment for Monthly Retroactive Reimbursements for Completed Work for Python Libraries Maintenance & Development
+- **Proposer**: JAMdot Technologies
+- **Category**: Signaling / Framework for Future Retroactive Funding for Completed Work
+- **Start Date**: January 2026
+- **Funding Request**: Retroactive Reimbursement capped to 12.000 EUR per month for completed work
+- **Source**: 
+
+This proposal seeks an OpenGov Treasury soft commitment that, starting January 2026, JAMdot Technologies can submit monthly retroactive reimbursement requests for completed work of the continued maintenance and development of Python libraries used throughout the Polkadot ecosystem.
+
+The intent of this proposal is not to request funds now, but to:
+- Confirm that the Treasury recognizes ongoing Python maintenance as a legitimate, ecosystem-critical activity;
+- Establish a predictable framework for monthly, retroactive reimbursement;
+- Ensure continuity of the long-standing work previously carried out by Polkascan (Web3 Foundation Grant recipient 2018–2020 and Treasury-funded 2020–2024); and
+- Signal that JAMdot Technologies can operate on a monthly retroactive basis for completed work without needing a full governance process for each minor maintenance reimbursement.
+
+This structure is aligned with the Web3 Foundation OpenGov guidelines: it aims to minimize proposal overhead for recurring essential work, while keeping the community fully in control of funding decisions and able to halt or adjust reimbursements if expectations are not met. Full details on this alignment can be found in Appendix 2.
+
+## 1. Background & Rationale
+### 1.1. Role of Python in the Polkadot Ecosystem
+Python is can be used across the Polkadot ecosystem for:
+1. Analytics and research;
+2. Proof-of-concepts and prototyping;
+3. Integration and testing;
+4. Governance and Treasury analytics;
+5. Automation and scripting;
+6. AI / LLM integration;
+7. Desktop applications.
+
+The Python libraries in scope (see Appendix 1) form the primary Python interface to Polkadot, Kusama and Substrate-based networks. They underpin:
+1. Node interaction and RPC access;
+2. SCALE encoding/decoding;
+3. Cryptographic operations (ED25519, SR25519, BIP39);
+4. Application and tooling development around Polkadot.
+
+Without active maintenance and incremental development, these libraries risk falling behind protocol evolution, causing breakage for hundreds of dependent repositories and packages.
+
+### 1.2. Legacy of Polkascan Foundation
+From 2017 onwards, Polkascan played a pioneering role in building open-source tooling around Substrate, Polkadot and Kusama. Between 2018 and 2020, this work was supported by Web3 Foundation Grants and from 2020 to 2024 it was funded via the Polkadot Treasury.
+During this period, the team:
+1. Designed, implemented and maintained the Python Substrate Interface, currently named Python Polkadot SDK (Appendix 1.1);
+2. Created and maintained the Python SCALE codec and cryptographic bindings (Appendix 1.1);
+3. Delivered regular accountability reports to the Treasury (Appendix 2.2);
+4. Supported a growing ecosystem of users and dependent projects (Appendix 2.4).
+
+This established the Python stack as a critical piece of shared infrastructure in the Polkadot ecosystem.
+
+### 1.3. Transition from Polkascan Foundation to JAMdot Technologies
+Late 2024, Polkascan Foundation was unwound. As a result:
+1. The legal and governance structure previously used for Treasury submissions ceased to exist;
+2. Treasury reimbursements for Python library maintenance were discontinued;
+
+The underlying work did not disappear; maintenance continued on a best-effort basis, but without a clear funding model. 
+
+To preserve continuity and avoid losing hard-won expertise, the core engineering team established JAMdot Technologies, with the explicit intent to:
+1. Continue maintenance and development of these Python libraries;
+2. Align this work with emerging priorities such as JAM and PyJAMaz (Python Implementation of JAM);
+
+### 1.4. Why a Soft Commitment for 2026?
+From January 2026 onward, JAMdot Technologies intends to allocate a predictable portion of its senior engineering capacity to Python library maintenance and development. For this to be sustainable, the team needs:
+1. Predictability: a reasonable expectation that monthly retroactive reimbursements are seen as a legitimate use of Treasury funds;
+2. Low overhead: avoiding the need to run a full governance campaign for each minor monthly reimbursement;
+3. Clear expectations: a shared understanding of scope, reporting standards and cost levels.
+
+This proposal therefore asks for a soft, non-binding signal from the OpenGov community that:
+1. Monthly, retroactive reimbursement requests for Python library maintenance and development are acceptable in principle; and
+2. They will be evaluated under the assumption that maintaining these libraries is a valid, ongoing Treasury-funded activity, subject always to community review and veto.
+
+## 2. Scope of Work (Starting January 2026)
+### 2.1. Scope
+The detailed scope and libraries are described in Appendix 1. At a high level, starting January 2026 the work will cover four main activity areas on a recurring basis:
+1. Maintenance and Continuity of Functionality
+  a. Keep the libraries compatible with current Polkadot, Kusama and future JAM networks.
+  b. Track and adapt to runtime upgrades, metadata changes, and RPC/API evolutions.
+  c. Fix bugs and regressions affecting production users and dependent projects.
+2. Addressing Technical Debt
+  a. Refactor and modernize code to reduce complexity and improve maintainability.
+  b. Update internal APIs and structures to align with modern Python practices and tooling.
+  c. Keep in step with new runtime, metadata and cryptography developments to avoid drift.
+3. Enhancing Adoption
+  a. Provide community support via GitHub (issues, discussions, PR reviews).
+  b. Improve documentation, guides and examples to lower onboarding friction.
+  c. Act as a “Python advocate” within the ecosystem, ensuring that Python remains a first-class option for building on Polkadot and future JAM.
+4. Best-Effort Incident & Problem Management
+  a. Triage and provide best-effort response to incidents and critical integration problems reported by ecosystem teams.
+  b. Diagnose, mitigate and, where necessary, prioritize fixes for problems that block or severely hinder adoption or production use.
+
+The monthly retroactive reimbursements will correspond to the actual effort spent across these categories, as evidenced by commits, issues, pull requests, releases and written reports.
+
+### 2.2. Priorities 2026
+In addition to the activity classes outlined in Section 2.1, JAMdot Technologies will focus on a set of targeted engineering priorities during 2026. These priorities address known technical debt, ecosystem requests and forward-looking compatibility needs for Polkadot and JAM.
+
+The priorities for 2026 are:
+1. Light Client First Strategy for Python Polkadot SDK Library: Explore and develop Light Client support for Python Polkadot SDK. Likely by FFI of Smoldot-Light (https://smol-dot.github.io/smoldot/doc-rust/smoldot_light/index.html).
+2. Enhanced Support for Metadata Versions V15 and V16: Expand and harden support for Metadata V15 / V16, ensuring robust compatibility with new runtime layouts and enabling downstream tools to remain functional across upgrades.
+3. Unifying the JAM Codec and Completing Version 2 of SCALE Codec: Finalize the integration of the JAM codec work into the main SCALE codec library and complete the V2 release. This includes redesigning internal abstractions, improving test coverage and ensuring full compatibility with evolving runtime specifications.
+4. Developing an Asynchronous Version of the Python Polkadot SDK: Introduce native async support in py-polkadot-sdk to improve performance, enable concurrency for high-throughput applications and align with modern Python best practices by applying learnings from our JAM research & development work.
+5. Python 3.14 Support Across Cryptographic Bindings: Update remaining bindings (ED25519, SR25519, BIP39) to ensure compatibility with Python 3.14, including adjustments for upstream dependency and interpreter changes.
+6. Security Updates and Dependency Modernization: Apply timely security upgrades to cryptographic and runtime-related dependencies, audit for outdated transitive dependencies and modernize build configurations where appropriate.
+7. Reviewing and Integrating Community Contributions: Systematically address open community pull requests for both py-scale-codec and py-polkadot-sdk: https://github.com/JAMdotTech/py-scale-codec/pulls and https://github.com/JAMdotTech/py-polkadot-sdk/pulls. This includes code review, integration, refactoring where necessary and documentation alignment.
+8. Resolving Community Issues and Questions: Address open GitHub issues across the repositories, many of which relate to edge-case SCALE decoding, metadata parsing and runtime-specific quirks.
+9. AssetHub Helper Functions: Implement helper utilities to simplify working with AssetHub pallets and support the relay-chain balance migration path, enabling ecosystem teams to adapt with minimal disruption.
+10. Improving Code Coverage and Unit Tests: Expand unit test coverage across all Python libraries, with a particular focus on edge cases in codec behavior, extrinsic composition and metadata decoding. This work increases robustness and reduces regression risk during network upgrades.
+
+These priorities collectively strengthen the reliability, performance and long-term sustainability of the Python tooling stack, ensuring that it remains a secure and modern foundation for ecosystem teams during the transition to Polkadot 2.0 and future JAM.
+
+## 3. Proposed Funding Framework
+### 3.1. Mechanism
+The proposed framework is:
+1. JAMdot Technologies performs maintenance and development work during a given calendar month starting January 2026.
+2. At the end of each month (or early in the following month), JAMdot submits a retroactive reimbursement request to the Treasury, including:
+  a. Concise monthly report (scope, highlights, issues resolved);
+  b. References to commits, releases, issues and pull requests;
+  c. Itemized overview of effort (hours) and associated reimbursement.
+3. The Treasury and community evaluate the request against:
+  a. Agreed scope (Section 2 and Appendix 1);
+  b. Standards for expertise, accountability, cost-effectiveness and ecosystem value (Appendix 2);
+  c. Community sentiment and any relevant feedback.
+
+This process ensures that no funds are requested in advance. The Treasury only reimburses work that has already been delivered, and retains the full ability to reject or adjust any monthly request.
+
+### 3.2. Target Level and Rate
+The intention is to work towards a structural reimbursement level of up to 12,000 EUR per month from 2026 onwards, corresponding to up to 3 days per week of dedicated senior engineering capacity.
+
+This is based on:
+1. Benchmark rate in line with EU Tech Lead Python Engineering rates (source: https://www.index.dev/blog/python-developer-hourly-rates),
+2. Historic rate of 125 EUR/hour used under Polkascan Foundation, and
+3. Demonstrated ecosystem-wide impact of ensuring these libraries remain maintained, modern and future JAM-compatible.
+
+The exact reimbursed amount for each month will reflect actual hours worked and will never exceed the structural cap.
+
+### 3.3. Nature of the Soft Commitment
+This proposal seeks:
+1. Governance-level acknowledgment that recurring monthly reimbursements for this specific maintenance scope are appropriate;
+2. Community consensus on the approximate cost level and service profile;
+3. Shared understanding that, as long as the work is delivered to a clear standard and reported transparently, such requests will be considered favorably.
+
+At the same time, OpenGov retains full flexibility to:
+1. Vote against any specific monthly reimbursement;
+2. Request changes in scope, reporting or rate;
+3. Discontinue the framework if the ecosystem decides to take a different path.
+
+## 4. Deliverables & Reporting
+Each monthly retroactive reimbursement request will be accompanied by a concise public report that includes at least:
+1. Work Summary
+  a. Key tasks completed that month across maintenance, technical debt, adoption and incident management.
+  b. Specific compatibility improvements (e.g. new runtime support, JAM-related changes).
+2. Code and Repository Activity
+  a. Links to GitHub commits and pull requests in the repositories listed in Appendix 1.
+  b. Summary of releases (versions, changelog highlights).
+  c. Overview of key issues closed and community contributions merged.
+3. Effort and Cost Breakdown
+  a. Total hours spent, grouped by activity category where feasible.
+  b. Derived reimbursement amount in EUR, respecting the agreed cap and rate.
+4. Risk and Incident Notes (if applicable)
+  a. Any critical incidents handled that month.
+  b. Known outstanding risks or backlog items that may require prioritization.
+
+This reporting approach:
+1. Mirrors the successful practice established under Polkascan Foundation (Appendix 2.2);
+2. Provides a transparent, auditable link between work performed and reimbursement requested;
+3. Enables the community to assess whether maintenance is keeping pace with protocol evolution and ecosystem needs.
+
+## 5. Risk Management
+The proposed framework manages risk for both the ecosystem and the Treasury in several ways:
+1. Retroactive Reimbursement for Completed Work Only
+  a. The Treasury does not pre-fund long-term commitments.
+  b. Each reimbursement is based on completed, verifiable work.
+2. Granular, Monthly Cycles
+  a. The community can provide feedback or intervene quickly if expectations are not met.
+  b. There is no lock-in; reimbursements can be stopped or adjusted at any time via OpenGov.
+3. Open-Source and Public Activity
+  a. All work is done in public repositories; verification does not depend on private information.
+  b. The community can independently inspect code, issues and releases.
+4. Clear Scope and Governance Hooks
+  a. The scope is explicitly defined (Appendix 1).
+  b. The budgeting and accountability framework is aligned with Web3 Foundation guidelines (Appendix 2).
+5. Key-Person and Continuity Risk
+  a. While the expertise is specialized, JAMdot Technologies is building on a long history of team collaboration around this codebase.
+  b. The open-source nature of the libraries means that, in the worst case, maintenance could be picked up by other ecosystem actors in the future.
+
+Overall, the combination of retroactive funding, public reporting and community oversight provides a conservative and transparent risk profile.
+
+## 6. Team
+JAMdot Technologies is formed by the core engineers who previously maintained the Polkascan Python ecosystem:
+1. Arjan Zijderveld: https://github.com/arjanz, 
+2. Matthijs Blaas: https://github.com/matthijsb,
+3. Emiel Sebastiaan: https://github.com/emielsebastiaan.
+
+The team brings:
+1. Deep experience with Polkadot and Substrate architecture, including runtimes and metadata;
+2. Proven track-record in tooling, metadata handling and SCALE codec;
+3. Many years of long-term maintenance workflows for open-source infrastructure;
+4. Extensive Python ecosystem engineering experience, specifically focused on cryptography, networking and protocol tooling;
+5. Demonstrated success in Treasury-funded project delivery, including multi-year reporting up to 2024.
+
+Years of prior Treasury reports and public repositories demonstrate that this team is capable of:
+1. Designing robust architectures;
+2. Maintaining compatibility through multiple network upgrades;
+3. Delivering incremental improvements without disrupting downstream users.
+
+JAMdot Technologies continues this lineage under a structure that is focused on sustainable maintenance and development.
+
+## 7. Conclusion
+This proposal invites the OpenGov community to:
+1. Acknowledge the systemic importance of the Python Polkadot SDK, SCALE codec and related bindings;
+2. Recognize that their ongoing maintenance and evolution are appropriate, recurring targets for Treasury funding;
+3. Provide a soft commitment that monthly retroactive reimbursement requests from JAMdot Technologies, within an agreed scope and cost level, will be considered as part of a standing maintenance framework starting January 2026.
+
+In return, JAMdot Technologies commits to:
+1. Delivering consistent, high-quality maintenance and incremental development;
+2. Keeping the libraries aligned with Polkadot, Kusama and JAM evolution;
+3. Reporting transparently and responding to community feedback;
+4. Respecting the Treasury as a scarce, shared resource.
+
+Re-establishing a structured, predictable Treasury-backed model for these libraries from 2026 onwards is both:
+1. Risk mitigation measure (preventing degradation of critical infrastructure), and
+2. Strategic investment in enabling Python-centric innovation on top of Polkadot and future JAM.
+
+# Apendices
+## Appendix 1. Scope
+### Appendix 1.1. Libraries
+The Treasury reimbursement covers maintenance, innovation and ecosystem support for the following Python libraries:
+
+
+| Library | Resource |
+| -------- | -------- |
+| **Python Polkadot SDK** (formerly known as: Python Substrate Interface) | *Description*: This library specializes in interfacing with a Substrate node and the broader Polkadot architecture; querying storage, composing extrinsics, encoding/decoding and providing additional convenience methods to deal with the features and metadata of the Substrate runtime. *Repository*: https://github.com/JAMdotTech/py-polkadot-sdk *Documentation*: https://jamdottech.github.io/py-polkadot-sdk|
+| **Python Scale Codec** | *Description*: Substrate uses a lightweight and efficient encoding and decoding program to optimize how data is sent and received over the network. The program used to serialize and deserialize data is called the SCALE codec, with SCALE being an acronym for Simple Concatenated Aggregate Little-Endian. *Repository*: https://github.com/JAMdotTech/py-scale-codec *Documentation*: https://jamdottech.github.io/py-scale-codec |
+| **Python BIP39 Bindings** | *Description*: Python bindings for the tiny-bip39 library: https://crates.io/crates/tiny-bip39. *Repository*: https://github.com/JAMdotTech/py-bip39 *Documentation*: https://docs.rs/crate/py-bip39-bindings |
+| **Python ED25519 Bindings** | *Description*: Python bindings for the ed25519-zebra RUST crate. *Repository*: https://github.com/JAMdotTech/py-ed25519 *Documentation*: https://docs.rs/crate/py-ed25519-bindings |
+| **Python SR25519 Bindings** | *Description*: Python bindings for sr25519 library: https://github.com/w3f/schnorrkel. *Repository*: https://github.com/JAMdotTech/py-sr25519 *Documentation*: https://docs.rs/crate/py-sr25519-bindings |
+
+### Appendix 1.2. Activities
+The Treasury reimbursement covers the following categories of work:
+
+| Activity | Description |
+| -------- | -------- |
+| **Maintenance and Continuity of Functionality** | Ensuring continuity, bug fixing and compatibility of the libraries with the evolution of the Polkadot, Kusama and JAM networks. This includes keeping pace with runtime upgrades, metadata changes and RPC evolutions so that downstream users experience minimal disruption. |
+| **Addressing Technical Debt** | Refactoring and code modernization, reducing legacy complexity, and keeping up with new runtime, metadata and cryptography updates. This includes restructuring modules, improving type safety, test coverage and performance, and aligning the codebase with current Python and tooling best practices. |
+| **Enhancing Adoption** | Community support, documentation improvements, example implementations and developer advocacy. This includes responding to GitHub issues, reviewing community pull requests, writing guides and tutorials, and providing reference examples that lower the barrier to entry for Python developers in the Polkadot ecosystem. |
+| **Best-Effort Incident & Problem Management** | Best-effort support for incidents that block or severely hinder integration within the ecosystem. This includes diagnosing and mitigating urgent issues reported by teams that depend on these libraries for production workloads, research, governance tooling or infrastructure. |
+
+## Appendix 2. Web3 Foundation OpenGov Guidelines Justification
+Source: https://medium.com/web3foundation/w3f-opengov-proposal-voting-guidelines-543ff7faba03
+
+### Appendix 2.1. Expertise
+**Guideline summary (expertise)**: 
+> “Credibility matters. Web3 Foundation will review the capabilities of the proposer and leverage its open and strategic grants evaluation framework to assess the credibility of the proposing entity in executing the deliverables. For technical work, this includes architecture, security and integration pathways. For community initiatives, it includes track record and community engagement. For research, it includes methodology and prior publications. For market development, it includes relevant market experience and realistic understanding. In all cases, W3F expects a verified proposer identity and credible evidence that the team can execute as promised.”
+
+**How this proposal meets the expertise requirement**: The work in this proposal is a direct continuation of the multi-year efforts of Polkascan Foundation, which has been active in the Substrate and Polkadot ecosystem since 2017 and received multiple Web3 Foundation Grants and sustained Treasury support from 2020 onwards. Over this period, the team designed, implemented and maintained the core Python Substrate Interface (now Python Polkadot SDK), SCALE codec library and associated cryptographic bindings.
+
+The engineers at JAMdot Technologies are the original authors and long-term maintainers of these libraries. Their expertise covers:
+1. Substrate and Polkadot runtime architecture, metadata formats and storage models.
+SCALE encoding/decoding.
+2. Cryptographic primitives used in Polkadot (ED25519, SR25519, BIP39).
+3. Long-term maintenance of production-grade open-source libraries, including compatibility management across all network Polkadot, Kusama, Parachain & Substrate upgrades since its inception.
+4. Integration pathways for indexers, research tooling, governance analytics, infrastructure automation and test frameworks built on top of these Python components.
+
+The public track record of Polkascan Foundation, including years of Treasury-funded work and reporting, provides verifiable evidence that this team can design robust architectures, maintain compatibility over time and deliver on technical commitments. JAMdot Technologies inherits this expertise and continues the same lineage of work under a more operationally focused structure.
+
+### Appendix 2.2. Accountability
+**Guideline summary (accountability)**: 
+> “OpenGov aims to ensure on-chain accountability through a periodic review process. Automatic milestone-based payouts are possible, and if deliverables are not consistently met, the community can stop future payouts through an OpenGov vote. This framework applies across proposal types, and KPIs can be structured with clear on-chain verification and logic. Proposers are encouraged to lock their scope and budget in immutable form (IPFS, Git, or on-chain hashes), enabling the community to verify what was promised and whether it was delivered.”
+
+**How this proposal meets the accountability requirement**: The Polkadot Treasury has previously reimbursed contributions for the maintenance of these libraries under Polkascan Foundation’s Social Contract 002 (https://github.com/polkascan/social-contract/blob/master/polkadot/social-contract-002.md). Accountability was enforced through periodic written reports and public code contributions. The following reports were submitted and accepted (monthly or quarterly, depending on the period):
+- 2020
+  - October: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202010.md
+  - November: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202011.md
+  - December: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202012.md
+- 2021
+  - January: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202101.md
+  - February: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202102.md
+  - March: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202103.md
+  - April: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202104.md
+  - May: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202105.md
+  - June: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202106.md
+  - July: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202107.md
+  - August: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202108.md
+  - September: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-202109.md
+  - Quarter 4: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-2021Q4.md
+- 2022
+  - Quarter 1: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-2022Q1.md
+  - Quarter 2: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-2022Q2.md
+  - Quarter 3: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-2022Q3.md
+  - Quarter 4: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-2022Q4.md
+- 2023
+  - Quarter 1: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-2023Q1.md
+  - Quarter 2 & 3: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-2023Q2-Q3.md
+  - Quarter 4: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-2023Q4.md
+- 2024
+  - Quarter 1: https://github.com/polkascan/social-contract/blob/master/polkadot/treasury-proposal-008-report-2024Q1.md
+
+Going forward, JAMdot Technologies will continue this reporting culture by:
+1. Providing periodic written reports that link concrete work (commits, releases, issues resolved) to the funded scope.
+2. Aligning reimbursements to clearly defined, measurable activities (e.g. monthly maintenance cycles).
+3. Accepting that OpenGov can halt or adjust reimbursement at any time if deliverables are not met or if the ecosystem decides maintenance should take a different form.
+
+This approach provides the same transparency and on-chain accountability that the Treasury has already used successfully with this codebase for multiple years.
+
+### Appendix 2.3. Cost-effectiveness
+**Guideline summary (cost-effectiveness)**: 
+> “Web3 Foundation invites proposers to engage early in public discussions to ratify costs. Budget discipline signals that a proposer has carefully considered what they are committing to. Proposals should include itemized costs, vendor quotes where applicable, and transparent benchmarking against comparable work. Spending should reflect both frugality and quality, and demonstrate respect for community capital as a scarce shared resource.”
+
+**How this proposal demonstrates cost-effectiveness**: Historically, Treasury reimbursements for the maintenance of these libraries have been calculated on the basis of an hourly rate of 125 EUR per hour (excluding VAT). The historic reimbursements can be summarized as follows:
+
+| Year | Hours | Reimbursements (DOT) | Reimbursements (EUR) | Taxes VAT (EUR) |
+| ------- | -------: | -------: | -------: | -------: |
+| 2020 | 416 | 10.000,00 DOT | 52.000,00 EUR | 10.920,00 EUR |
+| 2021 | 1646 | 6.098,45 DOT | 205.750,00 EUR | 43.207,50 EUR |
+| 2022 | 416 | 10.593,48 DOT | 52.000,00 EUR | 10.920,00 EUR |
+| 2023 | 493 | 14.397,75 DOT | 61.625,00 EUR | 12.941,25 EUR |
+| 2024 | 65 | 1.212,24 DOT | 8.125,00 EUR | 1.706,25 EUR |
+
+
+In the new structure:
+1. JAMdot Technologies operates in a way where no additional VAT burden is charged to the Polkadot Treasury, simplifying the financial structure and reducing overhead.
+2. The effective rate is competitive for Tech Lead/Architect EU-based Python engineers with deep domain expertise in cryptography, Substrate and Polkadot-specific tooling. (Source: https://www.index.dev/blog/python-developer-hourly-rates)
+
+Future Treasury requests will:
+1. Maintain a clear, itemized link between hours worked and delivered outputs.
+2. Keep the requested structural reimbursement (targeting up to 12.000 EUR per month for up to 3 days per week from 2026-Q1 onwards) modest relative to the ecosystem impact of keeping these critical libraries maintained and future-proof.
+
+This reflects a disciplined and frugal approach to long-term maintenance funding.
+
+### Appendix 2.4. Genuine Ecosystem Value
+**Guideline summary (genuine ecosystem value)**: 
+>  “Beyond expertise, accountability and cost-effectiveness, OpenGov assesses whether a proposal creates genuine ecosystem value and whether Treasury funding is the appropriate mechanism. Proposals with ecosystem-level impact are prioritized over those that primarily benefit a single team. A key question is: would the ecosystem be substantially worse off if this work were not funded?”
+
+**Why this work creates genuine ecosystem value**: The Python libraries covered by this proposal form foundational infrastructure for a wide range of teams and use cases. They are open-source, widely depended upon and form the backbone of Python-based interaction with Polkadot.
+
+As of 10 December 2025, the libraries show the following adoption metrics:
+
+| Library | Metrics (on: 10 December 2025) |
+| -------- | -------- |
+| **Python Polkadot SDK** (formerly known as: Python Substrate Interface) | *Stars*: 259, *Forks*: 120, *External Contributors*: 14, *Dependent Repositories*: 738, *Dependent Packages*: 59 |
+| **Python Scale Codec** | *Dependency of*: Python Polkadot SDK, *Stars*: 58, *Forks*: 57, *External Contributors*: 7, *Dependent Repositories*: 647, *Dependent Packages*: 46 |
+| **Python BIP39 Bindings** | *Dependency of*: Python Polkadot SDK, *Stars*: 3, *Forks*: 6, *External Contributors*: 2, *Dependent Repositories*: 496, *Dependent Packages*: 14 |
+| **Python ED25519 Bindings** | *Dependency of*: Python Polkadot SDK, *Stars*: 1, *Forks*: 2, *External Contributors*: 1, *Dependent Repositories*: 278, *Dependent Packages*: 5 |
+| **Python SR25519 Bindings** | *Dependency of*: Python Polkadot SDK, *Stars*: 9, *Forks*: 17, *External Contributors*: 6, *Dependent Repositories*: 1063, *Dependent Packages*: 30 |
+
+These metrics demonstrate:
+1. Broad ecosystem reliance: Hundreds to over a thousand dependent repositories per library indicate that many teams and projects silently rely on these components.
+2. Community involvement: External contributors across the stack show that this is not a single-team vanity project but shared ecosystem infrastructure.
+3. Systemic risk if unmaintained: If these libraries are not kept in sync with Polkadot, Kusama and JAM evolution, many downstream tools and experiments will break or stagnate.
+
+Treasury funding is therefore the appropriate mechanism: it supports shared, open-source infrastructure whose benefits accrue to the entire ecosystem rather than a single commercial product. Without ongoing maintenance, the ecosystem would be measurably worse off: Python-based integrations would degrade, new developers would face higher friction, and existing Treasury-funded or grant-funded projects that depend on these libraries would face avoidable risks.
+
+### Appendix 2.5. Minimum Standards Checklist
+This proposal is designed to meet the minimum standards expected under the Web3 Foundation OpenGov guidelines:
+1. On-chain verified proposer identity: Polkadot Identity: JAMdotTech, Jamdot Technologies, hello@jamdot.tech, Polkadot Account: 15gPiSBxhrrQFfShFbrnsQK7kokgQtVs3SEh38YjCDC31de3
+2. Immutable scope and budget: Content of this document to be published via GitHub.
+3. Concrete, measurable deliverables: Github activity on listed repositories (issues & pull requests).
+4. Itemized, benchmarked budget: Accountability reports within budget constraints meeting the standards as previously provided by Polkascan Foundation.
+5. Milestone-gated or period-based disbursement: Monthly retroactive reimbursements for completed work based on accountability reports meeting the standards as previously provided by Polkascan Foundation.
+6. Public discussion lead-time: This proposal will seek feedback from Web3 Foundation and Community upon publishing on the Polkadot Forum.
+7. Responsiveness to community feedback: This proposal will seek feedback from Web3 Foundation and Community upon publishing on the Polkadot Forum. Additionally work will consist of addressing a backlog of issues and community requests which can be found on the listed repositories.
+8. Open-source licenses: All libraries are open-sourced and permissively licensed and will remain so.
+9. Security-conscious processes and audits where relevant: Critical security updates will be addressed in a timely and responsible manner.
+10. Sustainability beyond Treasury funding: JAMdot Technologies is currently participating in the JAM Prize Competition which will hopefully result in achieving the JAM Prize Milestone 1. This achievement may result in membership of Polkadot Fellowship being granted. Such milestone achievement would be a natural point in time to re-evaluate this agreement.
+
+## Appendix 3. Questions and Answers
+### Appendix 3.1. Why not apply for a Web3 Foundation Grant?
+Source: https://medium.com/web3foundation/new-w3f-grant-guidelines-b2c921a84850
+
+The updated Web3 Foundation Grants Program focuses on innovation, new verticals and high-leverage research or product initiatives. Grants are best suited for:
+1. New protocol research;
+2. Novel tooling or infrastructure;
+3. Experimental products or verticals that expand the Polkadot ecosystem in new directions.
+
+By contrast, this proposal focuses primarily on long-term maintenance and incremental evolution of already mature libraries that are widely used in production and research. The work is not about launching a fundamentally new product, but about keeping critical shared infrastructure:
+1. Secure,
+2. Compatible with current and future Polkadot/JAM developments, and
+3. Accessible to Python developers.
+
+For such recurring maintenance, the Polkadot Treasury / OpenGov mechanism is more appropriate than a one-off Web3 Foundation Grant. Treasury funding better reflects the recurring, service-like nature of this work and allows the community to continuously steer, renew, or discontinue support as needs evolve.
+
+### Appendix 3.2. Why were Treasury reimbursements discontinued during 2024?
+Several factors contributed to the discontinuation of Treasury reimbursements in 2024:
+1. Dissolution of Polkascan Foundation: The governance and administrative structure of the Polkascan Foundation was unwound in late 2024. Treasury requests were formally tied to the Foundation entity, which disrupted the established workflow and made it impractical to continue submitting reimbursements under the same legal structure.
+2. Shift in priority towards PyJAMaz (JAM Prize): From Q3 2024 onwards, implementation of the JAM Protocol (PyJAMaz) under the JAM Prize became the primary focus for the core team. The Python libraries moved into a secondary, best-effort maintenance mode, even though Arjan continued to perform maintenance work de facto.
+3. Disproportionate overhead of Treasury submissions: Preparing, submitting and following up on Treasury reimbursement proposals involved a non-trivial administrative overhead. Relative to the available team capacity, this overhead became disproportionate compared to the incremental maintenance work being claimed.
+4. Capacity constraints in a small team: With limited engineering capacity, strategic deliverables (such as JAMPrize Milestone 1 and 2) were prioritized over routine ecosystem maintenance, even though the latter remained important. This made it difficult to maintain a regular cadence of Treasury proposals for the Python libraries.
+
+The new proposal and structure via JAMdot Technologies aim to restore a sustainable, low-overhead and predictable funding path so that maintenance does not depend on ad-hoc reimbursements or one-off windows of capacity.
+
+### Appendix 3.3. Why reposition these libraries from 2026 onwards?
+As PyJAMaz (Python implementation of JAM) moves towards the completion of Milestone 2, the Python libraries are deliberately being brought back into the foreground. There are several reasons for this:
+1. Ecosystem demand for stable, modern and JAM-compatible Python tooling: With JAM, Polkadot 2.0 and related developments maturing, there is a renewed need for Python tooling that is fully up to date, well maintained and aligned with the new architecture.
+2. Strategic fit for JAMdot Technologies as Python specialists: Systematically addressing technical debt and modernizing the libraries aligns with JAMdot Technologies’ role as the Python specialist within the Polkadot ecosystem. The team is uniquely positioned to perform this work efficiently due to deep historical context and ownership of the codebase.
+3. Essential for adoption and tooling around PyJAMaz, JAM and Polkadot: The libraries are not only generic ecosystem tooling; they are also foundational for adoption and integration around PyJAMaz, the JAM protocol and Polkadot itself. Ensuring their quality, stability and JAM-compatibility directly supports the broader strategic roadmap of the ecosystem.
+
+Repositioning the libraries in 2026 under a structural Treasury-backed model is therefore both a risk mitigation measure (preventing degradation of critical infrastructure) and a strategic investment in enabling Python-centric innovation on top of Polkadot and JAM.
+
+
+### Appendix 3.4. Comparable Projects
+
+
+| Name | Programming Language | GitHub |
+| -------- |  -------- | -------- |
+| SubXT  | RUST | https://github.com/paritytech/subxt |
+| Polkadot API | Javascript/Typescript | https://github.com/polkadot-api/polkadot-api |
+| Polkadot JS | Javascript/Typescript | https://github.com/polkadot-js |
+| Substrate API Client | RUST | https://github.com/scs/substrate-api-client |