Try   HackMD

Note

The following document is a proposal for the Amaru project. It is a collective document that describes the vision and the needs of multiple entities/actors involved in the development of Amaru.

It is meant as a starting point for discussing Cardano treasury withdrawals in alignment with the incoming constitution.

As such, we invite anyone interested to comment on the following document, and share feedback with us.

Vision

Amaru is an open-source project that aims to build a new fully interoperable block-producing node for improving the overall accessiblity and robustness of the Cardano network without compromising on its satefy and security. Amaru provides another perspective and solution for stake pool operators and developers alike, focusing on modularity and easy-of-use. The project is implemented mainly in Rust and aims to attract new contributors to the core maintenance of the ecosystem.

This proposal is designed to breakdown the objectives, scopes, timelines and costs pertaining to Amaru. It delivers the full vision behind the project and open the discussion regarding a Cardano treasury withdrawal to sustain its development.

Executive summary

Given the length of our proposal, we first provide a high-level overview of the project. The second part of the document goes into more details about the specifics of the Amaru project.

Disclaimer: proposal assumptions and bias

We consider that the current ask is a significant amount of money for a project proposal. We are also well-aware of the challenge (and therefore risks) that the project represents. However:

  • we don't start from scratch: the Haskell node is an excellent basis which has already solved numerous challenges. It also provides a solid baseline for performance and reliability.
  • we have gathered our best people around the project: we are all actively contributing to the Cardano ecosystem for many years and are recognized leaders in our respective fields.
  • lean environment: Amaru isn't our only project, so we need ways of working that are efficient and lightweight.
  • we are builders: we deliver in small steps, showcased in demos. Our main goal is to ship a working software.
  • we breathe open-source: we seek constructive feedback and actively engage with contributors who are willing to help us in our endeavour.

In addition, the sizing of this proposal stems from a few assumptions:

  • There's already ongoing work for most of the scopes, but rarely as a primary priority for people involved. The estimation presented in this proposal assumes a dedicated team;
  • This proposal spans over a year, throughout which there will be several deliveries of Amaru. We aim to deliver a capable block-producing node by end of 2025, with several useful increments in-between.
  • Given the timeline of the governance actions that are linked to this proposal, everything that is mentionned in this document is an estimate of 12 months of work that starts from June 2025 (our realistic timeline to get the treasury withdrawal active); The milestones described in Q1 and Q2 2025 are not taken into account in the FTE asked by each scope.
  • All the scopes described here are estimated in FTE (Full Time Employee) for the sake of evaluating the cost of our project we took the assumption that one senior Software Engineer with expertise in Rust and DLT (Distributed Ledger Technology) is valued at $200k (remote profile working from the US, recruitment, onboarding and extra costs related to working – i.e paid vacations, sick leave – are considered included in the $200k figure)
  • We will secure the treasury withdrawal with stablecoins whenever possible to keep the value until final payment to contributors is done (main assumption: withdraw everything but the Contingency in stablecoins)
  • Optimism bias: we are aware that while ongoing the forecast and constructing our proposal we are subject to underestimating complexity, overlooking challenges and undervaluing time and cost required to deliver: we will add a 25% contingency fund

Comparison to similar projects

RETH

Project RETH
Description A high-performance, modular, and open-source Ethereum execution layer client developed in Rust to enhance speed, efficiency, and client diversity for the Ethereum network
Timeline 2 years of development before mainnet
Dedicated team 8 core developers; 90 contributors
Roughly estimated overall cost >3M$

Firedancer

Project Firedancer
Description A high-performance, C++-based validator client for Solana, to enhance scalability, decentralization, and network efficiency by optimizing transaction throughput and reducing system bottlenecks
Timeline 2 years of development (still ongoing) mainnet targetted for 2025
Dedicated team no public figures available
Roughly estimated overall costs >5M$

Cardano-node

Project Cardano-node
Description The core implementation of Cardano's blockchain, written in Haskell, enabling decentralized transaction processing, consensus mechanisms, and smart contract execution within the Cardano ecosystem
Timeline Started with the Byron release on 2017, still ongoing
Dedicated team no public figures available
Rougly estimated overall costs >20M$

Tip

