LFX Mentorship Organizations

AI powered mainframe data modernization (unpaid)

Linux Foundation

<p>Artificial Intelligence (AI) presents an opportunity to accelerate and de‑risk mainframe data modernization by automating the most complex and labor‑intensive aspects of understanding, extracting, and rebuilding legacy workloads.</p><p>This project will deliver a comprehensive framework that guides organizations through understanding legacy mainframe data structures, mapping those datasets to modern cloud‑based platforms, and applying effective methods for data transfer, quality checks, and validation. As part of this effort, the participant will also develop a demonstration application that showcases the practical implementation of key elements of the framework, illustrating how each component works together to support a successful modernization journey.</p><p><br></p><p>Deliverables:</p><p>A technical framework</p><p>A whitepaper to be published under the modernization working group banner.</p><p><br></p><p><strong>Applications closing date: 25-Apr-2026</strong></p><p><br></p><p><strong>Mentee confirmation: 10-May-2026</strong></p>

AI-Powered Operations Agent for Hyperledger Cello (Unpaid)

Hyperledger

<p>Hyperledger Cello is an enterprise-grade Blockchain-as-a-Service (BaaS) platform that provides a comprehensive REST API for managing the full lifecycle of Hyperledger Fabric networks (Network, Node, Channel, Chaincode). However, all current operations require users to interact manually through the Dashboard, which presents a steep learning curve for newcomers.</p><p><br></p><p>This project aims to implement an AI-powered operation agent with chatbot interface for Hyperledger Cello. It consists of two components:</p><p><br></p><ol><li>AI Agent Backend: A Python service that wraps Cello's existing REST APIs into LLM. It accepts natural language requests, invokes Cello operations, and returns structured responses. It also provides AI-assisted fault log summarization for common Fabric failures.</li><li>Chatbot UI&nbsp;— A chatbot interface integrated into Cello's existing Dashboard (React), allowing users to interact with the AI agent.</li></ol><p><br></p><p>The combined system enables a natural language-driven operational workflow:</p><p><br></p><p>User (chat message) → Chatbot UI → AI Agent → Cello REST API → Fabric Infrastructure</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Open Source Collaboration: Familiarity with Hyperledger Cello workflow, code review standards, and CI pipeline.</li><li>Full-Stack Engineering: Experience building a production-integrated feature spanning a Python backend and a React frontend.</li><li>Applied AI Engineering: Proficiency in LLM Tool Calling integration, streaming response handling, and prompt engineering.</li><li>Blockchain Infrastructure: Hands-on understanding of Hyperledger Fabric network topology, node types, and Chaincode lifecycle.</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ul><li>Deliverable: AI Agent Backend</li><li>Acceptance Criteria: Python service exposing a chat API endpoint; supports natural language execution of core Cello operations (list/create networks, manage nodes, query channels and chaincodes)</li></ul><p><br></p><ul><li>Deliverable: Chatbot UI (Dashboard)</li><li>Acceptance Criteria: Chat panel integrated into Cello's existing React Dashboard; supports streaming responses; maintains multi-turn conversation context</li></ul><p><br></p><ul><li>Deliverable: Documentation</li><li>Acceptance Criteria: Setup guide for the AI agent</li></ul>

AI-assisted extraction of architectural parameters from RISC-V specifications

RISC-V

1) Develop prompts & context size for LLMs that identify architectural parameters in the RISC-V privileged and unprivileged spec. a) Give examples from the manually created list (in UDB). b) Identify with textual excerpt from the specs. c) Classify the parameters as either dependent on a configuration, named or unnamed. 2) Use those prompts to collect a list of parameters using at least two different LLMs and the parameters documented in UDB. 3) Refine the prompts to address any differences between LLM and UDB results, as needed. a) Filter out any hallucinations as negative examples, e.g. doesn’t fall into any of the 1(c) categories or falls into the wrong category (could be context size dependent). b) Use some missing parameters as further prompt examples. 4) Create a Github PR to insert tags into the spec for each parameter in the resulting list, giving unique names to unnamed parameters according to the tag format spec, and using existing parameter names as examples.

AI-assisted extraction of architectural parameters from RISC-V specifications - Part II

RISC-V

<p>This mentorship proposal extends an effort already underway to extract architectural parameters from the RISC-V ISA Manual using AI. It originally started as an RVI Mentorship for Spring 2026, and continued under the Parameter SIG. Although the results have improved steadily, we need further improvement in quality and implementation robustness. Hence the Fall mentorship proposes to:</p><p><br></p><p>1) Continue trying to find architectural parameters with LLMs in the RISC-V privileged and unprivileged spec, extending the initial work done in Spring 2026 mentorship. Use as training examples subsets of parameters from the manually created lists (and try to recreate the full lists) from the following efforts:</p><p><br></p><p>a. ISA Manual (per-chapter params in yaml format)</p><p>b. Google Drive (“keyword_matches” spreadsheet)</p><p>c. UDB yaml (enhance the current parameter recall process).</p><p><br></p><p>2) Extend the current classification scheme for parameters as needed.</p><p><br></p><p>3) Develop AI coding agents and skills for reproducible runs and reusable workflows (extending the prompt and context management in the current flow).</p><p><br></p><p>4) Explore integration of the tools developed for the ISA Manual based flow (in 1.a) to export the parameters in UDB yaml format.</p><p><br></p><p>5) Create a Github PR to publish the final reviewed parameter files in the appropriate repo and follow up with the maintainers on merging them.</p><p>&nbsp;</p>

BGP-LS Cli dev & testing on 7-node vSONiC topo

Linux Foundation

<p><strong>*APPLICATION ONLY OPEN TO COLLEGE STUDENTS BASED IN THE UNITED STATES*</strong></p><p><br></p><p><strong>Problem Statement</strong></p><p><br></p><p>BGP Link-State Protocol (BGP-LS) is a critical protocol for modern network management and SDN-style controller integration, enabling the distribution of network topology information. Currently, SONiC's BGP-LS implementation lacks comprehensive CLI tools for configuration and monitoring, making it difficult for network operators to effectively deploy and troubleshoot BGP-LS in production environments. Additionally, there is insufficient testing infrastructure to validate BGP-LS functionality in complex multi-node topologies.</p><p>This mentorship program aims to address these gaps by developing a complete CLI interface for BGP-LS operations and establishing a robust 7-node testing framework based on vSONiC instances. This will significantly improve SONiC's BGP-LS usability and reliability, making it production-ready for enterprises and service providers who rely on topology discovery for traffic engineering and network automation.</p><p><br></p><p><strong>Mentorship Objectives</strong></p><p><br></p><ul><li>Develop a comprehensive CLI interface for BGP-LS configuration, monitoring, and troubleshooting in SONiC</li><li>Design and implement a 7-node test topology to validate BGP-LS functionality in complex network scenarios</li><li>Create automated test cases covering BGP-LS neighbor establishment, topology advertisement, and failure scenarios</li><li>Document CLI usage and testing procedures for community adoption and future development</li></ul><p><br></p><p><strong>Expected Outcomes and Deliverables</strong></p><p><br></p><ul><li>Complete BGP-LS sonic-cli implementation with commands for neighbor configuration, status checking, and topology visualization</li><li>Functional 7-node test environment with automated deployment scripts and topology configurations</li><li>Comprehensive test suite covering at least 15-20 BGP-LS scenarios including normal operations and edge cases</li><li>Technical documentation including CLI user guide, test topology design document, and contribution guidelines for future enhancements</li><li>Merge CLI codes into SONiC repo</li><li><strong>Program Length: Summer / Fall Term (May - November) 20 hours of work each week*</strong></li></ul><p><br></p><p><strong>Recommended Qualifications</strong></p><p><br></p><ul><li>Proficiency in Python and/or C++ programming</li><li>Understanding of BGP routing protocols and network topology concepts</li><li>Familiarity with Linux CLI development and command-line interface design patterns</li><li>Experience with network testing frameworks (pytest, ansible Framework) or willingness to learn</li><li>Basic knowledge of SONiC architecture or similar network operating systems</li><li>Strong documentation and communication skills</li></ul>

BiniBFT - Testing, Integration, and Documentation (Unpaid)

Linux Foundation

<p>To test the BiniBFT consensus developed, and to make it as a standalone plugin, and to document the algorithm and process.</p><p><br></p><p>Check&nbsp;<a href="https://github.com/BiniWorld/Hyperledger-BiniBFT/tree/binibft" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">GitHub branch</a>&nbsp;for the BiniBFT consensus developed, and&nbsp;<a href="https://github.com/BiniWorld/Hyperledger-BiniBFT/tree/main" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">GitHub page</a>&nbsp;for the previous work.</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Deep understanding of consensus mechanisms</li><li>Testing and comparing different consensus algorithms</li><li>Developing standalone consensus plugins</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ul><li>To test the BiniBFT consensus developed</li><li>Integrate it to Fabric</li><li>Develop it into standalone plugin</li><li>Documentation</li></ul><p><br></p><p>Learn More at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/79" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/79</a>.</p>

Broadening the RISC-V High Precision Code Base and Reach

RISC-V

<p>We plan to refactor and recode Community AI / ML and HPC (double precision) applications to port them to RISC-V this summer. This is a large, potentially daunting effort but we anticipate building scripts and methods to be able to substantially automate the process. Priority will be given to codes that make the most impact. Here is the initial list of 400 codes we are optimizing and compiling for RISC-V this summer: <a href="https://tinyurl.com/2aau5b9r" rel="noopener noreferrer" target="_blank" style="background-color: rgb(255, 255, 255); color: rgb(17, 85, 204);">https://tinyurl.com/2aau5b9r</a><span style="color: rgb(34, 34, 34);">&nbsp;</span></p><p><br></p>

Cloud Native Computing Foundation

Cloud Infrastructure

The Cloud Native Computing Foundation (CNCF) hosts critical components of global cloud infrastructure, including Kubernetes and Prometheus.

Creating an Execution-Driven Version of Olympia, the Performance Model of example RISC-V superscalar

RISC-V

