Developer Access to the Libra Blockchain

Validators currently expose a gRPC endpoint for clients to access the Libra blockchain, and the Libra Core team is interested in receiving feedback from the developer community about gRPC. For example, is gRPC easy to work with? Would you prefer JSON-RPC, REST, or something completely different? What APIs would be valuable for your use case? What API endpoints have been valuable in other blockchain projects?

Please provide your feedback and let us know 1) which API protocol you would like an endpoint on nodes and 2) what use cases you are trying to support. Thank you for your input and we hope to learn more about how to serve the community!


1 ) Yes it’s ok to work with gRPC because some people start programming Framework to easily interact with Libra node :

  1. For the moment possible interactions with the node are very limited, but will be great to have API with some functionalities like :
  • getaccountstate or balance
  • mintLibra
  • transferLibra
  • createaccount

We have build a python library and a restfual API. If the libra core team is going to develop officail rest api and offical programming Framework, please anounce in advance.

This allows me to stop developing lib and rest apis and move on to upper level development.

If libra testnet support publish and execute smart contract, we don’t need to build our own dev network.


yes, IMHO, an official framework plus support docs would be probably helpful for those like me who’re relatively new in blockchain space .

  1. We like working with gRPC. The combination with proto files works. But documentation could be improved and it might be handy that proto files live in one folder. Would we prefer rest? Not really.

  2. Current available API endpoints are sufficient for our wallet use case. Maybe the limit of 1000 for transaction ranges could be increased to 5k. Its a bottleneck in our setup.


Thank you for your feedback! Why do you say you would not prefer REST?


gRPC performs and gRPC is a more modern protocol.


Frankly speaking, I’d prefer REST because it sounds a little more familiar to me. :slightly_smiling_face:
However, it might have both its pros and cons.

I’d be grateful if you guys let me know in advance because i was thinking to create rest API for the locals in Japan as a monetization API scenario.


Rest api and grpc. While grpc is more “efficient”, rest APIs are easier to visualize and consume. Also agree on allowing an upper limit of above 1k for developers access.


What are your use cases for bulk querying? Curious to see if this is a big use case.

1 Like

I believe you have probably compared these already when deciding on gRPC. Of course rest would be the most simple for anyone to start using and could be easilly integrated to various platforms but gRPC has features that make it better in this case.

For example streaming. Libra could provide a streaming api which I could use to listen to events on an account and I would not need to poll the api, also from client side I could open a stream for making payments instead of creating a new request for each transaction.

Also, I believe gRPC is more efficient on resources. Libra is already optimizing the request and response payloads by cutting away of bytes here and there, you could not do that with a verbose rest api.

To sum up, the current api does not utilize all the potential it has, when it does, gRPC will be a better choice than the others mentioned.


for a blockexplorer :slight_smile:


Indeef. Blockexplorer and everything related. Including wallets :slight_smile:


A primary use case I can think of is only a micropayment system like alipay in China which consumers can use libra to pay at merchants.

I just want to know of opinion from others, too . :thinking: :face_with_hand_over_mouth:


Ah, please don’t choose the easy road now, you started already fine, switching to REST would be surrendering to the easy path.
gRPC was a very valid choice for this use case, JSON-RPC would also be fine as eg. Ethereum chose, but gRPC is even better in terms of support and wide-spread usage. REST would be the wrong choice for sure. Yes, it’s so easy to use and there are so much tools and Swagger and Postman and client generating frameworks - all true, but

RESTful Web services allow the requesting systems to access and manipulate textual representations of Web resources by using a uniform and predefined set of stateless operations.

there are no resources here. Yes, it’s easy to redefine everything to a resource and many did, but for what happens in those clients, to me it’s RPC. And if it’s RPC, it shouldn’t be RESTified just for the sake of ease of access, please stay with gRPC!


Coming from the Ethereum community and progressing with the API endpoints that web3.js has been providing - I’d say the most important thing to be provided is a “transaction status” promise that returns “pending” , “error: message” , or “success: tx hash” - as this has major UX implications for projects built on top.

The second thing is to keep as low level functions open in the tx lifecycle so that developers have the flexibility to develop applications that pay for user transaction fees - this is VERY important.

REST should be developed - it’s the easiest to develop around for all developers and not just core developers. A block explorer would also be very helpful and, lastly, and ode editor UI (GUI) for smart contract deployment (like Mist for example).

  1. Considering the most common issue of creating a mass critical developer community I would implement a JSON-RPC because it’s widely used in the crypto space (this is to increase adoption not considering technical aspects). However, I don’t see any impediment using gRPC really.
  2. In our case we are building a voting platfom.
  3. We do need more RPC methods available like sendRawTransaction() to interact with our smart contracts.
  1. Add REST API - This is why
    I think that if we want to drive adoption and expand the audience of Libra beyond Core developers working with Blockchain or Cryptocurrencies, then Libra should also provide a REST API.
    REST API not only have a healthy and big community of Developers, iPaaS, vendors, OpenAPI supporter, but also a solid understanding from Business involved in API Economy, API ecosystems and Digital Transformation.

  2. Use Case
    I’m Integration Architect working with Mulesoft solution. Currently, developing (actually evaluating it) a custom Libra connector for Mule that would make possible integration with other REST API based services. The Libra connector basically would abstract away the gRPC for Mule Apps.


Agree with folks about staying with gRPC over implementing a new REST API, you could always expose the GRPC gateway and annotate the gRPC services, but, have you considered adding a GraphQL API?

As one area that gRPC does not do so well is the interactive exploring of an API, there are a few tools out there, but I feel that in addition to GraphQL being a fantastic production API for some use cases, it would be a great development / exploration API using GraphiQL


The downside of gRPC is that it doesn’t work on browser directly, it always need a bridge to make it work, thus making it more centralized. I wish validators have this bridge by default running so it’s not handled by another centralized service. Also it would be great if you guys keep a GitHub repo updated with only the .proto files, it would make easier for dev building clients to keep their client updated.