As our project is closer to RETH in its setup and environment this will be our target when coming down to the final estimate comparison.

Estimates and contributions

Overall sizing

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

You will find here the result of the estimation:

Scope Resource estimated
Ledger 2.5 FTEs
Consensus 2.5 FTEs
Ad-hoc mercenaries 2 FTEs
Testnet 0.5 FTE + $60k (infrastructure costs)
Mempool 0.5 FTEs
UTxO RPC 0.5 FTEs
Network (P2P) 0 FTEs

Total estimated for our assumption of 2025 delivery: 8.5 FTEs and 60k$ worth of infrastructure costs.

Already secured resources

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Here are the already funded that have resources allocated or a funding secured:

Scope Resources already secured
Ledger 1 FTEs
Consensus 1 FTEs
Ad-hoc Mercenaries 0 FTE
UTxO RPC 0 FTE
Network (P2P) 0 FTE
Mempool 0 FTE
Testnet 0 FTE

Total of the resources already available or funded: 2 FTEs from people that are employees of the Cardano Foundation.

Tip

The bounded context owners will also dedicate time managing their activity on the project but this has not been reflected in the above FTE evaluation.

Final ask

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Here are the treasury ask for each scope:

Scope Resource estimated Resources already secured Resources asked
Ledger 2.5 FTEs 1 FTEs 1.5 FTEs
Consensus 2.5 FTEs 1 FTEs 1.5 FTE
Ad-hoc Mercenaries 2 FTEs 0 FTE 2 FTEs
Testnet 0.5 FTE + $60k (infrastructure costs) 0 FTE 0.5 FTE + $60k
Mempool 0.5 FTEs 0 FTE 0.5 FTE
UTxO RPC 0.5 FTEs 0 FTE 0.5 FTE
Network (P2P) 0 FTEs 0 FTEs 0 FTE

Total of the asked for our proposal: 6.5 FTEs + $60k.

Given our assumptions the valuation of this proposal based on a $200k comes down to: 6.5 * $200k + $60k = $1360k

Given our assumption regarding our optimism bias (add 25% of contingency), here are the final figure for each scope:

Scope Resources asked
Ledger $300k
Consensus $300k
Ad-hoc Mercenaries $400k
Testnet $210k
UTxO RPC $150k
Mempool $150k
Network (P2P) $0
Contingency $340k (FTE: $325k + Infrastructure: $15k)
TOTAL $1700k

The proposal submitted will be targetting: $1.7M as a result of the scopes covered in Amaru.

Below in this document you will find details on:

  • The framework, methodology used
  • The result of the first Design phase and the scope split
  • The principles shared on managing Amaru
  • Deep dives on scopes, timelines, estimations
  • Already delivered scope overview

Sizing and managing the project

Amaru development framework: turning vision into achievable goals

Our main challenge as a team was to put into perspective what it means to build a Cardano node and dissecting this meaning into building components that are bringing the modular aspect of our product to life.

We looked into many methodologies and frameworks, and none of them really fit with both the vision and the environment of the project.

What we designed is a customised framework that has 2 majors phases:

  1. Design: Formalising the main problems we are solving and building the architecture of the product and allocating the scopes behind the vision of Amaru (modularity, performance)
  2. Drive and Deliver: A basic development cycle that is driven by demos and interfaces between each part of the architecture

4

This representation encapsulates all the phases imagined for designing and running the Amaru project:

  1. Problem framing : DDD : Framing the problem linking together Problem, People, Outcome and Constraints
  2. Solution architecture : C4 Architecture representing the system and the interfaces between each key components
  3. Solution flows and structure : DDD : Bounded context focusing on use cases and structuring the delivery blocks of the solution
  4. Manage release plans & interfaces : Extreme programming build a cycle with a release plan directed towards delivering a demo
  5. Demonstrate : Extreme programming deliver on the features with acceptance criteria and KPIs to measure
  6. Reflect and learn : Lean Startup : Validated learning allocate time to confront the solution to the problem environment and its user
  7. Final solution delivery : Lean Startup : Build, Measure, Learn document the main delivery and discoveries related to the problems, prepare the next maintaining cycle

Currently (December 2024) Step 3 is completed and each project scopes and interfaces are mapped out. Each scope owner manages its demo driven release plan aligned with the project's objectives.