Performance models are essential tools in both academia and industry for analyzing the efficiency of superscalar processor micro-architectural features. Olympia is a widely adopted performance model within the RISC-V community. Performance models can be categorized as either trace-driven or execution-driven. Trace-Driven Models rely on an instruction trace, which is simply a sequence of retired instructions. Execution-Driven Models (EDM), in contrast, use the program binary and associated data. This allows EDMs to simulate not only the sequence of retired instructions but also speculatively fetched and executed instructions resulting from mis-speculations like branch mis-predictions and memory-dependency mispredictions. Consequently, execution-driven simulations offer greater accuracy in prediction. Currently, Olympia only supports trace-driven simulations. The central objective of this project is to develop an execution-driven version of Olympia using an outside functional modeling driver such as Pegasus or Whisper. The Olympia project must remain agnostic to the functional driver of EDM. Specifically, a user of Olympia should be able to provide their own functional model backend to drive EDM. The simulated frontend and backend must remain agnostic to the fact that it is running in EDM. To enable this, a generic API for EDM (virtual interface) must be developed to connect the Olympia model to the driver.

DPU Operator Enhancement

Linux Foundation

OPI project is aiming to expand the OpenShift DPU Operator to support NVIDIA, xSight, and/or Mangoboost hardware. The ideal candidate needs to be comfortable at the intersection of infrastructure software and hardware offloading. The expected skill set is a combination of low-level hardware abstraction skills and high-level Kubernetes operator patterns. Technical skills: Golang expertise Github, CI/CD, Linux Networking expertise (Strong understanding of SR-IOV, OVS-DPDK, and virtual functions (VFs)) Familiarity with the OPI APIs and how DPUs handle networking and storage offloading. Experience with developing Kubernetes Operators. Experience with operator-sdk or controller-runtime. They must understand Custom Resource Definitions (CRDs), Reconcile loops, and watch patterns. Understanding Vendor SDKs (ex: DOCA). Optional - Comprehensive knowledge of the OpenShift ecosystem

DPU-Accelerated OVS Offload

Linux Foundation

<p>About the project</p><p>OPI (Open Programmable Infrastructure), a Linux Foundation project, defines vendor-neutral</p><p>standards and tooling for DPUs / IPUs. This internship produces a reference blueprint for</p><p>running VM networking through OVS that is fully hardware-offloaded to a DPU - first under</p><p>vanilla KVM on RHEL, then under OpenShift Virtualization. NVIDIA BlueField-3 (BF3) is the</p><p>reference platform because it ships a complete, mature stack (OVS-DOCA, vDPA, and DPF).</p><p>The blueprint then generalizes to a second DPU / IPU vendor (Intel IPU or Marvell Octeon).</p><p>What you&amp;#39;ll work on</p><p>The work runs as two tracks. Track 1 (BF3) is the proven reference; Track 2 ports it to a second</p><p>vendor and surfaces the gaps that need upstream work.</p><p>Track 1 - BF3 reference</p><p>• KVM on RHEL with OVS fully offloaded to BF3 in DPU mode via OVS-DOCA. KVM / libvirt</p><p>guests attach over vDPA so the guest runs stock virtio-net while the datapath is</p><p>accelerated in hardware. Validate offload is actually in hardware, baseline performance,</p><p>and exercise live migration. This is the reference blueprint.</p><p>• OpenShift Virtualization on BF3 via NVIDIA DPF, with accelerated OVN-Kubernetes</p><p>(OVS-DOCA) offloaded to the DPU and KubeVirt VMs riding the offloaded fabric.</p><p>Track 2 - second vendor (Intel IPU or Marvell Octeon)</p><p>• KVM on RHEL with OVS offload and vDPA using the vendor&amp;#39;s stack (Marvell: in-kernel</p><p>octeon_ep vDPA driver and Octeon SDK; Intel: IPDK / P4 and IDPF). Document the deltas</p><p>from the BF3 reference.</p><p>• OpenShift Virtualization on the second vendor via the OPI / Red Hat DPU Operator.</p><p>Identify and contribute the work needed to reach full primary-datapath OVS offload and</p><p>KubeVirt enablement, since the operator today centers on network-function offload and</p><p>service function chaining rather than the full offloaded OVN datapath that DPF provides on</p><p>BF3.</p><p><br></p><p>Required</p><p>• Linux, Red Hat family (RHEL 9 / 10): systemd, networking stack, kernel modules, and</p><p>hands-on troubleshooting</p><p>• KVM / libvirt / QEMU: VM lifecycle, virtio / vhost, and vDPA (vhost-vdpa) concepts</p><p>• OVS: bridges, flows, OpenFlow, datapath internals, and hardware-offload concepts</p><p>(switchdev / eswitch mode, VF / SF representors)</p><p>• Kubernetes: core concepts, CRDs, operators, and CNI / pod networking - enough to grow</p><p>into OpenShift Virtualization and OVN-Kubernetes</p><p>• Networking fundamentals: L2 / L3, VLAN, VXLAN / Geneve, SR-IOV (PF / VF / SF), and</p><p>throughput / pps testing</p><p><br></p><p>2</p><p><br></p><p>Preferred (a plus)</p><p>• OVS-DOCA and the DOCA SDK / DPF (DOCA Platform Framework) on BlueField</p><p>• vDPA hands-on: mlx5_vdpa, octeon_ep, vhost-vdpa, libvirt vDPA, and vdpa netlink /</p><p>iproute2</p><p>• OVN / OVN-Kubernetes; OpenShift / OpenShift Virtualization (CNV / KubeVirt)</p><p>• OPI DPU Operator, and vendor offload stacks: Intel IPDK / P4 / IDPF, Marvell Octeon</p><p>SDK</p><p>• Go (operator development), Python, and Bash</p><p>• Prior open source contribution (public Git workflow, mailing lists / Slack); familiarity with</p><p>OPI</p><p><br></p><p><br></p>

Drasi

Cloud Native Computing Foundation (CNCF)

