📄️ Overview
The M10 Ledger provides an easy-to-use and expressive API for interacting with our platform. The M10 API uses gRPC for the transport mechanism, but you will mostly interact
📄️ Accounts
The M10 ledger is made out of a tree of accounts. Every account, besides the root, has a parent. The parent can be thought of in a few ways. Let's think about how most banking systems work around the world.
📄️ Actions
Transfers are great when we want to send money to an account, but what if we want to send a message? — Actions fill that gap.
📄️ Banks
"Banks" on the ledger are used by our dashboard product, the CBDC admin, to determine which accounts are associated with which bank on the ledger. The "bank" object is just metadata and doesn't impact the functionality of the core ledger. Rather, services like the CBDC admin use the bank object to discover information about existing accounts on the ledger.
📄️ Role Bindings
Role bindings bind together roles, but what does that mean? In essence, they connect a public key to a role. If you want to grant a user permissions you first need a Role with those permissions. Then you need to grant their public-key access to those permissions using a role binding.
📄️ Roles
Roles (along with their partner Role Bindings) are the two core elements of M10's permissions system. They group together a set of permissions on resources into a single object. For instance you might have a Role called bank-admin that allows a user to create or read accounts. Or you might have a role called "viewer" which allows a user to view all resources. Roles are only useful once they are "bound" to a specific key using a Role Binding.
📄️ Transfers
Transfers are the way of sending funds from one account to another. Each transfer on the M10 ledger is made up of multiple transfer steps.