Design phase results: Architecture of the product

Our objective during that phase was to create clear and compelling problem statements that establishes a starting point to quickly understand:

  • Who is impacted by our project,
  • The desired outcomes that define success for our project
  • The constraints that will need to be taken into account

While starting out the discussion one topic was clear, we need diversity in the people contributing right from the start. The initial team that contributed to this design phase came from 6 companies: Blink Labs, Cardano Foundation, dcSparks, IOHK, Sundae Labs, TxPipe. The positions included were also of a varied range: CEO, COO, CTO, Senior developer, Project manager, SPO.

If you want to better understand the extent of the project and see what we went through you can have a look into the results of the design phase here: Amaru documentation: Design phase results It includes an overview of the problems statements that were identified, the people that we chose as stakeholders and the overall architecture setup we drafted. Keep in mind this is the current results, it may be subject to change depending on the direction we want to take and the use case we will be facing.

For this proposal we will take into account the results and focus on the execution of the project.

Turning product design into actionable scopes and teams

Now that we have a better understanding of the problems we want to solve, the global architecture of our product and have identified the scopes that each team will deliver, let's look into how we will organize the project to achieve everything we want to do.

Bounded context ownership

Our definition of a bounded context in our project is: "An autonomous scope included in the overall architecture of the product. The bounded context owner who has the responsibility of driving the activity and aligning with stakeholders the deliveries and managing interfaces."

Each bounded context owner has the responsibility of managing everything in order to deliver an integrated scope for the project. They also have ownership of decision making for everything related to their allocated budget. (that will be described later on in that document)

Having those scope owners will enable asynchronous development while being driven by the projects common targets: demos.

We currently establish the following bounded contexts, and their respective owners:

5

Anything that comes out of the scope of each owner will be discussed with the maintainer committee who has a role of sanity check for Amaru:

  • Aligning the demo content with the expected features
  • Reviewing the content of the integrated scope
  • Measuring the product overall performance and keeping up with expected targets

Governance

The decision making on the Amaru project function with a simple rule: "if you can decide, do it"

The project is structured in a way that allows each bounded context to have freedom in its decision making within the boundaries of its scope. The only topics where decisions have to be addressed with the maintainers committee are:

  • Interoperability
  • Interfaces with other scopes
  • Integration with the global product

Today this alignment is a recurring Maintainer Committee meeting every two weeks. Its purpose is to align the key decisions to be made regarding architecture and alignment of all the ongoing streams of activity.

The way we reach a decision by default is by lazy consensus meaning that once something is discussed, explained and an agreement is reached during the meeting mentioned above: it is accepted as a decision if no objections are made. For any objections regarding decision making the final approval will have to be settled with our main architect: Matthias Benkort.

Each scope owner will have total responsibility of its allocated budget withdrawal based on his FTE estimate. This will be executed with a multi signature contract on chain. Everything that goes out of the boundaries of the allocated budget will have to be decided by the maintainer committee.

Managing the finance of the project with on-chain decision making

In order to be fully transparent on how we plan to manage decision making and finance on the project here is what we will put in place on day 1 when we make the info action related to this proposal.

2025_02_11_Amaru_finance

Based on this proposal deep dives, each scope owner will have access to a Threshold that he can withdraw money from, each scope has only 1 owner and only 1 threshold (valued in $)

We want the decision making to be very simple and straightforward: every scope owner must be in agreement when the withdrawal is made

We want to have all the information of the transaction at the same place so that it's easier to understand why the decision has been made and what's the extent of it. We will include in all vote an intent and a document that states the commitment of the owner to a specific delivery that goes in line with the roadmap of the whole project.

As mentioned the process should be straight forward and everything has to be available on-chain:

vote

The current features related to the finance management on the project are:

  • Withdraw money: scope owner asks other scope owners for an amount of money to be withdrawn from his scope
  • Contingency withdraw: scope owner asks other scope owners for an amount to be withdrawn from the contingency funds
  • Change of ownership: scope owner asks other scope owners for a change of ownership of a scope (or a reallocation of threshold)
  • Contingency back to the Cardano Treasury: scope owner asks that the contingency be sent back to the Cardano Treasury