Drasi is a Data Change Processing platform that enables developers to detect and react to meaningful data changes using declarative Cypher queries. Drasi excels at complex change detection with unique features like `drasi.trueFor()` (detecting conditions that persist over time) and absence-of-change detection (alerting when expected events don't occur). However, it currently lacks native connectivity to IoT protocols. Drasi Lib provides Drasi's powerful graph-aware decision engine as an embeddable Rust library that can run completely offline on constrained hardware—enabling edge computing scenarios where logic runs directly on sensors and gateways. IoT applications fundamentally need to detect state transitions, but developers typically must write boilerplate code and manage state persistence manually. Drasi's diff-engine handles state management and change computation automatically, emitting events only when meaningful changes occur. MQTT (Message Queuing Telemetry Transport) is the de-facto standard protocol for IoT, used by AWS IoT Core, Azure IoT Hub, and virtually every IoT deployment. Adding MQTT support to Drasi Lib will unlock the entire IoT ecosystem for Drasi users. In this project, the mentee will build a suite of lightweight Rust crates that enable Drasi Lib to communicate with MQTT brokers. They will create connectors to ingest sensor data (MQTT Source), execute local actions (Shell Reaction), and close the control loop (MQTT Reaction).

Enable ISIS functionality on Sonic

Linux Foundation

<p><strong>*APPLICATION ONLY OPEN TO COLLEGE STUDENTS LOCATED IN CHINA*</strong></p><p><br></p><p><strong style="color: rgb(0, 0, 0); background-color: transparent;">Problem Statement</strong></p><p><br></p><p><span style="color: rgb(0, 0, 0); background-color: transparent;">IS-IS (Intermediate System to Intermediate System) is a link-state routing protocol used as an Interior Gateway Protocol (IGP) in TCP/IP networks.&nbsp;It is widely used in large enterprise networks, ISP backbone networks, and data center networks.&nbsp;It calculates the shortest path using the SPF algorithm, supports a hierarchical structure (Level-1/Level-2), and is known for its high scalability, reliability, and fast convergence.</span></p><p><br></p><p><strong style="color: rgb(0, 0, 0); background-color: transparent;">Mentorship Objectives</strong></p><p><br></p><p><span style="color: rgb(0, 0, 0); background-color: transparent;">ISIS, as a widely used IGP protocol, is already supported in FRR, the routing suite used by Sonic. However, Sonic does not yet support directly enabling and using ISIS protocol functionalities. We need to build the initialization, startup, configuration deployment of isisd in Sonic, and implement the ISIS functionality CLI in Sonic. </span></p>

Encrypted Portable Identity for AI Agents, Soul Protocol (Unpaid)

Linux Foundation

<p>AI agents can't move between platforms. When a user switches runtimes, their agent's memory, personality, and learned behavior disappear, locked into whatever system created them. There's no open standard for encrypting and exporting an agent's cognitive state.</p><p><br></p><p>Soul Protocol defines a&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">.soul</code>&nbsp;file format: an encrypted, portable container for agent identity and memory. It provides core primitives (create, read, write, export, import, encrypt, verify) without prescribing personality models, memory backends, or domain structures.</p><p><br></p><p>This project implements the encryption and portability layer: AES-256-GCM encrypted&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">.soul</code>&nbsp;file export/import, machine-derived key management, digital signature verification on import, and a cross-runtime test suite that validates&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">.soul</code>&nbsp;files across PocketPaw, LangChain, and CrewAI.</p><p><br></p><p>Reference implementation:&nbsp;<a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/github.com/pocketpaw/pocketpaw" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">PocketPaw</a>, 533+ stars, 3,200+ PyPI downloads and growing, 31 contributors, 2,000+ tests, 7-layer security architecture with Guardian AI.</p><p>Academic context: "Everything is Context" (arXiv:2512.05470) formalizes context engineering for agents but treats them as stateless tools. Soul Protocol adds a persistent identity layer, portable, encrypted, and owned by the user.</p><p><br></p><h3>Learning Objectives</h3><ul><li>Understand encryption primitives for portable file formats (AES-256-GCM, PBKDF2 key derivation) and how they apply to identity systems</li><li>Study protocol design principles for thin open standards, looking at how MCP and W3C DID succeeded through minimal interfaces</li><li>Build cross-runtime compatibility layers in Python targeting multiple agent frameworks (PocketPaw, LangChain, CrewAI)</li><li>Practice test-driven development with 90%+ coverage on security-critical code</li><li>Write technical specifications and documentation for an open standard</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ul><li>Encrypted&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">.soul</code>&nbsp;file format specification (AES-256-GCM, machine-derived PBKDF2 keys, Ed25519 signature verification)</li><li>Python SDK:&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">soul.export(encrypted=True)</code>&nbsp;and&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">soul.import(path, key)</code>&nbsp;with complete key management</li><li>Cross-runtime test suite validating&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">.soul</code>&nbsp;portability across PocketPaw, LangChain, and CrewAI</li><li>Developer documentation, quickstart guide, and specification document</li><li>Blog post documenting the mentorship experience, technical decisions, and lessons learned</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/75 " rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/75</a></p>

Extending language and library support in CBOMkit

Linux Foundation

<h3>Description</h3><p>This mentorship project combines both hands-on development and exploratory research.</p><p>CBOMkit currently supports cryptographic detection and analysis for Java, Python, and Go ecosystems. However, a significant portion of production systems relies on other programming languages like C/C++ (used especially in systems programming, embedded environments, and high-performance applications) and widely rely on crypto libraries like OpenSSL.</p><p><br></p><p>On the development side, the mentee will extend CBOMkit to support C/C++, with a primary focus on detecting usage of OpenSSL APIs, and cryptographic primitives. This includes adding C/C++ language support, designing detection logic in sonar-cryptography, integrating it into CBOMkit’s architecture, developing test cases and validating against real-world C/C++ projects, ensuring practical applicability and robustness.</p><p><br></p><p>Additionally, mentee will also test some other policies through existing Open Policy Agent (OPA) integration feature of CBOMkit.</p><p><br></p><p>On the research side, the mentee will analyze additional cryptographic libraries in the C/C++ ecosystem such as wolfSSL, libsodium, BoringSSL, and Botan, along with exploring language support for Rust and its associated cryptographic libraries. The goal is to evaluate their feasibility for future integration into CBOMkit.</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Understand analysis techniques for detecting cryptographic usage</li><li>Gain hands-on experience with cryptographic libraries such as OpenSSL in C/C++</li><li>Learn how to extend and contribute to a production-grade open-source security tool</li><li>Develop skills in designing test cases and validating tools on real-world codebases</li><li>Learn how policy-based security analysis works using Open Policy Agent (OPA)</li><li>Conduct technical research and evaluate cryptographic libraries and programming language for integration</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ul><li>C/C++ language support integrated into sonar-cryptography</li><li>OpenSSL detection module with meaningful coverage</li><li>integration with CBOMkit</li><li>Test suite for validating detection accuracy</li><li>Validation report using real-world C/C++ projects</li><li>Research document comparing additional libraries (wolfSSL, libsodium, BoringSSL, Botan) and language(Rust with its library) for integration feasibility</li><li>Blog post(s) or technical documentation describing implementation and findings</li><li>Evaluation with other policy through OPA</li></ul><h3><br></h3><h3>Recommended Skills</h3><ul><li>Proficiency in java with good understanding of C/C++</li><li>Experience with OpenSSL and general cryptographic APIs</li><li>Good understanding of cryptographic concepts (encryption, hashing, key exchange)</li><li>Experience with static analysis or code parsing (preferred but not mandatory)</li><li>Familiarity with Open Policy Agent</li><li>Familiarity with Git and open-source contribution workflows</li></ul><h3><br></h3><h3>Additional Information</h3><ul><li><a href="https://github.com/cbomkit/sonar-cryptography/blob/main/docs/LANGUAGE_SUPPORT.md" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">https://github.com/cbomkit/sonar-cryptography/blob/main/docs/LANGUAGE_SUPPORT.md</a></li><li><a href="https://github.com/cbomkit/sonar-cryptography/blob/main/docs/DETECTION_RULE_STRUCTURE.md" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">https://github.com/cbomkit/sonar-cryptography/blob/main/docs/DETECTION_RULE_STRUCTURE.md</a></li></ul>

Fablo

Linux Foundation

<p>Fablo is a tool mostly used for local development and in CI. It starts a Hyperledger Fabric network from a single configuration file, and supports various features that makes the development easier (REST API, network snapshots, advanced topology configuration, hooks, etc). It supports Hyperledger Fabric in versions 2.x and 3.x. Last year we were able to ensure feature parity between versions.</p><p><br></p><p>The target user of Fablo is the developer who works with the local Hyperledger Fabric network to either experiment with various topologies or work on contracts. The goal of this internship is to improve the overall developer experience by:</p><p><br></p><ul><li>Ensuring we have up to date and more approachable documentation, kept up to date with the help of AI CI workflows.</li><li>Improving Fablo distribution by supporting npm package along with existing Docker image distribution.</li><li>Resolving friction that is related to random errors, or slow responsiveness of the network setup.</li></ul><p><br></p><p>While a significant part of the proposal is improving the documentation Fablo, the most focus is on automating the process of keeping documentation up to date. This is why the primary focus of this proposal is coding.</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Designing and implementing GitHub Actions workflows</li><li>Using AI agent workflows in real use cases</li><li>Creating concise and approachable documentation</li><li>Debugging and resolving complex issues</li><li>Experience with Hyperledger Fabric network topology, setup and configuration</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ul><li>GitHub Pages with documentation</li><li>GitHub Actions using AI workflows to keep the documentation up to date</li><li>Agent skill file for Fablo</li><li>An additional channel of distributing Fablo (npm)</li><li>PRs with fixes towards reducing developer friction</li></ul><p><br></p><p>Learn More at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/84" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/84</a>.</p>

Fluid

Cloud Native Computing Foundation (CNCF)

To enhance code quality, maintainability, and developer experience, Fluid plans to migrate its unit testing framework from Testify to Ginkgo + Gomega—a more expressive and behavior-driven testing stack widely adopted in the Go ecosystem. Concurrently, we aim to significantly improve unit test (UT) coverage, raising it from the current 57% to at least 75%, thereby reducing regression risks and strengthening overall system reliability Expected Outcome: 1. Deliver comprehensive migration guidelines, coding best practices, and hands-on team training for Ginkgo + Gomega adoption. 2. Achieve a measurable increase in unit test coverage—from 57% to 75%—across core modules of the Fluid codebase.

Formal Methods for Comprehensive Testing of BGP Link-State (BGP-LS)

Linux Foundation

<p>*THIS APPLICATION IS ONLY OPEN TO COLLEGE STUDENTS BASED IN CHINA*</p><p><br></p><p><strong>Problem Statement</strong></p><p><br></p><p>BGP Link State (BGP-LS) is a northbound information exchange protocol extension. It allows external clients to subscribe to and collect link-state data (topology, traffic engineering metrics, segment routing SIDs, etc.). Originally designed as an export mechanism, BGP-LS is being increasingly used as a critical feed-back component in the operation and management of cloud network infrastructures. For example, TE controllers may rely on such information to respond to real-time connectivity and traffic status. Thus, the accuracy and reliability of BGP-LS is of foundational importance.</p><p><br></p><p><br></p><p><strong>Mentorship Objectives</strong></p><p><br></p><p>The objective of this mentorship is to develop systematic tests and validations for the BGP-LS implementation. More specifically, it needs to address complexities at various levels to achieve high coverage of the implementation. For example, at the high level, the stateful nature of the protocol extension itself, as well as the dynamic, disaggregated changes in a router's internal states, require thorough exploration of the handling of diverse interaction scenarios and even inconsistent states. At the low level, data processing utilities, such as the parsing of internal routing data formats, also requires systematic testing to validate the handling of both normal and abnormal data.&nbsp;</p><p><br></p><p><br></p><p><strong>Expected Outcomes and Deliverables</strong></p><p><br></p><p>A set of formal models describing both the expected high-level interactions and low-level processing logics of BGP-LS.</p><p>Benchmarks containing diverse interaction sequences and input data, providing comprehensive behavior and code coverage.</p><p>Testing infrastructures to execute, evaluate, and refine these tests.</p><p><strong>*Program Term: Summer - Fall (May - November) 20 hours of work each week*</strong></p><p><br></p><p><br></p><p><strong>Recommended Qualifications</strong></p><p><br></p><ul><li>Proficiency in Python and C/C++</li><li>Basic knowledge of IP networking and routing</li><li>Basic understanding of distributed systems and concurrency</li><li>Ability to navigate and understand complex codebases</li></ul>

Formal Methods for Refactoring

Linux Foundation

<p><strong>*APPLICATION ONLY OPEN TO COLLEGE STUDENTS BASED IN CHINA*</strong></p><p><br></p><p><strong>Problem Statement</strong></p><p><br></p><p>Software refactoring and restructuring is common in the open-source development of SONiC. Existing code structure may limit the adoption of new usage scenarios or protocol features, necessitating its refactoring into a better logical structure. For example, the ongoing RIB/FIB project intends to separate the RIB and FIB maintenance code in Zebra and move the latter down to SONiC’s fpmsyncd component. Since fpmsyncd resides in SONiC code space, it allows FIB to construct SONiC specific forwarding chain, and handle route convergence based on SONiC’s requirements.</p><p><br></p><p><br></p><p><strong>Mentorship Objectives</strong></p><p><br></p><p>A central requirement in such refactoring is to ensure that behavior changes are exactly as expected. In the RIB/FIB example, it requires that normal executions must be equivalent before and after the refactor. The objective of this mentorship is to devise a systematic approach to validate behavioral equivalence during SONiC refactoring. More specifically, it involves applying formal methods to mathematically describe the intended behavior, compare two distinct setups, and generate comprehensive tests to ensure the consistency before and after the refactor. This will serve as an exemplar of the formal-methods-based correctness paradigm in production code development.</p><p><br></p><p><br></p><p><strong>Expected Outcomes and Deliverables</strong></p><p><br></p><ul><li>Abstract formal models describing expected behavior of the relevant RIB/FIB operations.</li><li>Testing infrastructure that supports parametrized testing of individual modules and execution sequences across modules.</li><li>A test generation framework and the resulting high-coverage benchmark to validate the correctness of the RIB/FIB implementation.</li><li>*<strong>Program Term: Summer / Fall Term (May - November) 20 hours of work each week*</strong></li></ul><p><br></p><p><br></p><p><strong>Recommended Qualifications</strong></p><p><br></p><ul><li>Familiarity with Python and C/C++</li><li>Basic understanding of network forwarding and routing</li><li>Comfort with hands-on systems work under technical guidance, including system setups, trouble shooting, etc.</li><li>Strong communication skills</li></ul>

GitMesh

Linux Foundation

<p>Open source projects face an urgent governance gap as AI coding tools (Claude Code, GitHub Copilot, Cursor, Qwen Code) act on codebases with no shared coordination layer, no policy enforcement, and no auditable trail. The result is PR floods, duplicate issue work, and maintainer burnout.</p><p><br></p><p>GitMesh is an LFDT-native multi-agent orchestration runtime that closes this gap. This mentorship will implement&nbsp;Phase 1 (GitHub/GitLab Forge Integration)&nbsp;and&nbsp;Phase 2 (Policy-as-Code Engine)&nbsp;— building the&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">forge-sync</code>&nbsp;bidirectional webhook service, the&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">policy-engine</code>&nbsp;OPA integration with YAML-to-Rego auto-compilation, an append-only audit log with policy enforcement metadata, and a three-view maintainer dashboard. Real infrastructure, deployed to a live LFDT lab.</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Build a bidirectional webhook-based forge integration (GitHub/GitLab) with event-triggered agent wakeups.</li><li>Design a policy-as-code engine using OPA with YAML-to-Rego auto-compilation and real-time evaluation middleware.</li><li>Implement an append-only audit log capturing policy version and enforcement outcome for every agent action.</li><li>Build a maintainer approval dashboard (Active Agents, Pending Approvals, Audit Log) with mobile-first UX.</li><li>Learn AI agent coordination patterns — atomic checkout, budget enforcement, heartbeat scheduling.</li><li>Gain exposure to LFDT identity extension points (Hyperledger Identus, AnonCreds, Sigstore) planned for the future trust layer.</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ol><li>Forge Integration Service&nbsp;— Bidirectional GitHub/GitLab webhook receiver and outbound action service (post comment, add label, request review, close issue). Includes raw webhook storage and event-triggered agent wakeup support.</li><li>Policy Engine&nbsp;— OPA integration with YAML-to-Rego auto-compilation. Policy evaluation middleware injected into all agent heartbeats and API routes.</li><li>Audit Log Enhancement&nbsp;—&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">policyVersion</code>&nbsp;and&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">policyOutcome</code>&nbsp;columns on the activity log. Append-only, exportable as JSON/CSV, filterable by agent/action/time/outcome.</li><li>Three-View Maintainer Dashboard&nbsp;— Active Agents (status, budget), Pending Approvals (mobile-first), Audit Log (policy filtering).</li><li>Default Policy Template Library&nbsp;— Five ready-to-use YAML rulesets (no-merge-without-approval, no-CI-modification, security-advisory-gate, budget-hard-stop, triage-scope-limits).</li><li>Documentation&nbsp;— Architecture diagram, developer onboarding guide, YAML policy authoring reference, end-to-end test scenarios.</li></ol><p><br></p><p>Learn More at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/81" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/81</a>.</p>

Headlamp

Cloud Native Computing Foundation (CNCF)

Build a Headlamp plugin to surface Kubeflow resources (Pipelines, Katib, PipelineRuns, Notebooks, TFJob/PyTorchJob/TrainJob, Spark) so operators and ML engineers can discover, monitor, and manage ML workloads alongside standard K8s resources. Link to Kubeflow UIs when deeper functionality is needed. - Expected Outcome: - New Kubeflow sidebar with cross-namespace lists for Pipelines (Experiments, Runs), Katib experiments, Notebook servers, Training and Spark jobs. - Detail pages per resource showing metadata, status, metrics, logs and common actions (start Run, open Jupyter, view best hyperparams). - Links/embed to Kubeflow Central Dashboard or Pipelines UI for advanced tasks. - Headlamp Map integration: show relations to Deployments/Pods, Argo workflows, Spark driver/executors. - Metrics via Prometheus or /metrics: basic charts for experiment objectives and pod resource use. - Polished UX: icons, pagination, filtering, error handling. - Outreach: README/User Guide and a demo blog post with screenshots.

Hyperledger Foundation

Blockchain & Ledgers

Hyperledger Foundation is a global enterprise-grade blockchain consortium hosted by the Linux Foundation.

Implementation of Tightly-Coupled Data-Flow Integrity in RISC-V

RISC-V

<p>Data-Flow Integrity (DFI) offers robust protection against memory corruption by ensuring that runtime data flow matches a program's static data-flow graph. However, software DFI suffers from prohibitive overhead. Recent hardware solutions attempt to mitigate this by using decoupled coprocessors (e.g., RvDfi) or alternative architectures, but a tightly coupled approach that extends the ISA directly within the pipeline offers a compelling opportunity to optimize performance and area.</p><p><br></p><p>In a collaboration between the SUSHI research team (Inria Rennes) and the Barcelona Supercomputing Center (BSC), this mentorship implements tightly-coupled DFI in the open-source RISC-V Sargantana core. To ensure a realistic scope, the project is structured in two phases. Phase 1 focuses on hardware: the mentee will collaborate with a student at SUSHI who developed preliminary RTL modifications for the CVA-6 core. This accelerates porting and optimization of these ISA extensions for Sargantana.</p><p><br></p><p>Once the hardware is stable, Phase 2 explores the software stack. To keep the project tractable, the goal is an initial, proof-of-concept toolchain integration. The mentee will leverage adaptations started by SUSHI, using the RVDFI toolchain as a baseline. SUSHI's LLVM experts will provide guidance to help the mentee establish a foundational compiler backend. This phased approach guarantees a solid hardware deliverable while ensuring a full-stack proof-of-concept remains an achievable stretch goal.</p>

Implementation of the RISC-V ISA Extensions for Control-Flow Integrity

RISC-V

<p>Control-flow integrity (CFI) is a fundamental security mechanism that prevents attackers from hijacking a program's execution flow. By exploiting memory vulnerabilities, such as stack-smashing or use-after-free bugs, malicious attackers can corrupt pointers or overwrite return addresses, thereby silently redirecting execution to arbitrary malicious code. RISC-V has recently ratified two ISA extensions to enforce CFI at the hardware level through two complementary primitives. The shadow stack maintains a separate, hardware-protected copy of return addresses, preventing a corrupted call stack from redirecting returns to malicious code. Landing pads require that all valid indirect jumps must land at an explicitly marked location with a special instruction, preventing attackers from redirecting execution to unintended locations.</p><p><br></p><p>In collaboration between the Barcelona Supercomputing Center (BSC) and the SUSHI research team (Inria Rennes), this project aims to implement both CFI extensions on Sargantana, an open-source, Linux-capable, RISC-V core. The mentees will begin by studying the RISC-V CFI specification and the Sargantana microarchitecture, and will then produce an architectural plan of the required pipeline modifications. The mentee will then implement the shadow stack mechanism, including hardware enforcement of shadow stack semantics and access-protection logic. This will be followed by landing pad support, which will involve pipeline enhancements to validate indirect branch targets at commit time. Finally, the mentee will use the Sargantana emulation infrastructure to ensure functional correctness of the implemented extensions and to study the hardware overhead they impose.</p>

Knative Functions

Cloud Native Computing Foundation (CNCF)

<p>Knative Functions ships an MCP (Model Context Protocol) server that exposes its toolchain to AI agents. This project builds on that foundation: deepening the MCP server to cover initial environment setup and CI/CD integration, and authoring a companion skill that walks agents through the full lifecycle of a Function. Together these enable end-to-end agentic usage of Serverless Functions; from initial scaffolding through deployment with CI/CD.</p><p><br></p><p>- Expected Outcome:</p><p>&nbsp;- New agentic installer</p><p>&nbsp;- New MCP operations covering prerequisite checks with guidance.</p><p>&nbsp;- A companion skill that composes initialization, CI/CD setup, and deployment into a guided workflow.</p><p>&nbsp;- End-to-end demonstration.</p><p>&nbsp;- User-facing and agent-facing documentation.</p><p><br></p>

Koordinator

Cloud Native Computing Foundation (CNCF)

<p>AI agentic workflows (multi-agent collaboration frameworks, automated evaluation systems such as SWE-bench) frequently spawn and tear down large numbers of short-lived sandboxes (gVisor, Wasm, Kata Containers) to execute skills or tools. Current Kubernetes scheduling models are too heavy for these transient workloads, causing high latency, weak isolation, and APIServer pressure. This project will extend Koordinator to provide first-class support for AI agent scenarios by integrating sandbox runtimes with Koordinator QoS classes, implementing equivalence-class scheduling for near-identical sandbox requests, and introducing a dedicated Sandbox Pipeline that handles pre-warming, capacity reservation, and actionable scheduling feedback to enable agent self-healing.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Native integration of agent sandbox runtimes (gVisor/Wasm/Kata) with Koordinator QoS classes (LSR, LS, BE) and resource hardening templates</p><p>&nbsp;- Equivalence-class scheduling logic in the Koordinator scheduler that skips redundant Predicate/Priority calculations for batches of similar sandbox pods</p><p>&nbsp;- A Sandbox Pipeline mechanism with pre-warming, automated environment provisioning, and reservation hooks</p><p>&nbsp;- Annotation/Status-based scheduling diagnostics that surface actionable next-step suggestions to upstream agents</p><p>&nbsp;- End-to-end tests and benchmarks demonstrating throughput and latency improvements for high-concurrency sandbox workloads</p><p><br></p>

Kuadrant

Cloud Native Computing Foundation (CNCF)

<p>Kuadrant's MCP Gateway is an Envoy-based gateway for Model Context Protocol (MCP) servers that provides routing, policy enforcement, and tool federation. As the agentic ecosystem grows, we're looking to extend the gateway's capabilities beyond MCP to support other agentic protocols. The A2A (Agent-to-Agent) protocol is an emerging standard for inter-agent communication with capabilities like long-running tasks, streaming, and agent discovery via agent cards. This project will investigate how A2A support can be added to the gateway alongside MCP, then build a proof-of-concept demonstrating federated agent discovery and A2A request routing through the gateway. The mentee will work closely with mentors throughout — collaborating on the design doc, pairing on implementation decisions, and spiking on specific pieces as needed to validate assumptions early. They will also engage with the broader Kuadrant community through PR reviews, design discussions, and community calls.</p><p>- Expected Outcome:</p><p>&nbsp;- Analysis of the A2A protocol with a gap assessment comparing A2A and MCP traffic patterns (request/response vs long-running tasks, push notifications, multi-modal artifacts)</p><p>&nbsp;- Design document covering A2A routing through ext_proc, federated agent card serving in the broker, session handling implications, and CRD design</p><p>&nbsp;- Federated agent card endpoint in the broker that aggregates upstream A2A agent cards</p><p>&nbsp;- A2A request routing through the Envoy ext_proc path, with appropriate header handling and policy enforcement</p><p>&nbsp;- CRD design (new resource or MCPServerRegistration extension) for registering A2A agents with the gateway controller</p><p>&nbsp;- E2E tests demonstrating A2A agent discovery and task execution through the gateway</p><p><br></p>

LF Energy - Hyphae APIS

Linux Foundation

<p>With energy resources and infrastructure increasingly challenged to meet the coming impacts of climate change and natural disasters, Hyphae aims to make the grid more resilient and flexible with microgrids. By providing an Autonomous Power Interchange System (APIS), Hyphae automatically and efficiently distributes locally-produced renewable energy over a DC grid to interconnect with AC Grids. With resilient, physical peer-to-peer microgrid energy trading, even the most remote communities will be able to store and distribute energy autonomously without connecting to large-scale power stations or electrical distribution networks. Sponsored-Term: This is a 10-12 week project that aims to stabilize APIS repositories and integrate the energy trading mechanism with enAccess PayGo Token (https://github.com/EnAccess/OpenPAYGO-python) . We are looking to raise $6000 for registration and travel expenses to OSEAS 2026 (https://www.oseas.org/)</p><p>For the Spring 2026 cohort, we will also look into integrating with GAIFARE from Open Renawable Energy Systems LF Energy program to see what AI can bring to the Hyphae use cases.</p>

LF Research

Linux Foundation

LF Research publishes actionable and decision-useful insights into open source software, hardware, standards, and data based on empirical research methodologies. Through leveraging community networks, project databases, surveys, and qualitative findings, and through its commitment to best practices in primary research, Linux Foundation Research is the definitive home for data-driven insights into open source for the benefit of governments, enterprises, and society at large.

LFDT - Advanced Threshold Key Management

Linux Foundation

<p>In standard cryptography, a single compromised key means total failure. Threshold Cryptography eliminates this risk. Using a Distributed Key Generation (DKG),&nbsp;n&nbsp;participants generate a&nbsp;t-out-of-n&nbsp;key where the full secret is never reconstructed in one place. Operations like signing or decryption happen via interactive protocols like CGGMP24 or FROST.</p><p><br></p><p>In this project, you are invited to build the "lifecycle" tools required for production-ready key management:</p><ul><li>Key Share Repair:&nbsp;t&nbsp;parties restore a lost share for a peer, "healing" the network without exposing the secret.</li><li>Key Refresh:&nbsp;Enables proactive security by rotating shares. This protects from "low and slow" attackers, as shares from different epochs are mathematically incompatible.</li><li>Key Reshare:&nbsp;Dynamically changes the participant set or the threshold&nbsp;t, allowing the security policies to evolve.</li></ul><p><br></p><p>Protocol implementation will follow an academic paper: for instance, Key Refresh protocol can be adapted from&nbsp;<a href="https://eprint.iacr.org/2021/060.pdf" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">CGGMP24 paper</a>&nbsp;(see Fig. 7). Development will leverage the Lockness ecosystem, utilizing&nbsp;<code style="color: rgb(9, 105, 218); background-color: rgba(129, 139, 152, 0.12);"><a href="https://github.com/LFDT-Lockness/round-based" rel="noopener noreferrer" target="_blank">round-based</a></code>&nbsp;as MPC framework and&nbsp;<code style="color: rgb(9, 105, 218); background-color: rgba(129, 139, 152, 0.12);"><a href="https://github.com/LFDT-Lockness/generic-ec" rel="noopener noreferrer" target="_blank">generic-ec</a></code>&nbsp;for elliptic-curve arithmetics.</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Deep Dive into MPC &amp; Threshold Primitives: Transition from theoretical knowledge of cryptography to implementing complex Multi-Party Computation (MPC) protocols, and gain a first-hand understanding of how&nbsp;t-out-of-n&nbsp;security is maintained mathematically.</li><li>Rust Development in the Lockness Ecosystem: Master high-performance, memory-safe programming by contributing to the Lockness ecosystem, specifically using the&nbsp;<code style="color: rgb(9, 105, 218); background-color: rgba(129, 139, 152, 0.12);"><a href="https://github.com/LFDT-Lockness/generic-ec" rel="noopener noreferrer" target="_blank">generic-ec</a></code>&nbsp;library for efficient and type-safe elliptic curve operations.</li><li>Modern Distributed Programming:&nbsp;Learn to write asynchronous code via the&nbsp;<code style="color: rgb(9, 105, 218); background-color: rgba(129, 139, 152, 0.12);"><a href="https://github.com/LFDT-Lockness/round-based" rel="noopener noreferrer" target="_blank">round-based</a></code>&nbsp;framework to manage complex network interactions.</li><li>From Paper to Production:&nbsp;Develop the ability to translate academic research into reliable, auditable, high-quality code, bridging the gap between "whitepaper math" and "real-world software".</li><li>Production-Grade Workflow:&nbsp;Experience a professional development lifecycle where cryptographic code is subject to rigorous peer reviews and testing to ensure maximum security. Learn the discipline required to build cryptographic libraries where every line of code must be verified for both correctness and security.</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><p>Standalone libraries that implement mentioned protocols</p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/56" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/56</a></p>

LFDT - Build and release a Java SDK for Paladin

Linux Foundation

<p>Paladin is a programmable privacy solution for EVM blockchains. It provides a framework for deploying and working with private tokens and EVM-compatible private smart contracts for private, programmable on-chain logic such as atomic swaps.</p><p><br></p><p>See&nbsp;<a href="https://www.paladinprivacy.org/" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">https://www.paladinprivacy.org/</a>&nbsp;and&nbsp;<a href="https://lfdt-paladin.github.io/paladin/head/" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">https://lfdt-paladin.github.io/paladin/head/</a></p><p><br></p><p>To work with Paladin tokens and private smart contracts applications typically use one of the existing SDKs - currently available for Go and Typescript.</p><p>There are users keen to build Java applications that utilize all of the Paladin privacy features in a performant, language-idiomatic way.</p><p><br></p><h3>Learning Objectives</h3><ol><li>Understand all the basic components and privacy patterns of Paladin</li><li>Understand the Paladin REST APIs and and their inputs/outputs</li><li>Review the existing SDKs to understand what feature-parity of a new SDK would look like</li></ol><h3>Expected Outcome and Deliverables</h3><ul><li>A Java SDK available as a published dependency for Java applications to consume</li><li>Request/reply and web-socket event-driven interfaces</li><li>A repeatable release process integrated with the current release pipeline</li><li>A high degree of test coverage of the new SDK</li></ul><p><br></p><p>Ultimately we are looking for a well designed SDK that feels natural to Java application developers to use, and makes use of current, idiomatic language features.</p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/64" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/64</a></p>

LFDT - Continuous Benchmarking for Besu EVM

Linux Foundation

<p>Besu includes comprehensive EVM benchmarking tooling — including JMH microbenchmarks for 40+ EVM operations, precompile benchmarks via&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">evmtool benchmark</code>, and full blockchain-level test execution via&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">evmtool block-test</code>. However, these benchmarks are currently only run manually by developers on local machines. There is no automated way to track performance over time, detect regressions introduced by PRs, or visualize trends.</p><p><br></p><p>This project aims to build a continuous benchmarking pipeline for the Besu EVM, for example by integrating existing benchmark tooling into CI. The mentee will discuss a solution with Besu maintainers, design and implement automated (and/or manually triggered) workflows that run EVM benchmarks, collect results, store historical data, and produce reports that give maintainers clear visibility into performance changes.</p><p><br></p><p>An excellent reference for the kind of output we'd like to achieve is the&nbsp;<a href="https://benchmarks.ethrex.xyz/gas-benchmark-eest/" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">ethrex gas benchmarks dashboard</a>, which provides comparative benchmark reports with sortable tables, speedup metrics, and historical tracking across runs.</p><p><br></p><p>Besu's existing benchmark tooling includes:</p><ul><li>JMH microbenchmarks&nbsp;(<code style="background-color: rgba(129, 139, 152, 0.12);">ethereum/core/src/jmh/</code>) — 40+ benchmarks covering EVM arithmetic, bitwise, shift, stack, memory, and crypto operations (reported in execution time only)</li><li>Precompile benchmarks&nbsp;(<code style="background-color: rgba(129, 139, 152, 0.12);">evmtool benchmark</code>) — benchmarks for AltBN128, EcRecover, ModExp, BLS12, P256Verify, SHA256, RIPEMD-160, and KZG Point Eval with throughput metrics (MGps)</li><li>Block-test execution&nbsp;(<code style="background-color: rgba(129, 139, 152, 0.12);">evmtool block-test</code>) — full blockchain reference test execution with timing and pass/fail reporting</li><li>Shell-based benchmark scripts&nbsp;(<code style="background-color: rgba(129, 139, 152, 0.12);">ethereum/evmtool/src/test/benchmarks/</code>) — existing scripts for static operations, loop operations, and mainnet-like contract execution</li></ul><p><br></p><p>The project scope could include:</p><ol><li>CI Workflow Design&nbsp;— Create GitHub Actions workflows (manually triggered in the first instance) that run selected benchmarks on consistent hardware.</li><li>Results Collection and Storage&nbsp;— Design a scheme for storing benchmark results over time (e.g., GitHub Pages, artifact storage, or a lightweight results repo).</li><li>Reporting and Visualization&nbsp;— Find/build a dashboard or report format that shows performance trends, highlights regressions, and allows comparison between runs.</li><li>PR Integration&nbsp;— Optionally, enable benchmark runs on PRs that touch EVM-critical code paths, with summary comments showing performance impact.</li><li>Documentation&nbsp;— Document how to run, extend, and interpret the benchmarks.</li><li>RPC Performance&nbsp;- As a stretch goal could also cover RPC performance, such as eth_call.</li></ol><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/69" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/69</a></p>

LFDT - Exploring Chaincode Support for Hyperledger Fabric-X

Hyperledger

<p>Hyperledger Fabric has been available for several years and there are many production networks using Chaincode. Fabric-X has just been released and it introduces changes to the current way of deploying applications. This brings up the question on how to migrate existing applications and chaincodes to this new environment.</p><p>The goal of this mentorship project is to:</p><ul><li>Explore the feasibility to run existing Fabric Chaincode on Fabric-x;</li><li>Design and develop a proof of concept that showcases Go Chaincode for Fabric-X;</li><li>Implement a prototype of the components identified;</li><li>Identify a demo use case (i.e., Fabric Samples, CC-Tools, Fabric Private Chaincode) that comes with go chaincode;</li><li>Produce documentation that explains the architecture and how it can be used as well as potential avenues of development.</li></ul><h3>Learning Objectives</h3><ul><li>Deep dive into Hyperledger Fabric and Fabric-X.</li><li>Experience an active open-source community.</li><li>Mastering open-source workflow.</li><li>Enhance your designing and implementing skills, testing, documentation, and project management.</li></ul><h3>Expected Outcome and Deliverables</h3><ul><li>Proof of Concept that showcases an alternative on how to migrate classic Fabric go chaincode to Fabric-X.</li><li>Documentation that explains the demo and how to run it.</li><li>Bonus: a technical blog post and meetup talk.</li><li>Having fun.</li></ul><p><br></p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/59" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/59</a></p>

LFDT - Extending Hiero Enterprise Java with Smart Contract Event and Log APIs

Linux Foundation

<p>The&nbsp;<a href="https://github.com/hiero-ledger/hiero-enterprise-java" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">hiero-eneterprise-java</a>&nbsp;project provides a layer on top of Hiero SDKs to integrate Hiero functionality in enterprise java applications that are based on frameworks like JakartaEE, Microprofile, Quarkus or Spring Boot. Instead of just defining the SDK API, the project creates a layer on top of it by providing services and repositories for an easier and integrated interaction with any Hiero based network.</p><p><br></p><p>The project invests in rich and easy to use APIs to interact with smart contracts. While deploying smart contracts and calling functions of contracts is already part of the project, the log and event functionality of smart contracts is missing. This functionality allows smart contract functionalities to share information with external observers of the contract. Hiero events and logs of smart contracts can be accessed by the&nbsp;<a href="https://github.com/hiero-ledger/hiero-mirror-node" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">Hiero mirror node</a>. Sadly the workflow is very complex, and now easy to use API exists to easily receive events for a specific smart contract instance.</p><p><br></p><p>This project should extend hiero-enterprise-java by providing a new public API and implementation for events and log observation of smart contracts.</p><p><br></p><h3>Learning Objectives</h3><ul><li>Understanding smart contracts and Solidity as smart contract language.</li><li>Understanding best practices for creating smart contracts.</li><li>Deploy smart contracts and interact with smart contracts on an Hiero based network.</li><li>Understand the Hiero SDKs.</li><li>Understand the Hiero Mirror Node.</li><li>Learn about hiero-eneterprise-java and best practices for providing functionality to enterprise Java frameworks.</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><p>The successful completion of this project will result in new code and modules in the hiero-eneterprise-java project. Tests, documentation and samples of the new functionality are part of the expected outcome.</p><p><br></p><p>Mostly, all new content will be part of the hiero-eneterprise-java project (excluding stand alone examples).</p><p><br></p><p>We expect that events and logs of any deployed smart contracts can be observed by the API (by using callbacks).</p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/70" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/70</a></p>

LFDT - Fablo

Linux Foundation

<p>Hyperledger Fabric-X introduces a new architecture for Fabric, with decomposed services for ordering, endorsement, validation, and committing, but its current developer workflow is still centered around dedicated deployment scripts and Ansible-based setup.</p><p>Fablo, on the other hand, is widely used to start Hyperledger Fabric networks quickly from a single configuration file for local development, CI, and experimentation.</p><p>This project will explore and implement the best path to support a simple local Fabric-X network through the Fablo experience. We will evaluate architectural options such as a new engine, a separate repo, or an extension/wrapper approach, then build a minimal but practical MVP that can generate configuration, bootstrap the required components, and start/stop a working local Fabric-X network. The goal is to reduce setup friction for contributors and users, and provide a repeatable developer workflow, examples, and documentation that make Fabric-X easier to try, demo, and extend.</p><h3>Learning Objectives</h3><ul><li>Understand the architecture and deployment model of Hyperledger Fabric-X, including how it differs from classic Hyperledger Fabric.</li><li>Learn how to design contributor-facing tooling for distributed systems with evolving architecture.</li><li>Gain experience in open source development across CLI/tooling, configuration generation, testing, and documentation.</li><li>Develop practical skills in Docker-based environments, and debugging multi-component systems.</li></ul><h3>Expected Outcome and Deliverables</h3><ul><li>A design proposal describing the recommended integration path between Fablo and Fabric-X (for example: separate repo, pluggable engine, or wrapper-based approach).</li><li>An MVP implementation that can bootstrap a simple local Fabric-X network and manage its lifecycle.</li><li>Example configuration(s) and sample workflow for running Fabric-X through the proposed Fablo-based experience.</li><li>Automated tests and/or validation scripts covering the supported MVP scenario.</li><li>Contributor and user documentation explaining setup, architecture decisions, and next steps.</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/83" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/83</a></p>

LFDT - Fabric-x EVM Compatibility

Linux Foundation

<p>The Fabric / Fabric-X EVM Gateway adds a standard Ethereum JSON-RPC interface and an embedded go-ethereum EVM execution path to a permissioned Fabric(X) network. Client transactions are simulated by EVM Endorsers against a custom&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">StateDB</code>&nbsp;wrapper that builds Fabric-style read–write sets (rwsets) and preserves Fabric endorsement, ordering, and MVCC validation—while remaining fully compatible with Ethereum tools and semantics (e.g.,&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">msg.sender</code>, receipts, logs).</p><p><br></p><p>This mentorship centers on&nbsp;hardening and concurrency: implementing a durable, correct mempool/queue with retry logic that masks MVCC conflicts from Ethereum clients; enforcing ledger-tracked Ethereum nonces decoupled from Fabric txIDs with endorser-side checks; handling client bursts and replacement transactions; ensuring API-visible consistency across processes/restarts and (eventually) across multiple gateway replicas; and validating event/log hygiene so non-committing executions never leak to clients.</p><p><br></p><p>Candidates will work in Go, touch the gateway/endorser boundary, and contribute tests and docs that make the gateway robust under failures (kill/restart), high load, and contention.</p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/72" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/72</a></p>

LFDT - Hiero

Linux Foundation

<p>Open source collaboration platforms rely heavily on email-based identity and platform accounts for contributor attribution.</p><p>While widely adopted and convenient, this model has limitations: commit author metadata can be spoofed, contributor identity is fragmented across projects / ecosystems and hard to verify, and trust relationships are challenging to establish without additional verification on a person-to-person basis.</p><p>Current GitHub contribution workflows face multiple risks, including commit author impersonation and email-based identity spoofing.</p><p>These risks became even more relevant with advancements of Agentic AI capable of identity impersonation and "flooding" open source projects with low-quality or even malicious contributions.</p><p>From a technical perspective, there are many ways to mitigate these risks. However, not all of them are suitable for open source specifically – decentralized and transparent trust along with self-sovereign identity management are crucial factors.</p><p><br></p><p>Compromising on these principles can lead to a less trustworthy relationship between individual contributors and the projects, as well as it can create a higher entry barrier for new contributors.</p><p><br></p><p>We believe that decentralized identity concepts (<a href="https://www.w3.org/TR/did-1.1/" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">Decentralized Identifiers (DIDs)</a>&nbsp;and&nbsp;<a href="https://www.w3.org/TR/vc-data-model-2.0/" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">Verifiable Credentials (VCs)</a>) can help to mitigate the spoofing and impersonation risks without compromising trust, providing a more secure and trustworthy way to recognize contributors.</p><p><br></p><p>This project proposes the development of a prototype (with long-term development potential) for contributor identity validation in Hiero that will leverage existing tools / applications available in Hiero Identity ecosystem, including the new&nbsp;<a href="https://github.com/hiero-ledger/heka-identity-platform" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">Heka Identity Platform</a>.</p><p><br></p><p>The prototype will be tested in a real-world scenario using one of Hiero open-source repositories (e.g.,&nbsp;<a href="https://github.com/hiero-ledger/identity-collaboration-hub" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">Identity Collaboration Hub</a>, DID SDKs, or Heka Identity Platform repo itself).</p><p><br></p><h3>Expected Outcome and Deliverables</h3><p>The successful completion of this project will result in a working prototype for contributor identity verification that can be used safely across Hiero repositories.</p><p>Expected deliverables include:</p><ul><li>A GitHub App capable of verifying contributor identity using DID and VC / VP</li><li>Implementation of a contributor onboarding workflow based on Heka Identity Platform</li><li>Implementation of pull request verification workflow leveraging contributor DID and Linked VP</li><li>Full integration demo with GitHub pull requests in one of the Hiero repositories</li><li>Documentation and high-level design for future development</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/87" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/87</a></p>

LFDT - Hiero Github Workflow App

Linux Foundation

<p>The Hiero ecosystem includes a growing number of diverse contributors, repositories, junior committers/committers/maintainers, pull requests, issues, discussions, and quality requirements.</p><p><br></p><p>To build a diverse ecosystem which generates high-quality code, maintainers need to spend a significant amount of time on repetitive coordination tasks such as checking contributor qualifications, validating pull request quality, un-assigning inactive contributors, closing stale issues, creating issues at different difficulties, and ensuring that repository processes are followed consistently.</p><p><br></p><p>We have demonstrated in some SDK repositories many of these maintainer tasks can be automated using custom GitHub action workflows and templates. However, the current setup is fragmented, difficult to customize and scale, and inconsistent across repositories. Different repositories may require different rules, but maintainers still need support to ensure they are working on the most important tasks, and developers need support to help them progress quickly and qualify to gain more responsibilities.</p><p><br></p><p>This mentorship project aims to design and build an automation framework and application for Hiero end-to-end maintainer workflows. The system should support configurable repository automation features that maintainers can turn on or off, depending on the repository context.</p><p><br></p><p>Example user on-boarding workflows:</p><ul><li>Checking contributors are humans</li><li>Checking whether contributors meet contribution requirements before assigning issues</li><li>Offering automatic issue assignment</li><li>Automatically assigning mentors for new contributors</li><li>Issue templates and documentations</li></ul><p>Example pull request review and quality workflows:</p><ul><li>AI issue planning</li><li>AI initial reviewing</li><li>Automated code quality, DCO, GPG, etc checks based on configurable quality requirements</li><li>Automatic review based on configurable quality requirements</li></ul><p>Example developer progression workflows:</p><ul><li>Automatic issue recommendations after a merged pull request to next available issues</li><li>Checking whether advanced contributors meet requirements to progress to JC/committer/maintainer</li></ul><p>Example issue management workflows:</p><ul><li>Managing stale issues or pull requests</li><li>Requesting help or feedback from specified teams based on labels</li></ul><p><br></p><p>A core requirement of the project is to ensure that this automation is reliable, consistent, secure, and scalable enough to be used across a variety of repositories inside Hiero (and one day optionally across LFDT).</p><p><br></p><p>The project should also define clear boundaries for what the automation is allowed to do, how maintainers configure it, and how users can understand or override automated actions when necessary.</p><p>The result should not just be a prototype for a single repository, but a hardened and reusable solution that can serve multiple Hiero repositories with different policies and maintenance needs. </p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/73" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/73</a></p>

LFDT - Hyperledger Fabric Token SDK Sample

Hyperledger

<p>The Hyperledger Fabric Token SDK sample (fabric-samples/token-sdk) is a reference application demonstrating how to issue, transfer, and redeem privacy-preserving tokens on a Hyperledger Fabric(X) network using Zero Knowledge Proofs and the UTXO model.</p><p><br></p><p>The sample was originally created in October 2023 and currently pins to Token SDK v0.3.0 and an older version of the Fabric Smart Client. Since then, both the Token SDK and Fabric Smart Client have evolved significantly. The sample needs to be updated to track the latest library versions, and several features listed as "out of scope" in the original implementation are now feasible and would significantly improve the sample's value as a learning and prototyping resource.</p><p><br></p><p>This project targets contributors who want to gain hands-on experience with privacy-preserving token systems, Zero Knowledge Proofs on Hyperledger Fabric, Go-based distributed application development, and REST API design.</p><p><br></p><h3>Learning Objectives</h3><p>By the end of this mentorship, the mentee will be able to:</p><ol><li>Navigate and contribute to a real-world open source Go project within the Hyperledger / LF Decentralized Trust ecosystem, following standard PR and code review workflows.</li><li>Understand the architecture of the Hyperledger Fabric Token SDK — including the roles of issuer, auditor, and owner — and how they communicate via Fabric Smart Client.</li><li>Manage and upgrade Go module dependencies in a multi-module repository, resolving version conflicts and validating compatibility across fabric-token-sdk and fabric-smart-client.</li><li>Explain how privacy-preserving token transactions work using the UTXO model and Zero Knowledge Proofs (specifically the dlog/zkatdlog proof system), and implement or extend token flows accordingly.</li><li>Design and implement REST API endpoints using OpenAPI / Swagger and oapi-codegen, following the existing patterns in the sample.</li><li>Write end-to-end integration tests for distributed multi-party applications running on a local Fabric(X) network via Docker Compose.</li></ol><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/66" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/66</a></p>

LFDT - Hyperledger Fabric to Fabric-X Ledger Migration Tool

Hyperledger

<p>Hyperledger Fabric-X is a ground-up re-architecture of Hyperledger Fabric designed for national-scale regulated digital-asset systems, achieving 400 K+ TPS through independently scalable micro-services. For enterprise adoption, existing Fabric deployments must be able to migrate their ledger state to Fabric-X without losing transactional history or state integrity.</p><p><br></p><p>This project defines and implements an end-to-end ledger migration path using Fabric's official peer snapshot mechanism as the source of truth. Two architectural gaps must be bridged: (1) Fabric organizes state by channel, namespace, and collections, whereas Fabric-X uses a only namespaces, and (2) Fabric snapshots contain private-data-collection (PDC) artifacts that have no equivalent in Fabric-X.</p><p><br></p><p>The mentee will design a channel-to-namespace mapping strategy, build an Exporter tool that parses Fabric snapshots and produces a portable genesis-data file, and implement a Bootstrap procedure inside the Fabric-X committer that ingests that file and verifies state integrity post-migration.</p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/65" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/65</a></p>

LFDT - Hyperledger Identus - Identity Portal

Hyperledger

<p>Hyperledger Identus provides mature backend services (Cloud Agent, Mediator) and Edge Agent SDKs (TypeScript, Kotlin Multiplatform, Swift) for building Self-Sovereign Identity (SSI) solutions.</p><p><br></p><p>This mentorship project will deliver a&nbsp;lightweight, unified agent interface&nbsp;— primarily a web-based reference dashboard — that supports:</p><ul><li>Offline-first / non-custodial mode&nbsp;— powered entirely by the TypeScript Edge Agent SDK running in the browser, with CIP-30 Cardano wallet integration (via MeshSDK) for PRISM DID operations.</li><li>Connected / custodial mode&nbsp;— optional connection to an existing Cloud Agent instance via a configurable API endpoint.</li></ul><p>Core architectural principles</p><ul><li>Offline-first by default&nbsp;— If no&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">CLOUD_AGENT_API_ENDPOINT</code>&nbsp;is provided, the application runs fully in the browser with no backend dependencies.</li><li>Maximal reusability&nbsp;— Core SSI logic is built as pure TypeScript modules / utilities that can be reused in other projects (web, React Native,, custom dApps, etc.).</li><li>Minimal vendor lock-in&nbsp;— No UI component kits (e.g., no shadcn/ui); use plain Tailwind CSS + simple, custom, portable components.</li><li>Stable &amp; compatible stack&nbsp;— Target React 18 (latest stable non-experimental version) to maximize future compatibility with projects.</li><li>Modular structure&nbsp;— Separate concerns: pure SSI logic → service adapters (Edge vs Cloud) → presentation layer.</li></ul><h3>Learning Objectives</h3><ul><li>Deep understanding of SSI concepts: Decentralized Identifiers (DIDs – especially PRISM method), Verifiable Credentials (JWT, SD-JWT, AnonCreds), schemas, revocation, DIDComm messaging, trust frameworks, issuer/holder/verifier roles</li><li>Hands-on experience with the Hyperledger Identus ecosystem: Cloud Agent REST APIs, TypeScript Edge Agent SDK, Mediator coordination, PRISM DID resolution &amp; publishing to Cardano, Verifiable Data Registry</li><li>Building reusable, framework-agnostic TypeScript code for SSI workflows</li><li>Implementing a unified UI system for both the Cloud Agent and the Edge Agent (offline first)</li><li>Practice open-source development workflows, including code review, documentation, community engagement, and incremental delivery</li></ul><p><br></p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/77" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/77</a></p>

LFDT - Implement DKLs23 (threshold ECDSA) protocol

Linux Foundation

<p>In standard cryptography, a single compromised key means total failure. Threshold Signing Schemes (TSS) mitigate this by distributing "shares" of a key across&nbsp;n&nbsp;participants, requiring a minimum threshold&nbsp;t&nbsp;participants to engage into the protocol to generate a signature. While the Lockness ecosystem already has a CGGMP24, a threshold ECDSA protocol, the&nbsp;<a href="https://eprint.iacr.org/2023/765.pdf" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">DKLs23</a>&nbsp;protocol presents different features and performance, and unlocks new use-cases.</p><p><br></p><p>In this project, your goal is to transform a formal description of the protocol from the&nbsp;<a href="https://eprint.iacr.org/2023/765.pdf" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">DKLs23 paper</a>&nbsp;into the code utilizing&nbsp;<code style="color: rgb(9, 105, 218); background-color: rgba(129, 139, 152, 0.12);"><a href="https://docs.rs/round-based/latest/round_based/" rel="noopener noreferrer" target="_blank">round-based</a></code>, a framework for TSS protocols, and&nbsp;<code style="color: rgb(9, 105, 218); background-color: rgba(129, 139, 152, 0.12);"><a href="https://docs.rs/generic-ec/latest/generic_ec/" rel="noopener noreferrer" target="_blank">generic-ec</a></code>, a type-safe library for elliptic-curve arithmetics.</p><p><br></p><h3>Learning Objectives</h3><ul><li>Deep Dive into MPC &amp; Threshold Primitives: Transition from theoretical knowledge of cryptography to implementing complex Multi-Party Computation (MPC) protocols, and gain a first-hand understanding of how&nbsp;t-out-of-n&nbsp;security is maintained mathematically.</li><li>Rust Development in the Lockness Ecosystem: Master high-performance, memory-safe programming by contributing to the Lockness ecosystem, specifically using the&nbsp;<code style="color: rgb(9, 105, 218); background-color: rgba(129, 139, 152, 0.12);"><a href="https://github.com/LFDT-Lockness/generic-ec" rel="noopener noreferrer" target="_blank">generic-ec</a></code>&nbsp;library for efficient and type-safe elliptic curve operations.</li><li>Modern Distributed Programming:&nbsp;Learn to write asynchronous code via the&nbsp;<code style="color: rgb(9, 105, 218); background-color: rgba(129, 139, 152, 0.12);"><a href="https://github.com/LFDT-Lockness/round-based" rel="noopener noreferrer" target="_blank">round-based</a></code>&nbsp;framework to manage complex network interactions.</li><li>From Paper to Production:&nbsp;Develop the ability to translate academic research into reliable, auditable, high-quality code, bridging the gap between "whitepaper math" and "real-world software".</li><li>Production-Grade Workflow:&nbsp;Experience a professional development lifecycle where cryptographic code is subject to rigorous peer reviews and testing to ensure maximum security. Learn the discipline required to build cryptographic libraries where every line of code must be verified for both correctness and security.</li></ul><p><br></p><h3>Expected Outcome and Deliverables</h3><p>A library that implements DKLs23 protocol.</p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/58" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/58</a></p>

LFDT - Implementation of a ZK-SNARK Token Driver for Hyperledger Fabric using gnark

Hyperledger

<p>This project aims to implement a new privacy-preserving token driver for the Hyperledger Fabric Token SDK. The architecture will follow the blueprint established in the paper "Privacy-preserving auditable token payments in a permissioned blockchain system" (Androulaki et al.), which outlines a token management system tailored for enterprise networks that requires binding tokens to user identities while supporting fine-grained auditing functionalities for AML/KYC compliance.</p><p><br></p><p>While the original paper relies on specific zero-knowledge proofs and commitments, this mentorship project will adapt the cryptographic backend to utilize zk-SNARKs via gnark, a high-performance ZK-SNARK library written in Go by Consensys. The mentee will be responsible for designing the required ZK circuits for minting, transferring, and auditing tokens, and subsequently integrating these circuits into a fully functional token driver within the Fabric Token SDK framework.</p><p><br></p><h3>Learning Objectives</h3><ul><li>Gain a comprehensive understanding of the Hyperledger Fabric Token SDK architecture and the role of token drivers.</li><li>Develop practical expertise in Zero-Knowledge Proofs (zk-SNARKs) and circuit design using the gnark library.</li><li>​- Understand the cryptographic mechanisms behind privacy-preserving enterprise blockchains, including UTXO models, Pedersen commitments, and identity-bound token ownership.</li><li>Enhance skills in writing highly optimized, concurrent, and secure Go code for distributed systems.</li></ul><h3>Expected Outcome and Deliverables</h3><ul><li>Fully functional gnark circuits implementing the logic for token issuance, private transfers, and auditor revelation as described in the blueprint paper.</li><li>A new ZK-SNARK token driver completely integrated into the Hyperledger Fabric Token SDK.</li><li>A comprehensive test suite, including unit and integration tests for the driver and circuits.</li><li>​- Performance benchmarks evaluating proof generation times, verification times, and transaction throughput compared to existing FTS token drivers.</li><li>Technical documentation detailing the circuit design, driver architecture, and usage instructions.</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/67" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/67</a></p>

LFDT - Improve usability, maintainability, and contributor experience of Hyperledger Cacti

Hyperledger

<p>This mentorship focuses on improving the usability, maintainability, and contributor experience of Hyperledger Cacti. Following the merger of Hyperledger Cactus and Weaver, the codebase and architecture have grown complex, with fragmented documentation and legacy components that hinder onboarding and long-term sustainability.</p><p><br></p><p>The project targets the ongoing Cacti Cleanup Initiative, aiming to simplify architecture, remove deprecated modules, improve security, and create high-quality documentation. The mentee will audit and restructure developer and user documentation, align docs with the evolving architecture, identify outdated components for removal, and improve onboarding guides and contribution workflows.</p><p><br></p><p>Implementation will follow an iterative process: reviewing GitHub issues and cleanup boards, proposing improvements, implementing updates to documentation and selected code areas, and validating improvements with maintainers. The outcome will be a streamlined, well-documented Cacti framework that lowers entry barriers for contributors and strengthens the project’s long-term sustainability.</p><p><br></p><h3>Learning Objectives</h3><ul><li>Understand cross-chain architectures and pluggable DLT frameworks</li><li>Gain experience contributing to a large open-source project under the LF Decentralized Trust ecosystem</li><li>Learn best practices for technical documentation, developer experience, and onboarding design</li><li>Develop skills in codebase refactoring, modularization, and security-driven cleanup</li><li>Collaborate with an international open-source community using GitHub, CI/CD pipelines, and review workflows</li></ul><h3>Expected Outcome and Deliverables</h3><ul><li>A restructured and standardized documentation suite (developer, user, and architecture docs)</li><li>Cleanup contributions removing deprecated or low-value components and simplifying modules</li><li>Improved onboarding guides, tutorials, and contributor documentation</li><li>CI/CD improvements reducing pipeline runtime and complexity (where applicable)</li><li>A final report summarizing changes, impact, and recommendations for future improvements</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/62" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/62</a></p>

LFDT - Improving Hyperledger Solang Through Comparative Analysis with the Soroban Rust SDK

Hyperledger

<p>Hyperledger Solang is a Solidity compiler to multiple non-EVM targets, including Stellar's Soroban. The Soroban VM is inherently different than the EVM. Also, How Solang translates Solidity to Soroban's WASM is different from the Rust SDK: A different storage layout, different encoding/decoding mechanisms and different optimizer passes as well.</p><p><br></p><p>The main smart contracts SDK for Soroban is&nbsp;<a href="https://github.com/stellar/rs-soroban-sdk" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">the Rust soroban SDK</a>. The purpose of this mentorship is to do an in-depth evaluation of Solang's soroban contracts runtime cost and behavior against the main Rust SDK. This evaluation is critical to Solang's health: We need a reproducible way to validate the design choices of how Solang handles storage operations and encoding/decoding on Soroban.</p><p><br></p><p>The mentorship will be in 3 stages:</p><ol><li>Getting familiar with Solang's code base. This could be done by implementing a Soroban specific feature in Solidity. This task will touch all stages of the compiler, thus enabling the mentee to get familiar with the code base as well as concepts around the Soroban VM and Solidity.</li><li>Implement a differential testing tool for the currently supported Soroban Solidity contracts. The tool should take an input a Solidity contract and a Rust contract, and should provide:</li><li class="ql-indent-1">Runtime cost comparisons, ideally by deploying to Solang's mock Soroban VM.</li><li class="ql-indent-1">Behavioral comparison.</li><li class="ql-indent-1">An interpretation of <span style="color: rgb(31, 35, 40);">the runtime cost for each contract, i.e number of Soroban host function calls, guest memory used, etc...</span></li><li>Publish a list of recommendations that Solang (or the Rust SDK) should improve. Recommendations should be backed up with evidence from the tool defined at stage 2</li></ol><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/74" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/74</a></p>

LFDT - Refactoring and Evolution of the Besu Plugin API

Linux Foundation

<p>The Besu team has been pushing heavily on extensibility via plugins, as a way to support Layer 2 or private networks, without needing to fork the core Besu codebase, with Linea being a notable success example.</p><p><br></p><p>The Plugin API, now offer a variety of services, form consuming blockchain data for custom needs, modifying the behavior of an Ethereum network to adapt to specific workflows, to streamlining the deprecation of legacy features by re-implementing them as plugins. They are also highly useful for testing and debugging purposes.</p><p><br></p><p>However, Besu Plugin API is fragile and grew in a non-organic way over the years. Because its evolution was mainly driven by specific needs rather than clear design principles, so it grew without a real direction, resulting in poorly organized code. Currently, every time a new functionality needs to be exposed via the Plugin API, it is not clear how to expose the interfaces or where to place them. Consequently, quick trade-offs are sometimes taken to avoid undertaking a large refactoring effort.</p><p><br></p><p>Furthermore, the plugin lifecycle—especially during the startup phase—is not well defined. This ambiguity can result in critical problems, such as plugins attempting to access a service before it is fully initialized. Finally, there is currently no real process around deprecation, versioning and backward compatibility, which makes it difficult to detect and manage braking changes in a coherent way.</p><p><br></p><h3>Learning Objectives</h3><ul><li>Gain a deep understanding of the Besu architecture, specifically its plugin ecosystem, module organization, and node lifecycle.</li><li>Learn advanced Java software design, focusing on code refactoring, API versioning and deprecation strategies, API documentation best practices, and establishing clean design principles.</li><li>Develop practical experience in open-source software development, including untangling technical debt and proposing structural architectural improvements.</li><li>Collaborate closely with plugin users and core maintainers to better understand their needs and pain points.</li></ul><h3>Expected Outcome and Deliverables</h3><ul><li>Code Reorganization &amp; Design Principles: Refactor the existing plugin codebase to improve organization and document clear guidelines/patterns on how and where to expose new interfaces in the future.</li><li>Lifecycle Refinement: Analyze and implement a robust, well-defined startup lifecycle for plugins to eliminate race conditions, ensuring services cannot be accessed before they are fully initialized.</li><li>API Versioning System: Design and integrate versioning support into the Plugin API so that maintainers and developers can systematically detect and manage breaking changes</li><li>Documentation: Renew the API documentation and Plugin writing guides.</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/82" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/82</a></p>

LFDT - Research Composable Token Primitives for Post-Trade Clearing, Settlement, Compliance on DLT

Linux Foundation

<p>Global post-trade settlement infrastructure remains fragmented across incompatible ledger implementations, jurisdictional compliance regimes, and asset-class-specific token schemas — creating systemic friction at the intersection of programmable finance and institutional market microstructure. This project conducts an open, community-driven research inquiry into the design space for a protocol-agnostic token framework within the LF Decentralized Trust ecosystem, exploring how composable token primitives may serve as a convergence layer across heterogeneous post-trade settlement rails. All research outputs, findings, and prototypes will be contributed openly to the LF Decentralized Trust community under applicable open-source licenses, with no implied endorsement or proprietary claim by any contributing organization.</p><h3>Learning Objectives</h3><p>The mentee will survey existing tokenization frameworks, identify gaps in interoperability and compliance metadata propagation, and develop exploratory prototypes to inform community discussion around open standards for post-trade infrastructure within the LF Decentralized Trust ecosystem.</p><h3>Expected Outcome and Deliverables</h3><ul><li>A Research Report documenting a comparative survey of existing tokenization frameworks, proposed schema considerations, and community recommendations for token base types, behaviors, and metadata — contributed as an open draft for community review.</li><li>An Exploratory Prototype — a series of illustrative smart contract examples (Solidity or Chaincode) demonstrating potential implementation patterns across representative use cases, intended for research and educational purposes only.</li><li>A Community Whitepaper presenting findings, open questions, and suggested directions for post-trade token framework adoption — offered as a contribution to broader community discourse with no prescriptive or regulatory guidance implied.</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/88" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/88</a></p>

LFDT - Web3j Libraries Full Lifecycle Development

Linux Foundation

<p>The Web3j library is an essential tool for Java and JVM-based developers looking to integrate with the Ethereum blockchain. It provides seamless Ethereum client communication, enabling developers to interact with smart contracts and blockchain networks. However, maintaining and improving Web3j while ensuring seamless adoption of the latest Ethereum Improvement Proposals (EIPs) remains a challenge for maintainers due to the lack of time and contributors.</p><p><br></p><p>This project aims to enhance the core Web3j by improving and continue to keep up to date its component libraries, focusing on reducing existing issues and integrating the missing EIPs. By improving the additional Web3j libraries, we aim to streamline development workflows, enhance testability, and create a more robust framework that simplifies Ethereum development for Java and JVM-based projects. The updates will address known gaps in the libraries, ensuring compatibility with the latest Ethereum standards while improving documentation, developer experience, and maintainability.</p><p><br></p><p>A similar mentorship project took place during the last mentorship program and resulted in significant code contributions, documentation and blog posts.</p><p><br></p><p>The initiative will introduce structural improvements, new features and documentation for better integration, and testing, making Web3j a more sustainable and adaptable web3 development tool project.</p><p><br></p><h3>Learning Objectives</h3><ul><li>Gain hands-on experience contributing to an open-source blockchain library, improving their understanding of Ethereum integration in JVM applications.</li><li>Develop expertise in Java and its application in blockchain smart contract development.</li><li>Enhance their skills in software libraries architecture, Ethereum blockchain and Solidity Smart Contracts development practices.</li><li>Collaborate with an open-source community, learning best practices for issue tracking, code reviews, and pull request management.</li><li>Develop expertise in complex library release process and code management.</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/60" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/60</a></p>