Improve Integration Experience - Project plan

Devhub and Integration Documentation









Rework navigation and user flow

  • Currently, the site takes a “list information” approach and is not geared to a specific user (e.g., wallets, exchanges, etc.)

@David Gold suggested we migrate to target specific integrators: Wallet Integration, Exchange Integration, etc. We would pull out common tasks into shared pages, but would gear the integration language to be specific to the different use cases.

Suggested outline:


Building an API node and upgrade process (for wallets and exchanges)

  • Create a document on the different paths to building an API node


Integration guide

  • Fixes to new integration guide from Pawel


Indexing transactions

  • Add more detail on indexing transactions


Submit transactions: Packing and Signing

  • Add more detail on packing and signing transactions


BP Voting and Proxying

  • Updating voting page to clean up and add intro on how to research BP activity



general BP info

  • Links to different BP resources



FIO Versioning

  • Port Versioning document from confluence
Dev hub page:


Pub/Priv Keys

  • Info on deriving and validating FIO Pub/Priv Keys
Devhub page:


BP Fee setting

  • BP Fee setting - update with links to tools



UX best practices

  • Document best practices for UX (@Emily Mader )


History API

  • Add history API


Purchase of domains and addresses

Simple explanation of how to purchase a domain or address if you are a new integrator. How to transfer if it is owned by the foundation.

Also the pros and cons of holding the keys for a domain versus having the foundation hold the keys.


Free FIO Address workflow

How to integrate free fio address giveaways into your site




In be more explicit that an action consists of account, name, authorization and serialized action data. May want to add an action type to the API. There is an example there under Transaction Schema, but needs more detail



Integration overview

@ericbutz @pawmmm I think I’ve seen this question before regarding TPID and max_fee so let’s think through how we can explain these concepts up front. Same for the need to pack and encrypt certain body payloads. I know it’s there buried in the details but mentioning there terms and explaining them up front in a getting started section may be useful.



Complete SDK main page

Need to populate with all SDKs:



Integration Checklist

  • Complete integration checklist page.

  • Include list of which integrations are done for which partners



  • Complete certification pages. Include map all currencies and review on






Free FIO Addresses on private domains

  • We need to better describe the options for registering “free” FIO Addresses on domains that will be kept private.



EOSIO content

  • Use content similar to eosio


Devhub Readme

  • Create readme similar to eosio


Ecommerce Integrators page

  • Home page link for ecommerce integrators - work with Pawel



FIO Dev Guide

  • Contributing to FIO dev page

Example: (not sure if that’s the post I was thinking of, but there are others that talk about this)



  • Create document on accessing FIO nodes (multicasting)


Address/Domain renewal

  • Add page on address/domain renewal


API Error Codes

  • Clean up error codes (and make generic) some 403s look incorrect.

  • Add 202 response to all actions (make this generic). See old site


OBT and Request auth checks

  • Writeup on authority checks with FIO Requests


FIO Contract development

  • FIO Contract development - Description of how to create actions and getters in contracts


Mapping options

  • Document different mapping options


Compatibility matrix

  • Matrix for different releases


Known issues

  • Document the known issues and helpful hints with SDKs, APIs, and chain.


FIO Glossary

  • Add a glossary of FIO terms


Devnet setup

  • Add a section on devnet setup


API - addaddress

  • Add explanation of chain level mappings



APIs and SDKs













Leverage existing EOSIO libraries and code

  • FIO chain code has diverged from EOSIO core code making it difficult to “plug and play” with existing EOSIO tools


Support for unique FIO endpoints

  • Support for transaction-based API endpoints creates release overhead and could cause confusion


Complexity of chain code releases

  • The need to update the chain code for every new getter adds release overhead.


Simplify Fees

  • Change how max_fee works to include a buffer on the current fee set by the BPs


SDKs and third-party libraries




Simplify SDK and reduce upgrade complexity

  • We would like to reduce the number of upgrades required by integrators

    • Integrators should be able to access all Mainnet features, including getters and contract actions, without having to upgrade.

    • SDK updates should only be required for bug fixes and when breaking changes in the API are introduced.


Reduce complexity of SDK

  • A proliferation of getters and api endpoints increases the size and complexity of the SDK


Serialization and encryption


Standardize and simplify serialization and encryption libraries

  • The encryption used in FIO Requests and OBT Record actions is non-standard

  • There are issues with the fiojs library including encryption libraries, difficulty of integrating with other EOSIO tools, and maintaining a copy of eosjs


I’ve had good success so far using AnchorLink, though it is front-end specific and currently requires Anchor. That said, under the hood, is EOSIO Core which seems to be a useful improvement over eos.js or fio.js and it supports FIO well (such as allowing you to pass in a legacy prefix such as FIO when getting public keys).

I think this is a really important problem to overcome. It should be easy for any developer to quickly work with OBT data, send, receive, cancel, and approve FIO Requests without having to import tons of extra code or libraries or sdks, especially if most everything of what they want can be done via things like EOSIO Core from Greymass. If existing tools for interacting with EOSIO chains will work well with FIO, we should embrace them and provide very minimal code needed to do FIO specific things.

We also need to figure out how “authenticator” wallets like Anchor, Metamask, and Ledger (hardware) wallets can work with OBT data. What’s the path of least resistance for them to get up and running quickly? What’s the minimal code footprint we’ll be asking them to introduce? How will this work with secure enclaves coming in the future with crypto-enabled hardware devices like phones.