Tip

12 months after the treasury withdrawal what's left within the contingency account will be automatically transferred back to the Cardano Treasury.
We believe that if we need the contingency to carry over then we need another proposal to be discussed linked with deliveries.

We will track the status of the budget status of each scope and of the overall project on a monthly basis.

Safeguards

We want to make the system to manage the finance of the project to be using a full consensus for decision making, that implies that a few safeguards must be put in place to make the system resilient.

First safeguard: what happens in case of someone losing access or adversarial behaviour from one of the scope owners. This will be managed by a simple mechanism that triggers after 3 consecutives "no" votes from one of the party. If these 3 votes happen then the other bounded context owners will have the possibility to diminish the decision making threshold for voting to 50% instead of 100% to reach a decision.

Second safeguard: securing the deliveries on the projects linked to the money withdrawal. We want to have a very straightforward method when it comes to managing milestones and deliveries: use Github Pull Requests to formalise the final delivery. The acceptance process of the deliveries will be using our day to day regimen:

  • Make sure the codebase proposed is integrated on the right branch of the Amaru repository
  • Include testing results from the modified environment
  • Validate with the core maintainers and have them sign off the Pull request
  • Push the pull request to the active codebase

This means that the withdrawal will be done with a basic rule on our project: 30% of the sum required will be withdrawn directly and the rest will be allocated to the forecast of milestones where the code is pushed to the repository.

Third safeguard: not delivering upon the requested targets. If the maintainers of the project deem the work not up to what the project needs 3 times in a row then the money initially asked in the withdrawal will be sent back for the scope owner to manage. This will be done using the maintainer committee or during specific deliverable reviews.

Fourth safeguard: delivering the money to the contractors/people executing the activities. The people in charge of delivering the activity for Amaru will have to specify a wallet address in order to receive the money from the withdrawal. The wallet information will be kept private and only the transaction will be visible to the public.

Ongoing activity

What's left to be clarified (before the official info action) is the way we make the on-chain activities related to the withdrawal of funds. So far our assumption is to use a multi sig scheme with off chain commitments, but stay tuned something else might come up!

PRAGMA policies applied to Amaru: quarterly review

PRAGMA is a member-based, not-for-profit open-source association for blockchain software projects created by 5 companies: Blink labs, Cardano Foundation, dcSparks, Sundae Labs, Txpipe.

PRAGMA is composed of two entities: the General assembly and the Administrative board.

The General assembly is composed of a representative of each founding member and decides the strategy and the composition of PRAGMA.

The Administrative board is elected by the General assembly, manages the operational side of PRAGMA and oversees each of the project.

6

PRAGMA's Administrative board has the responsibility of aligning with each of the projects that are part of PRAGMA the composition of the maintainers and reviews every quarter the progress of each project.

The content of these reports are straightforward and include:

  • Problems that require board attention (infrastructure, trademarks, etc.)
  • Project status (active, inactive, initiating, etc.)
  • Community changes (last committer addition)
  • Next planned steps (new releases, significant changes, etc.)
  • Reflection & Performance

This recurrent interaction will provide an overview of the project with a long term perspective and support the maintainers committee on aligning priorities and drawing out next steps.

The outcome of these reviews will be publicly available as documentation in the Amaru Github repository.

Demo driven approach

Everything that happens when planning and discussing future implementation has to be demo driven by our product: Amaru. We want to have an approach to always put into perspective the outcome of what we are trying to do. Every goals and milestones that we want to deliver has to be linked to something that can be run in an integrated demo.

As a result of this mindset, each bounded context owner has to integrate the deliveries of his scope into a demo for Amaru and align with the maintainer committee timing, content and the extent of the features required.

The achieved demos for Amaru so far are:

The demos that are currently forecasted are:

Delivering Amaru: deep dives

This section of the proposal will cover everything that has been planned so far related to the vision and objectives we set for our project.

Each scope will be described with the following pattern:

  • Scope to be covered and associated timeline
  • Estimated resources required: number of FTE (Full time employee), Infrastructure costs, Licenses and additionnal costs
  • Resources and funding already secured contribution to the scope
  • Additional effort required to be added to the proposal

