Skip to content

Ideal Go API boundaries for consensus engine developers #9879

@thanethomson

Description

@thanethomson

What do the ideal Go API boundaries look like (i.e. functions, interfaces, types exposed) for Tendermint to better support consensus engine developers' use cases?

Definition of Done

When we have an ADR (or set of ADRs) that outlines these APIs. Ideally this work would include some recommendations as to a plan for doing the implementation in a piecemeal way, preferably informed by the specifications.

Metadata

Metadata

Assignees

No one assigned

    Labels

    T:uxType: Issue or Pull Request related to developer experiencestalefor use by stalebot

    Type

    No type

    Projects

    Status

    Done/Merged

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions