Proposal: Web3API Terra SDK and Community Pool Funding


Web3API makes it easy to interact with any protocol or blockchain, from any programming language. It aims to make integrating Web3 protocols into applications seamless, without sacrificing decentralization. The Web3API DAO recently announced a grant with Uniswap, and have a soon to be announced grant with another top 10 market-cap blockchain in order to make the experience integrating their protocols into decentralized applications 10x better.

We’re huge fans of the Terra ecosystem and want to drive its further adoption. We propose to partner with Terra to implement its Web3API for the Terra developer community with the goal of releasing Terra’s SDK on Web3API in Q3-Q4 2021.

Technical details

Terra’s development experience would be improved in the following ways:

  • Streamlined Integration - Query any Web3API on-the-fly, by simply providing its URI (example: api.terra).
  • Simple Interface - With GraphQL, Web3APIs are as easy to use as Web2 web services.
  • Multi-Platform - Use Terra’s Web3API in any programming language through a Web3API Client implementation. Instead of needing to maintain both the Python and Javascript SDKs (as well as future language support), Terra could just maintain its SDK through Web3API and have it accessible on any language.
  • Automatic Updates - Resolving packages at runtime allows for automatic (opt-in) updates.
  • Limitless Composability - Since Web3APIs are not bundled into applications, there are no scaling limits to composability.
  • Extendable Protocols - Web3APIs can query each other and define standard interfaces, enabling fully extendable protocols.

Project Details

First, let’s walk through how Web3API accomplishes what it’s claiming to do above.

For the visual learners, here is a video explanation: (

Web3API is a WebAssembly (WASM) standard and a developer toolchain that streamlines Web3 protocol integrations. All logic that was once bundled into JavaScript SDKs (among other languages) is now within lightweight, secure, and portable WASM modules called Web3APIs.

Querying these Web3APIs is done through a familiar GraphQL ( interface resulting in a developer experience almost identical to that of a Web2 web service. Instead of sending GraphQL queries to a centralized endpoint, such as, apps query a decentralized endpoint like api.protocol.eth.

The Web3API Client resolves the Web3API package hosted at its decentralized endpoint, downloads it at runtime (if not present), and executes the application’s queries on the WASM modules.

See this Architecture section( for a deep dive.

Ecosystem Fit: Why Terra x Web3API is a great partnership

We think Terra x Web3API could be a great partnership in both technology and ecosystem ideologies:

  • Instead of authoring language specific SDKs for application developers to use, authoring a single Web3API can serve as a solution for all developers, regardless of what language they’re building in.

    The goal is for this Web3API to supersede the existing Terra Python and Javascript SDKs that exist today for developers. In the future when there are more Web3API Client implementations in other languages, this Web3API will be usable there as well.

  • We could be the de-facto SDK platform for current and future projects built on Terra, if the community likes the initial SDK. For instance, Web3API could work with Anchor to make their goal of integrating into applications with less than 7 lines of code a reality.

  • Terra is bringing blockchain to the real world. Real world use cases necessitate speed, security, and interoperability - which Web3API provides. Consider for instance a video game that pulls files from IPFS, mints NFTs on Ethereum, and makes payments on Terra. Web3API makes it significantly easier to develop this type of game.

  • A Terra Web3API that’s easy to use would further increase accessibility for developers to build on Terra and overall adoption.

  • Web3API will have eventual value capture mechanisms (ie similar to Docker or RapidAPI in the Web2 world), for which UST could be the default currency.

  • Terra smart contracts are already built in COSMWASM, so we imagine the ecosystem understand the utility of developing with WASM broadly. Web3API also sees WASM as the future for enabling hyper-composability on decentralized applications, over the current standard of clunky JS wrappers.

Plan and funding

It would be great to work closely with the Terra team in Q3/Q4 to build out Terra’s Web3API. We would work closely with Terra engineers and research team to design, build, and test Web3API’s Terra integrations.

Total estimate expenses

Cost: $25,000

Effort: 25-30 hrs/week x 12 weeks

Scope: Port the entire existing Terra Javascript/Python SDK into a fully functional Web3API

Broadly, we’re also interested in:

  • Terra helping promote the Web3API standard, encouraging developers building multichain decentralized applications to use Web3API to access the Terra blockchain.
  • Working with projects on Terra in the future to build their Web3APIs :slightly_smiling_face: (Mirror, Anchor, etc)
  • Value capture with UST when Web3API goes live

Call to action:

Thank you for reading! I’d be grateful to receive feedback.

What do people think? Does this tackle a problem that Terra developers have with composability, integrations, needing to maintain multiple SDKs? We’d love to hear specifically from the Terra engineering team and developers who have built/tried to build on Terra. We’re also curious what how we fit in with the larger development roadmap for Terra as a whole.

If anyone wants to help on any of the above or is generally have any questions, don’t hesitate to DM me :slight_smile:


Looks great! Is there possibly a version in production we can try to play around with? TFL devs are digging through the architecture docs now and will comment here.


We actually just release our first set of onboarding documentation. This can be found here:

NOTE: the tool-chain and documentation are in pre-alpha

As for demos, we have 2 live at the moment.

The first is a “simple storage” example on Ethereum, a walk-through of this demo can be found here.

The second demo is a “hello world” Web3API which simply logs input to the browser’s console, this can be found here.

All of our demo Web3APIs and accompanying interfaces can be found here on GitHub.

Please don’t hesitate to reach out if you or the development team has any questions!

1 Like

Hey – I received a demo from the Web3API guys not too long ago, but wasn’t too sure about how this would be applicable to Terra since the docs just provide examples for Web3/ETH; do you think you could provide a Terra-specific example?

Hey William, Web3API is a completely agnostic tool-chain. It should be thought of as a replacement for language specific SDKs (JavaScript, etc).

The demos we have currently are focused around Ethereum as this is the first use-case we’re enabling, by creating an Ethereum Web3API.

For Terra, a Web3API could be made for it, the same way you’d create a Terra SDK in JavaScript for example. The benefits for doing this can be found here:


Awesome! Not to dis Java and Python, but options for preffered programming languages for programmers not to mention the variety of use cases/methods/purposes languages each bring to the table, yummy.


Echoing Jordan’s message; other examples for how this is useful for the Terra ecosystem are provided in the original post.

Also it seems there may be confusion around the difference between Web3 and Ethereum. Web3 refers more broadly to applications (such as Anchor, Mirror) that which are decentralized, run on any blockchain (not just Ethereum), transparent/fair, give users control over their own data, etc. As an example, web2 is Robinhood (the internet platforms you know today which are centralized, rent seeking, breakable, not transparent), web3 is Mirror. The Ethereum foundation has a good overview of this here, but again, this isn’t restricted to just Eth :slightly_smiling_face:

Hope that’s clarifying, the web2 vs web3 distinction can be confusing vocabulary to those who are unfamiliar :slightly_smiling_face:

Sure, thanks for the clarification. Would you guys mind porting a small example of a subset of the SDK to show us? Still can’t wrap my mind around the IPFS stuff or your Web3API standard.


For this part, I don’t understand how it works. How would you download instantiated wasm contract and query store of it?

1 Like

Hey William,

I thought it would be helpful to post @dOrgJelli’s response here as well, since he had some technical issues posting:

Sure thing, we can take a crack at defining what the schema might look like for Terra. In the meantime, here’s the first draft of a Uniswap Web3API schema that we’re currently working on implementing.

We recently received a grant from the UniGrants program. The schema above is the “public interface” to the underlying WASM modules which contain all of the business logic that will be run within dApps.

As far as understanding the “IPFS stuff” and the “Web3API standard”, here’s some more information to help with that.

In the above example, it shows a Web3API being stored on IPFS, and referenced using an ENS domain. The Web3API client (which implements the standard) resolves Web3APIs in an agnostic way, allowing any developer to define new “api-resolver” implementations to work with other naming & storage systems. A step by step walkthrough of how the Web3API client’s standard works, as well as a helpful architecture diagram, can be found here.

1 Like

Hi Paul,

That’s a great question. Firstly, the WASM modules should not be thought of as “smart contracts”, but rather “business logic”. They take the place of the SDKs that protocols create today (IPFS.js, Ethers.js, Terra.js).

Secondly, the WASM modules containing the query/mutation business logic is stored using a decentralized storage network (like IPFS), and referenced using a decentralized naming system (like ENS). In addition to the WASM modules, the Web3API package contains a manifest file and GraphQL schema. Together, these files make up your deployed “Web3API”.

When your client launches, our “Web3API Standard” handles a number of things at runtime:

  1. it resolves and downloads the Web3API given a valid URI
  2. it instantiates the WASM module being queried
  3. it calls the method being queried (ex: “swap” or “send”)

Web3APIs can also query each other, making composability seamless.


Hey @william, I went ahead and made a small example showing what Terra’s Web3API schema may look like: GitHub - dOrgJelli/init-spec-terra-web3api

The files in the repo are as follows:

  • terra-schema.graphql: This is the public interface of the “Terra Web3API”. The query methods shown here would be implemented in WebAssembly, and able to be executed in any language (JavaScript, Rust, C#, Python, etc).
  • index.ts: An example dApp that queries the “Terra Web3API”. It also sets up an in-memory wallet to be used for all signatures.
  • signer-schema.graphql: This is the public interface of the “Terra Signer Web3API”. The “Terra Web3API” depends upon, and queries into this for signatures. The signer would be implemented as a “Web3API Plugin”, meaning it would be written in JavaScript and added to the Web3ApiClient.

Please let us know if you have any questions.


Did this see any traction?

The Web3API (now known as Polywrap) project has continued progressing nicely! Unfortunately this Terra integration has been stagnant and we haven’t received much feedback. Please feel free to add any opinions you have on whether this sounds like a good integration to have for the Terra ecosystem.

If you’d like to learn more about Polywrap, feel free to join our Discord, happy to discuss more there.

Give highlights / teasing info here? I mean unless dropped funding propsal on Terra