The following summarizes the list of bounded contexts that will be detailed in the document.

Note that since Dolos and the GO Node are not directly implemented in Amaru we will only manage the interfaces through the ledger and the networking stacks (P2P).

Assumption for this deep dive:

  • The below scopes describe every resources needed for a year as we expect to be done with delivering most of the scopes by the end of 2025
  • In each scope two additional activities are to be integrated : integration and research we will illustrate the extent of this at the end of our deep dive
  • Our estimates are optimistic by nature and we try to limit ourselves to the "just necessary" workload in order to be as lean as we can, we will use a comparison after the deep dive to reflect upon our estimates and adjust the overall picture with contingencies

Cardano ledger

Scope and timeline

Scope

The scope of this bounded context is to implement and maintain a ledger compatible with Cardano. This includes:

  • Phase 1: Prototype/exploration/proof of concept -private testnet
  • Phase 2: Tracking of ledger state (restricted to anything but transaction validation and governance) -private testnet; trusted peers
  • Phase 3: Complete ledger rules implementation -private testnet; preview; trustless
  • Phase 4: Performance optimisation of tracking ledger state and full validation -private testnet; mainnet ready; trustless

Timeline

Estimated resources required

Rust developers: 2.5 FTE

Resources and funding already secured

Rust developers: 1 FTE (Matthias 0.5) (Matthieu 0.5)

Additional effort required

Rust developers: 1.5 FTE

Ouroboros Consensus

Scope and timeline

Scope

The scope of this bounded context is to implement and maintain software implementing the Ouroboros family of blockchain consensus protocols. This includes Ouroboros Praos, the ongoing incarnation, and all future extensions like Genesis, Peras, Leios… The core requirements of the consensus are:

  1. correctness: Whatever version of the protocol is current, a node using it can participate fully in the Cardano network, as a client, relay, or block forging node,
  2. security: Consensus software provides evidences it is safe and secure in accordance with the theoretical properties expected from current version of the protocol and situation of the network,
  3. observability (o11y): Consensus software affords all information needed for node operators and developers to fully understand how it operates, both at build and run time
  4. maintainability: Consensus code strives to be easy to understand, analyze, and extand now and in the future
  5. performance: consensus should require limited resources and run on commodity hardware

Timeline

We give a rough (with a 3 months granualarity) timeline of the main deliverables for the Amaru project below. Note that dependencies are only needed to demonstrate the deliverable runs on a full Cardano network.

  1. Explore (EOY 2024)
    • Build a model of Praos (w/ Genesis?) that exhibits expected properties
    • Define interfaces and relationships with other bounded contexts (networking, mempool, ledger)
  2. Testing (Q1-Q2 2025)
    • Build a conformance testing tool and related suite of tests based on consensus specification and existing implementation
    • Be able to run conformance testing suite against any implementation of Ouroboros, including existing ouroboros-consensus and future implementation for Amaru
  3. Chain validation (Q2-Q3 2025)
    • Build a version of consensus that can follow the chain and validate blocks (include headers and transactions validation)
    • Demonstrate conformance of validating node against existing node and network
    • Dependencies: ledger state access and transactions validations, networking n2n protocols
  4. Block production (Q3-Q4 2025)
    • A version of consensus that can forge blocks with transactions from the mempool according to the predefined VRF-based schedule
    • Conformance suite validing block production schedule and transaction selection logic w.r.t existing node
    • Dependencies: ledger, network + mempool

Estimated resources required

Rust developer: 2.5 FTEs

Resources and funding already secured

Rust developers: 1 FTE (Arnaud 0.5) (Pawel 0.5)

Additional effort required

Rust developers: 1.5 FTE

Testnet facilitator

Scope and timeline

Scope

The scope of this bounded context is to create a testing environment for Amaru and maintain the infrastructure required to run it. This includes:

  • Setting up the testnet environment (Hardware, services, support)
  • Running operations (stake distrubtion and health of the testnet has to be actively monitored)
  • Tooling, API, operator interface development
  • Maintaining continuous integration and continuous delivery/continuous deployment
  • Periodic testing (integration/benchmarking)
  • Automated testing

Thresholds targets to test the performance of Amaru:

  • Number of nodes involved in the network: 10
  • Geographic distribution (6 locations, 1 from each continent)
  • Setup: run with a single type of node (Haskel); run with multiple bloc producing node (Haskel & Amaru)

Timeline

  • Closed testnet: Q1 2025
  • Testing to transition to preview: Q2 2025
  • Public VS private testnet analysis and transition setup: Q3 2025
  • Tuning down the private testnet and transition to preview/preprod: Q4 2025

Estimated resources required

Rust developer/infrastructure operator : 0.5 FTE Infrastructure cost for a year with 10 nodes running: 60k$ Based on the estimate of running a Cardano node (permanent hardware, network, storage): 500$/node/month

Resources and funding already secured

None

Additional effort required

Rust developer/infrastructure operator : 0.5 FTE
Infrastructure cost: 60k$

Mempool

Scope and timeline

Scope

The scope of this bounded context is to implement and maintain a mempool compatible with Cardano. This includes:

  • Mempool library: Build a standalone library (data structure that represents transactions in memory) with an interface to get an extract of these transactions
  • "Simple" mempool implementation: Build a basic mempool that adds, remove, gather, drain transactions and exposes a new ledger state
  • "Complex" mempool implementation: Build a more refined version of the mempool that handles features differently and optimises the overall resources consumption
  • Mempool tooling and API: Create a tool able to manage the mempool and the modularity
  • Node management Remote Procedure Call (RPC): Build a software that handles the "operator perspective" on operating the Amaru node
  • Block forging: Develop a component able to forge blocs

Timeline

Estimated resources required

Rust developers: 0.5 FTE

Resources and funding already secured

0 FTE

Additional effort required

0.5 FTE

UTxO RPC integration and specification

Scope and timeline

Scope

The scope of this bounded context is to implement and maintain a UTXO RPC service compatible with Cardano. This includes:

  • UTxO RPC specification sanity check and update: Review and update the UTxO spec based on the targetted features
  • UTxO RPC container implementation: Build a standalone component that has the expected features integrated with Amaru
  • Sundae Sync implementation: Integrate the Amaru component with Sundae Sync

Timeline

  • UTxO RPC specification sanity check and update: Q1 2025
  • UTxO RPC container implementation: Q2 2025
  • Sundae Sync implementation: Q2 2025

Estimated resources required

Rust developers: 0.5 FTE

Resources and funding already secured

0 FTE but work already done: Sundae Labs: Amaru Node Development Support

Additional effort required

Rust developers: 0.5 FTE

Networking (Peer to Peer)

This scope is covered by a Catalyst proposal that is a lot more detailed than the content of this document, you can check it here: Amaru: P2P networking component by TxPipe

Scope and timeline

Scope

The scope of this bounded context is to implement and maintain a peer to peer networking layer compatible with Cardano. This includes:

  • Peer discovery: A mechanism to establish which peers are participating in the network without relying on a static topology.
  • Outbound routing: A component that manages the outbound traffic to peers using different heuristics with the goal of optimizing overall network efficiency.
  • Inbound routing: A component that is in charge of monitoring inbound connections with the goal of optimizing efficiency and to mitigate abuses / attacks.
  • Simulation testing environment for performance checks

Timeline

  • Peer discovery: Q1 2024
  • Outbound routing: Q2 2024
  • Inbound routing: Q2 2024

Estimated resources required

Rust developers: 0 FTE

Resources and funding already secured

Rust developers: 0 FTE but work already done: Amaru: P2P networking component by TxPipe

Additional effort required

Rust developers: 0 FTE

Unbounded activities

This section describes the expected rigorous development expectations that comes with delivering software on the project and the activities that aren't specific to a bounded context.

Amaru product integration

Each bounded context has to deliver an implementable version of his scope for Amaru. This means that the following has been achieve:

  • Refactoring: the structure of the developed code has been optimized to fit with the current structure of the Amaru code base
  • Benchmarking: the targets set for the features has been compared to the standards and is up to par with what's available
  • Testing: once implemented in the Amaru context, reports are available to show that the expected features are working within the targeted environment.
  • Performance: expected performance is tracked and aligned with the Amaru maintainers

Expectations regarding each bounded context are:

  • Vision & direction alignment: the deliveries are linked to demos forecast and aligned during maintainer committees
  • Quality assurance: each implementation comes with a clear methodology and respects the standards set for Amaru
  • Troubleshooting: the scope owner has a responsibility of resolving issues and bugs when pinned down to a specific scope

The main responsibilities of managing a bounded context comes with aligning forecasts between multiple teams, securing commitments from contributors all while taking into account risks and managing contingencies that can help delivering. This will also be a significant workload for each scope owners and the maintainers committee of the project.

Cardano research, specifications

Delivering an implemented software comes naturally to senior developers, although we want our project to be up to par with the state of the art regarding the Cardano ecosystem.

Expectations regarding each bounded context are:

  • Specifications referencing: each implemented component will have to reference the specifications that cover their scope
  • Specifications cross check: the features and the performance of the integrated version of the component has to be validated by a threshold or a target included in a specification. If the said specification does not align with the outcome of the performance, either the specification has to be updated or the implementation has to be corrected.
  • Specifications updates: any feature implementation or release that impacts a performance boundary that isn't contained in a specification has to be traced and explained to update the documentation or create documentation if none exist
  • Research alignment: if the implemented scope challenges the state of Whitepapers or research documents that are existing it has to be addressed with the people involved in the research category

Product and Project Management

The current set of activities that are in that spectrum are:

  • Creating and managing SPO working groups to actively improve the operator side of Amaru
  • Roadmaps interfaces and scopes alignment synchronization
  • Organizing and facilitating workshops related to key explorations of the product
  • Marketing, implementation partnerships alignment, use case specific collaborations
  • Budget and finance management of the project

Each bounded context will share ownership over a product/project manager that will interface himself with all the stakeholders of the Amaru project to facilitate the management activities and harmonize the ways of working around the bounded context.

Use case specific workload, troubleshooting, bug fixes

Part of our journey will involve making our node modular and welcome many different use cases. We intent that each scope owner has a responsibility towards making evolutions towards fulfilling these use cases.

We are aware that bringing more implementations and various use cases will come with a higher number of bugs and troubleshooting tasks towards making sure Amaru runs smoothly with a high performance.

Resulting workload: Ad-hoc Mercenaries

Given the mentionned above activities and a set of uncertainty regarding the overall scope of the project after Q4 2025 the owners decided to allocate 2 FTE to a bounded context called "Ad-hoc Mercenaries".

The purpose of that team is to be a lean surgical team that can help any bounded context in delivering actionnable results. They will function as a straighforward "help us deliver this" and can be sollicitated by any bounded context owner.

For the time being, the owner of that bounded context will be Pi Lanningham.

Conclusion

The proposal submitted will be targeting: $1.7M as a result of the scopes covered in Amaru, as summarized in Estimates and contributions.

The Amaru project represents an opportunity to bring node diversity through the development of a modular, high-performance, and interoperable block-producing node for enhancing the Cardano ecosystem. Our approach, rooted in openness, innovation, and operational resilience, aims to deliver significant advancements in blockchain technology without compromising security or operator experience.

Through rigorous design and execution phases, we have outlined actionable scopes, realistic timelines, and comprehensive resource allocations to achieve our ambitious goals by the end of 2025. The detailed breakdown of scopes, funding and resources already secured reflects our commitment to transparency and efficiency. While we remain optimistic about our forecasts, we acknowledge the complexities involved and have incorporated contingencies to address unforeseen challenges.

The requested treasury funding of $1.7M will empower us to build on the foundational work started, enabling us to transition from vision to reality. We firmly believe that the exceptional talent and dedication of our team, combined with the robust framework, will ensure the project's success.

This proposal is more than just a funding request; it is an invitation to collaborate and innovate together. The Amaru project is ambitious, but it is also achievable with the collective effort of our contributors and the broader Cardano community. By focusing on building, learning, and demonstrating tangible progress, we are confident that Amaru will pave the way for a more resilient and decentralized Cardano ecosystem, ensuring long-term reliability and innovation.

Let’s build the future of Cardano together.

Last changed by 
 
PRAGMA-org
A member-based, not-for-profit open-source association for blockchain software projects.
10
1
1868
Published on HackMD