Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Why we need an Internet of Impact to address the sustainability threats that face humanity.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Technical explanations of ixo concepts. For simpler explanations, please see ELI5 topics in the ixo Forum.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
A generic means of production.
Loading...
Loading...
Loading...
Decentralised development finance
Loading...
Loading...
An open knowledge-graph for sustainability.
Decentralised, virtual ...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Decentralised Development Finance.
Loading...
Reference examples of how the Internet of Impact is being used.
Loading...
Inter-blockchain Communication standard.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The ixo Protocol documentation. A work in progress!
The open-source ixo Protocol is the basis for building an Internet of Impact for sustainable social, environmental and economic development and to mitigate climate impacts.
The vision of ixo is to build a global digital immune system for humanity, which will enable us to far more effectively sense and respond to sustainability threats and to invest intelligently in opportunities for positive impact.
This ixo documentation is a work in progress, to which all contributors and users of the ixo protocol and its related open-source software are welcome to help improve.
This is a living document which will be continuously updated. Please refer to the git history for this document to view changes.
Suggest new content
Request features
Give general feedback
Test the documentation by using it!
The preferred way to help make improvements is to post a new discussion, or contribute to an existing discussion, in this Github repo.
Content in the document is copyright of The ixo Foundation. It may be re-used subject to the Creative Commons Attribution-ShareAlike License.
Please attribute the source as The ixo Foundation.
Your contributions will be considered open-source and copyright for permissive re-use will transfer to The ixo Foundation, unless your contributions are based on your own prior art. Please ensure that you do not infringe on the intellectual property rights of others when re-using their content here.
We respect the intellectual property of others and ask that you do too. If you believe any content or materials in this documentation violates a copyright held by you and would like to submit a notice pursuant to the Digital Millennium Copyright Act or other similar international law, you can submit a notice to the ixo Assistant
This website is maintained by ixo.world AG.
The most frequently asked questions. For the rest, chat with the ixo Assistant.
The ixo Assistant contextual AI chatbot is being trained to answer your questions. This assistant gets smarter by being asked questions, using machine learning. So please ask and if it does not know the answer, you will be routed to an ixo team member who can assist you further.
The ixo Assistant can be accessed through Telegram, or the ixo-Webclient and ixo-Mobileclient interfaces.
Pioneered by ixo
Our mission is to enable organisations across the world to coordinate, finance, deliver and verify Impacts at Internet-scale.
The Internet of Impacts provides foundational digital infrastructure for the Impacts Economy
The ixo Platform is an open-source software stack:
The ixo Layer 1 blockchain is purpose-built to implement the ixo Protocol and related services for coordinating, financing, delivering, and verifying Impacts at Internet-scale.
Verifiable Claims capture tamper-proof and accountable digital records of the state of the world, about any imaginable subject.
Claims are evaluated by independent trusted verification services (which ixo describes as Prediction Oracles).
Verified claims with their crypto-economic proofs and data assets are issued as tokenised. For instance a Carbon Emission Reduction claim can produce a verified, information-rich Carbon Credit token.
Tokenised Impact makes the results of development processes more precisely measurable and valuable. Tokens can be traded and used in decentralised development finance mechanisms, such as ixo Alphabonds for Adaptive Financing.
If you feel inspired to learn more: You have come to the right place. Read the docs or ask oxi the Impacts Co-Pilot.
If you want to do more: Join the Internet of Impacts DAO community.
If you are ready to make an impact: Form or become a member of an Impact DAO, launch a Project, invest in or create an Impact Asset Collection, fund or issue an Impact Investment, use or deliver an Impact Oracle Service, and implement or create your own powerful data-driven Impact Protocols.
If you want to build software or data solutions: Visit the ixo Developers Portal.
If you want to host an Impact Marketplace or Impact Exchange: Get in touch with the ixo team.
Why we need an Internet of Impact
Term | Definition in the context of this documentation |
---|---|
Reach out to the ixo team via or .
Agent
Any person, organisation, or machine who has control over a self-sovereign digital identifier (DID), to transact in Internet of Impact networks
Alphabond
Novel impact finance tool with risk-adjusted bonding curve used to provide dynamic risk assessment for funding outcome-based social impact projects. Alphabond Docs
Blockchain
Decentralized, immutable transaction record secured by cryptography and consensus mechanisms.
Cell
The base form of any type of organisation, which is represented by a digital identifier (DID); cyber-cellular organisation to coordinate the activities of agents.
Cell Node
An autonomous, decentralised, sovereign data store and software agent which performs actions on behalf of one or more controller agents. Cell Node Config
Claim
Observed state in the world, submitted by an agent.
Credential
Issued to DIDs by Trust Seeds to create stateful trust graph; grants rights, access, or verifies as a trusted entity.
Cosmos
The Internet of Blockchains, formed by networks built on the Cosmos SDK and Tendermint consensus engine, which are interconnected through the Inter-Blockchain Communication (IBC) protocol
Decentralised Identifier
A W3C standard digital identifier
Delegator
Person or entity who delegates tokens for staking and/or voting with a selected validator.
DID
See Decentralised Identifier
DID Document (DDO)
A set of data describing an Entity Node (the DID subject) in ixo protocol networks; stateful digital record as a collection of JSON-LD attributes and objects related to DID.
Hub
Network of interconnected blockchains or devices.
IBC
Interoperability protocol for communicating arbitrary data between arbitrary state machines.
Inter-blockchain Communication
See IBC
Interchain Identifier
A decentralised identifier (DID) which has been purposed to identify digital assets which are located within blockchain name-spaces
Impact Token
Digital asset which represents interest in the impact economy and its impact claims.
ixo
Name of the open-source project that is building the Internet of Impact. Not an acronym.
IXO
The native utility token of the Internet of Impact Hub
Market Relayer
Agent who cultivates, facilitates, and supports projects, activities, and actors within a regional impact market.
Oracle
AI or human reporting agent attesting to state.
Precision Impact
Defined by a set of 10 Precision Impact Functions: Proofing, Prediction, Personalisation, Prescription, Planning, Proposing, Prevention, Protection, Profiling, and Participation.
Oracle that provides Precision Impact Functions (P-functions).
Proof
Collected data that supports a claim.
Relayer
Validator Node operators of the Impact Hub are referred to as Relayers.
Specification
The data requirements needed to properly satisfy a valid claim.
State
The observed, verifiable condition of the world. Or, the digital representation of this observed state recorded on blockchain as claim.
Token
A medium of value. Digital asset representing a denominated unit of value or, in the case of a Non-Fungible Token, the representation of a real asset or claim.
Validator
A computer server that validates blockchain transactions through peer-to-peer consensus mechanisms.
Validation
The process of verifying the authenticity and the accuracy of a transaction by verifying cryptographic credentials and blockchain state.
Verification
The process of evaluating the veracity of a claim.
Verified Claim
Claim which has been verified by evaluation entities such as a Verification Agent, Auditor, or Arbitrator.
Wallet
DID associated, encrypted, secured data store, such as ixo Keysafe, that holds an Agent's tokens and digital assets.
Zone
ixo Protocol Networks may be independently configured into zones that have their own security, governance and economic mechanisms.
Intelligent in all parts
Adaptive and predictive in real-time
Networked and distributed everywhere
Why the Internet of Impact is unique.
ixo protocol networks are designed to mimic how the human immune system operates. These networks form an Internet of Impact which is conceptually a global digital immune system for humanity.
The purpose of this internet is to sense and respond to sustainability threats or opportunities.
Sensing applications include:
IoT
This decentralised architecture must enable local coordination with rapid information feedback loops. It must be possible to rapidly amplify cyber-physical mechanisms that can support social, environmental and economic interventions to scale effectively and safely.
Humans in the loop
Economy in the loop
Environment in the loop
Oracles in the context of the Internet of Impact are trusted digitally-enabled services that operate on stateful data to perform Precision Functions (P-functions).
Proofing through evaluation and verification of claims
Prediction by determining statistical probabilities and forecasts
Personalisation of interventions and responses
Prescription to program deterministic interventions and responses
Planning support to make decisions about interventions and responses
Proposing how to configure interventions and responses
Prevention through relative risk calculation and alerting
Protection through threat detection and proactive response
Profiling to identify patterns of attributes and features
Participation by enabling humans in the loop
Users employ ixo Oracles to provide these functions on their data. This helps optimise the outcomes, risks and financial results of cyber-cellular organisations, projects and investments.
Oracles are categorised into different namespace types, to help identify the their general purpose. Whilst oracles are all the same entity class, some security and technical characteristics can differ, depending on the oracle type.
For instance, a Treasury Oracle must be listed in the genesis record of an ixo-SDK blockchain. This type of oracle has the privileged capability to programmatically mint, burn or transfer a specific token on the network.
Each oracle has a digital identifier (DID), with one or more verifiable credentials. These credentials are issued by other entities that have a high trust rating, serving as Trust Seeds. This creates a stateful trust graph, based on cryptographic proofs, which can be independently extracted by any Internet of Impact user who wishes to verify that an oracle can be trusted.
Trust must be earned over time. The performance of each oracle is recorded in the blockchain record. For a given oracle, a user can determine from the oracle's transaction history how many services the oracle has provided, to how many different users. They can also see any disputes against the oracle, which were upheld against the oracle provider.
Oracle service providers may be required by the users who employ their oracles, to place a security deposit into escrow, in order to perform services. This performance bond is a risk assurance mechanism for the users of an oracle service. The bond can be slashed if the terms of a Service Execution Agreement are not upheld, when a dispute is adjudicated against the oracle provider.
Oracle launchpad and innovation bonds
Oracle development toolkit
Jupyter Notebooks for designing and training oracles
Federated learning on a Cell Node network
Oracle credentialing
Oracle Type | Purpose (click the links to learn how) |
---|---|
Evaluation Oracle
Approval of claims
Alpha Oracle
Risk estimation
Verification Oracle
Verification of claim and credential proofs (including Zero-Knowledge Proofs)
Credentialing Oracle
Issuance of Verifiable Credentials
Impact Oracle
Precision impact
Audit Oracle
Claims and transactions audit
Banking Oracle
Banking claims
Treasury Oracle
Instruct the network treasury module to programmatically mint, burn or transfer tokens
The digital building-block of ixo Protocol Networks.
A special type of digital document is the digital building-block of ixo Protocol Networks. An ixo document, together with its associated Decentralised Identifier (DID), identifies and describes each entity in an ixo protocol network. This should become interoperable with all other networks that implement the new W3C Internet standards for a decentralised internet.
The ixo Document also associates cryptographic objects with an entity. This gives the entity remarkable capabilities, such as sovereign control over its own identifier and the ability to authenticate with services, using keys that are referenced in the network's decentralised public key infrastructure.
The Internet of Impact is formed by inter-connected decentralised networks of both physical infrastructure and virtual data nodes. Every node which implements the ixo protocol standards can be described as an **ixo Entity. **(The ixo protocol implements core new web standards from W3C).
An ixo Entity has an identity and an associated store of information. The ixo Document provides the genesis record for this information and can maintain a core record of the entity's information and connections. This includes specifying end-points for locating other information and services that are associated with the entity.
Entities connect to other entities, using cryptographic proofs. These authenticated connections form Webs of Trust, through which information and value can securely flow.
By subscribing to standard data models and open data schemas, entity nodes and the connections (edges) between these nodes form an ontologically rich and precise knowledge-graph. These graphs can be searched and navigated through the Internet of Impact and hyperlinked into Web 2.0 networks.
An entity in the context of ixo can be a:
Cell (type of Decentralised Autonomous Organisation)
Project (time-limited coordination mechanism for delivering, evaluating and funding a specified scope of claims)
Oracle (software-mediated data service)
Fund ("smart contract")
Data Asset (dataset, algorithm or encoded model)
Relayer (connecting market need to products and services delivered through the network)
Agent (person, organisation or machine)
Each Entity has an identity, which is defined by a Decentralised Identifier (DID).
An entity is described by information contained in a standard Document format - the DID Document (DDO).
A DID Document is a set of data describing an Entity Node (the DID subject) in ixo protocol networks. The DDO includes mechanisms, such as cryptographic public keys, that the DID subject can use to authenticate itself, to prove their association with the DID and to be given electronic rights (capabilities). A DID document might also contain other attributes or claims that describe the subject. These documents are graph-based data structures which the ixo protocol expresses using JSON-LD (though other compatible graph-based data formats could be used).
The ixo Network maintains a distributed registry of entities, which consists of DID:DDO pairs. An entity DID does not change, but the DDO record can be modified.
All changes to the DDO are permanently stored and cannot be erased. Therefore, the information contained within a DDO on a public network must not contain any private or personal identifier data. For this reason (and to reduce the replicated data storage load on the network), the bulk of the descriptive content relating to an entity is stored "off-chain".
As the default, ixo uses IPFS for off-chain document storage to be persistent and available. Document data stored in IPFS may be either encrypted or unencrypted, depending on the preference of the DID controller. Off-chain objects that form part of the DDO are by default referenced in the DDO using Content Identifiers (CID), which enable the data to be validated and locates the content file without any dependencies on URL paths that tend to break or become unavailable over time.
Learn more about IPFS and content addresses (CID).
ixo Documents are compiled using a logical structure that can be accessed through standard API interfaces. This builds on the principles of the Document Object Model (DOM), which is a core internet standard from W3C.
The generic structure of an ixo document has 3 sections:
Header section which contains the document metadata.
Page section which contains public descriptive content about the entity, with a content-addressable link to off-chain document content (which may be clear-text or encrypted).
Core properties which contains objects for:
Identifiers
Public Keys
Authentication
Authorisation and delegation
Service endpoints
Cryptographic proofs
See the technical specification [insert link] for these document objects.
A DID and DID document do not inherently carry any PII (personally-identifiable information).
When a Document is created on an ixo protocol network, this produces a Genesis Record in the blockchain registry.
ixo Documents can only be updated following protocol rules:
A document update is only valid if it is added to the Document chain, which is an append-only log stored in an ixo protocol blockchain database.
To add an update to the document chain, a valid message must be submitted to the blockchain, which is signed by the controller of the DID for the entity.
The `documentupdate` message must contain a CID pointer to the previous record as prev
, a patch containing the update to the document as content
, and an encoded signature.
Updates to this specification may in future be compatible with the Ceramic Protocol.
⚠️ PAGE UNDER CONSTRUCTION
Accesses the claims in a Cell-node database, for which it is authorised.
Reads the claim data.
Uses external information sources to triangulate and predict the odds of claim attributes being true-positive.
Opines on whether the claim meets pre-determined criteria for approval
Enriches the claim with additional information, such as data transformations and expert opinion.
Issues a cryptographic proof based on the analysis and approval status
⚠️ PAGE UNDER CONSTRUCTION
An Entity is a node in the Internet of Impact graph. The best way of explaining this is to describe the different classes of entities and their primary puposes.
Entities are inter-linked. The relationships between entities are the edges of the impact graph, as illustrated in the example below.
{insert diagram}
Each entity has its own digital identifier, in the format did:ixo:29wribufwiuw984feuf98348fj9f4
and an associated stateful digital record, which is referred to as the DID Document (DDO).
User Story
As a user of the Internet of Impact, I am an Agent with a digital identifier that I can use to authenticate myself with keys that are stored in my Impact Wallet, over which only I have control. As an Agent, I can create a cyber-cellular organisation (Cell) to coordinate the activities of other agents, such as the members of my team, towards achieving a shared mission. I associate the Cell with a Cell Node (web service), which provides computational and data hosting infrastructure for the Cell and its related entities. Now members of my Cell can create one or more Projects. The simplest way of doing this is by using a Template. I can set up an investment entity to form and allocate resources to the Cell and Projects, using an instrument such as an Alphabond. I can employ Oracles to assist with a range of Precision Functions. If I have data assets that will be used by my own and other entities, I can register this data to make it available in a data marketplace. All information and transactions flow between these entities in the format of cryptographically signed messages between identified counter-parties.
The Internet of Impact is formed by networks of Cell Nodes.
Cellular organisations (Cells) are a highly effective coordination mechanism for people to self-organise and self-govern towards achieving a common mission. By definition, cells are decentralised, autonomous, locally responsive, adaptable, hyper-networked, intelligent and purpose-driven. They are highly suitable for virtual and remote teams to work together and share common resources.
Cellular organisations are taken to a whole new level in the Internet of Impact. Cells now benefit from the capabilities of digital communication tools, stateful data, programmable capital and networked intelligence-sharing.
Cell nodes are the digital infrastructure for all types of cellular organisations. These are decentralised, autonomous data stores with digital agency and cryptographic signing capabilities.
Cell nodes have powerful built-in Web 3.0 capabilities, such as:
Stateless validation of data entering the cell node.
Hash-chain data storage, secured by a public blockchain ledger.
Publicly accessible file storage that is content addressable and tamper-proof.
Decentralised authentication using cryptographic identifiers and provable credentials.
Cryptographic message signing.
Cell nodes also connect to the universe of Web 2.0 services through conventional application-programming interfaces (APIs).
Cell nodes are configured to provide cellular organisations with powerful tools that can be used 'out of the box'. Cell nodes also connect through the Internet of Impact to third-party data, application extensions and integrations.
Projects
Secure peer-to-peer communication
Precision Oracles
Data marketplace
Alpha Bond funding
Agent credentialing
Token issuance
Dispute resolution
Crowd-funding
Prediction markets
Bounties
Blockchain Accounting
Legal agreements
The purpose of a Cell defines how it will operate in terms of membership, size, location, lifespan, scope of projects it undertakes and other types of organisational characteristics. A Cell Node is configured to fit the purpose of a cell.
The founder/s of a cell define its purpose - usually with an explicit mission statement.
Examples of cell types and their primary purpose:
Each cell defines its mission explicitly in terms of credible commitments that can be collectively monitored. Cell commitments are accountable, measurable and verifiable. For instance a Procurement Cell can define its mission as: "Source and distribute 1,000 Ventilators to provide care for people infected with the Covid-19 virus."
Participants in a cell are referred to as Agents. Agents include identified individuals, organisations, software agents and devices.
Agent roles can be broadly categorised as:
Implementing agents
Evaluation agents
Investment agents
Each agent is identified by a self-sovereign digital identifier, with associated verifiable credentials. Credentials are issued by known entities within a web of trust. Every message or transaction an agent sends is signed with their Identity. This ensures a high level of agent accountability, trust and compliance.
Agents are given rights for performing specific roles. They issue verifiable claims which attest to the contributions they make towards the mission of the cell. This makes agents fully accountable. The Cell Node is designed to store agent identifiers and credentials in a way that ensures privacy and protects their personal information.
Cells may incentivise agents with tokenised rewards, which are tracked by the Cell Node. Agents can also be economically penalised for not operating within the rules of the cell.
The participants in a cell pursue their mission by implementing one or more projects. The scope of each project is defined in an immutable Project Document. Project information and all the data collected by every project that the cell implements gets stored in the Cell Node.
The performance of each project is tracked through claims which are submitted by cell agents who are authorised to work on the project. Claims are independently evaluated and verified (for instance, by Proofing Oracles).
Cells are independent, sovereign entities within the Internet of Impact. A Cell Node embodies the digital agency of cells with encrypted identifiers, provable credentials and cryptographic keys for authentication, signing messages and secure messaging.
Each cell operates its own private computational and data storage node. Cell Node software and data can be self-hosted or hosted as a service.
The founder of a cell is the ultimate controller, as they hold the keys to the Cell Node and retain full external access control over the cell's data.
The cell founder decides which agents and services are permissioned to connect with the cell and is able to manage or revoke these permissions. Access and authentication is autonomously managed by the Cell Node, without relying on centralised authentication services. This makes Cell Nodes censorship-resistant.
The role of a cell founder is to instantiate the cell, manage the keys of the cell and ensure that the call operates effectively.
The founder of a cell can be:
One or more identified individuals;
One or more identified organisations;
A combination of individuals and/or organisations operating through a decentralised autonomous organisation (DAO).
Cells are principally organisations of people with digital super-powers. To be successful, participants in a cell need to be well-governed, incentivised and empowered. This requires leadership, cooperation and accountability.
Once a cell has been formed, it may be governed by the founder/s or by all the participants in the cell. The Cell Founder configures a governance mechanism when the Cell Node is instantiated.
Cells exist within an economy that broadly have three types of common enterprises, in which cell agents may be incentivised to participate:
Entrepreneurial Common: interfaces the cell with external ecosystems and markets. This common sets financial and monetary policy. It determines the price of cell membership, how the cell is owned and how to distribute capital. Incentives for participation in the entrepreneurial enterprise may be created by issuing and distributing shares or tokens in the cell that embody rights of ownership, economic participation and access to the cell's capital resources.
Production Common: produces goods and services though the cooperative efforts of the cell members. As incentives, contributors may be paid for their work or receive shares for the value they have created.
Beneficial Common: governs the cell's mission, impact goals, operating policies, membership, consensus rules, rights and incentive mechanisms. Voting rights are an incentive for participating in the beneficial common.
There are many possible ways of raising capital resources for a cell. Operating capital can come from more traditional commercial, philanthropic or peer-to-peer sources. Instruments include grants, venture capital, loans, crowd-funding, mutual credit, etc. Now there are also decentralised financing instruments such as tokenisation, Alpha Bonds and Quadratic Funding.
The use of capital by a cell can be transparently tracked and accounted for using the Cell Node's blockchain ledger. This includes a mechanism for tracking financial transactions in fiat bank accounts and representing these on the ledger.
Capital flows can be programmatically allocated and distributed using Alpha Bonds. Conditional payment triggers are linked to provable results. This has tremendous potential for risk-adjusted financing of new ventures and performance-based contracts.
If you can't find a template that suits your specific needs, start a new cell template with guidance from the ixo-assistant chatbot.
Registering a Cell Node with a Decentralised Identifier and Cell Document on the Sustainability Hub incurs a negligible transaction fee (gas) for writing these records to the blockchain.
Cells can choose to employ services and acquire applications from a growing network marketplace, where the costs are determined by providers.
Entity Class | Primary Purpose |
---|---|
are common in nature. Think about how human immune cells sense and respond to threats with targeted precision. Immune cells signal other systems, amplify their responses through replication, produce neutralising or catalytic antibodies and build cellular memory. Each of these has strong analogies with digitally-enhanced cellular organisations.
Cell nodes enable data to be communicated quickly and securely through . All participants in a cell have access to the same information and share intelligence both within their own cell node and with other organisations, through Internet of Impact networks.
The digital artefacts created by a cell (such as Project Documents) are stored in the node as stateful records which are referenced in a distributed ledger. Public metadata are stored using the (IPFS). This allows cell nodes to retain a form of memory that can be shared and rapidly amplified when cells need to be replicated or re-activated.
Cell Type | Purpose |
---|
To view more Cell types and understand the range of purposes for which these have been formed , or search the Internet of Impact through .
Templates for forming different types of Cells can be found in the This is a good place to begin learning from the community it provides a fast-track way to set up your Cell Node, using proven data models and business logic.
Find out more about .
Find out more about and .
Decisions and actions may be made by the Cell Founder, or by cell agents. The Cell Node provides governance tools for stakeholders to make proposals, vote and pass executable resolutions. These tools are available as Cell Node plug-ins, such as Holographic consensus.
The easiest way to start is with a template. Browse to find one that fits close enough to the purpose and other characteristics of the cell you want to form. The ixo explains this further.
The costs of hosting a Cell Node depends on whether this is self-hosted or hosted as a service. For hosted options offered by ixo.world see the .
Agent
The digital representation of a natural person, organisation, machine, or software service.
Cell
The cybernetic unit of organisation for coordinating a network of Agents.
Project
The operational unit for Agents to perform tasks that can be recorded as digital claims.
Investment
The economic unit for programming resource-flows between Agents.
Oracle
A service that operates on stateful data to provide precision functions (P-functions).
Data Asset
The digital representation of any type of data that can be used in a data marketplace transaction.
Template
The generic instance of an entity, which can be used to create a specific instance of the entity.
Citizen Cell | Mobilise citizen action towards a common cause. |
Hackathon Cell | Hack a prototype solution for a specific challenge. |
Procurement Cell | Negotiate the supply of goods/services in an accountable and transparent way. |
Investment Cell | Form and allocate capital for debt and/or equity investments. |
Startup accelerator Cell | Support ventures to find product-market fit and deploy their value propositions. |
Taskforce Cell | Tackle a specific task with a defined mandate and deliverable. |
R&D Cell | Research and develop novel solutions though an experimental process. |
Cooperative Cell | Facilitate broad economic stake-holding in the supply and/or demand of goods and services. |
Mutual Credit Cell | Form and allocate capital through a peer-to-peer marketplace. |
Who operates and benefits from the Internet of Impact
Offer services to projects, in a peer-to-peer marketplace. Submit high-definition claims, using apps and connected devices. Prove your credentials and grow reputation, with self-sovereign identity. Receive automated digital payments for services. See personal performance dashboards, owning your private data.
Project types are
Accreditation
Accountability
Behaviour Change
Circular Economy
Civic Action
Climate Impact
Climate Adaptation
Clinical Trial
Community Currency
Community Development
Commons
Conservation
Decarbonisation
Disaster Response
Ecological Regeneration
Education & Awareness
Enterprise Development
Environmental Protection
Epidemic Response
ESG
Governance
Identity
Impact Investment
Insurance Bond
Intelligence-gathering
Lean Data
Microfinance
Needs Assessment
Opinion Survey
Recycling
Reforestation
Refugee Support
Renewable Energy
Research & Development
Skills Development
Social Enterprise
Social Finance
Social Innovation
Sustainable Capital
Sustainable Consumption
Sustainable Infrastructure
Sustainable Supply Chain
Universal Basic Income
Waste Reduction
Water and oceans
The data management solution in a container that you own, suitable for all sizes of projects.
A project has
Scope
Deliverables
Resources
Time
Set up projects from templates, or or create your own.
Collect, process & store project data, under your control.
Decide who has access to your project, using digital identity credentials.
Employ service providers & verification oracles, with automated payments.
Issue project tokens to incentivise stake-holders and raise project funding.
New: Track bank and token transactions to transparently demonstrate use of proceeds.
⚠️ PAGE UNDER CONSTRUCTION
Verifiable Claims are the basis for all identified data objects in the Internet of Impact.
Claims are nodes in the Impact Graph. They have relationship edges with the entities which issue, hold, inspect, proof and are the subjects of these claims.
Verifiable Claims encode high-definition data, which has the following characteristics:
Resolution to decentralised identifier keys (DID)
Linked-data contexts for resolving ontologies
Cryptographic verifiability of the data object
Content addressability (each claim has a unique identity)
Cryptographic authentication of the subject identifier
Cryptographic authentication of the issuer identifier
Verifiable Claims are serialised as JSON-LD data schema.
Verifiable Claim Type
Primary Purpose
Service Claim
Procurement Claim
Outcome Claim
Identity Claim
Associates attribute values with an identifier. The basis for issuing a Verifiable Credential.
Dispute Claim
Investment Claim
Provenance Claim
Custody Claim
Banking Claim
Use of Funds Claim
What is a wallet
Keys
Types of keys
Credentials
Like a driver's license.
Non-custodial wallets
Custodial wallets
Evaluating claims with precision.
Purpose tokens
How the Internet of Impact is built
ixo Protocol networks are formed by connecting distributed blockchain nodes in a way that is designed to create a global Internet of Impact. This builds on core Internet protocols and standards, but uses additional and repurposed standards, in the same way as Web 2.0 has been adapted to form the Internets of Commerce, Finance, Social Media, Internet of Things, etc.
The ixo Protocols provide additional common operating protocols and standards that build on foundational new World-wide Web Consortium (W3C) standards for Linked-data, Decentralised Identifiers and Verifiable Claims. ixo also builds on emerging Web3 standards for tokenisation, cryptographic message-signing and validation.
Together, the ixo Protocols provide new ways of:
Identifying impact with decentralised identifiers and high-definition data
**Verifying impact **with crypto-economic proofs
**Valuing impact **through tokenisation of impact data assets
The Internet of Impact will become interconnected by the Inter-blockchain Communication (IBC) Protocol. In the future this will also connect across protocols, to a universe of other Web3 networks, including for instance, the Ethereum Network.
ixo Protocol Networks may be independently configured into zones that have their own security, governance and economic mechanisms. These networks may be public or private, closed or open. The building-blocks are modular, open-source software components that anyone can reuse, build on and repurpose for their own diverse applications and use-cases.
These network zones provide the backbone that supports a reticular mesh of project Nodals. Nodals can be thought of as the cells that are responsible for coordinating, resourcing and incentivising the sense and respond activities of the network. Each Nodal is a containerised, sovereign message processing and project data storage component.
Validator Node operators of the Sustainability Hub are referred to as Relayers. These organisations join a consortium which is responsible for securely operating blockchain nodes and to host the software clients that deliver applications to end-users. Relayers also provide channels to the markets in which they operate, providing support to their customers and end-users with value-adding products and services.
Applications built on ixo protocol networks are delivered as web, mobile, IoT and Precision Oracle services. A collection of open-source ixo client applications is available for developers to build on or adapt to their own business requirements.
The** ixo protocols** are based on core new standards for the decentralised internet from the World-wide Web Consortium (W3C).
The software clients that provide the communications, data processing and storage capabilities of ixo protocol networks are modules that build on the generic Cosmos SDK, written in Golang.
In addition to the generic Cosmos modules, which have been purposed for the Internet of Impact, the ixo SDK includes application-specific modules, which include:
Projects Module
Bonds Module
Data Assets Module
Identity Module
Fiat Banking Oracle Module
Alpha Oracle Module
The ixo blockchain contains the records of every claim that is issued against a project and the subsequent evaluation of those claims. Each record is validated by a quorum of validator nodes before it is written to the chain and thereafter the record cannot be removed or updated. This data is then aggregated to build out the final states of the projects.
All the information on the ixo blockchain is publicly available through the ixo Explorer. This data includes the project information, stats regarding the project, the stakeholders of the project and the structure of data being captured against the project. All actual claim data is stored in the Project Datastore.
Much of the data that is captured within a claim is highly sensitive in nature. This data might have specific regulator requirements such as GDPR or maybe the data may not reside outside certain geographical boundaries. In order to comply with this and to also put the data into the hands of the owners of the project we have created the concept of independent data stores for each project.
The ixo Blockchain keeps a link to the location of these project data stores and provides services to the project data that are governed by cryptographic access controls.
All requests that create data or access sensitive data require cryptographic signatures and a capabilities model supports this to provide finer grained access control.
In general update requests are created and signed on the front end using our keysafe which holds the private keys for the user. The request with its signature portion is then passed to the Project Datastore (PDS) when it is processed and the results are then ledgered onto the ixo blockchain with hash references back to the original transaction on the PDS. The block containing the request is then processed on the ixo blockchain and the ixo Explorer syncs this block to the current system state.
When reading publicly availably data a REST call is made to the ixo Explorer which contains the current state of the blockchain. If private information needs to be accessed then a signed request is submitted to the PDS which will respond with the data if the the signature and capabilities of the user adhere to the policies for that data.
The digital dynamo for processing, storing, protecting and sharing impact claims data. Deployed as fully decentralised virtual containers that are identified and secured on the ixo blockchain. A marvel built for Web 3 data sovereignty and interoperability! ixo-pods provide the open-source software infrastructure for all types of data-intensive sustainable development applications.
Automatically deploys when a project is initiated. Configures to the requirements of the project. Validates claim submissions in real-time (eliminating duplicates). Built for high-definition data, based on the new web standards for verifiable claims. Stores data in a cryptographically secured private ledger. Identified and secured by the ixo public blockchain. Includes a powerful event sourcing module and web APIs. Access is controlled by decentralised authentication. Enables secure communications and messaging. Project Founders own and control their project data and decide where this should be hosted. This is free open-source software that is fast, inexpensive and highly scalable.
ixo Data Stores are fast, cost-effective, highly scalable and fully interoperable with a wide range of services.
You hold the keys to your data and decide who gets access. Processes project data automatically, as each claim is checked and validated on submission. No more double-counting. Record claims in a high-definition data format that is machine-readable and verifiable. Each project Publishes claims metadata to the ixo public blockchain, for transparency, accountability and trust. Built for Web 3.
Collect, validate, store and share your project data with private, secure, decentralised data containers, your data is always Built for Web 3, ixo Project Data Stores automatically process and store claims in a new high-definition data format. Each claim is validated and published to the public ixo blockchain.
Software infrastructure for the Internet of Impact.
The ixo blockchain is open-source software to provide computational and data storage infrastructure for the Internet of Impact. This implements open standards to form an inter-operable network of networks. Anyone can set up an ixo blockchain based network, which will provide users with a common set of functionalities.
A network running the core ixo blockchain software can fulfil the following functional requirements:
The ixo Blockchain software is modular. Application-specific networks can configure these modules for their purpose, add new modules, or swap-out some of the non-core modules. These modules are written in Go.
The purpose of each module is briefly outlined in the table and described in technical detail on the linked pages.
The ixo blockchain SDK shares a set of core blockchain modules with the Cosmos-SDK and is built using the same standards. The Cosmos-SDK is a software development kit for building application-specific blockchains.
This enables functional interoperability between blockchains that implement the same modules.
For example:
The MsgSend
function transfers fungible tokens of designated denominations between counter-parties, using the bank module
.
The account
querier function, which is part of the Auth Module
, returns information about an account, regardless of which chain this account is created on.
The IBC module
enables messages to be sent between blockchain networks implementing the Inter-Blockchain Communication Protocol.
ixo Blockchain SDK Module | Purpose |
---|---|
Functional Requirement
ixo Blockchain mechanism
Identify agents
Digital Identifiers (DID) & Verifiable Credentials
Identify cell nodes
Digital Identifiers (DID)
Identify projects
Digital Identifiers (DID)
Identify claims
Content Identifiers (CID)
Revoke identifiers
Distributed revocation list
Open knowledge graph
Distributed Hash Table (DHT)
Locate cell nodes
DNSLink
Program state-changes
Virtual Machines
Authenticate identifiers
Public Key Infrastructure (PKI)
Sign messages
Cryptographic keys
Validate messages
Validator nodes
Verify claims
Oracles
Record proofs of state
Merkle DAGs
Transfer value
Digital wallets
Issue digital assets
Token minting
Incentivise network hosts
Gas fees
Prevent Byzantine faults
Tendermint consensus
Protect against censorship
Distributed validator nodes
Protect against tampering
Hashes
Protect against spam
Message Validation
And more ... not an exhaustive list
Alpha Module
Calculates project risk scores (Alpha) which provide signals to the Bonds module to adjust the pricing of Alpha-Bonds and trigger bond state changes.
Bonds Module
Calculates the buy/sell price and supply of tokens, using configurable bonding curve algorithms and other automated market-maker mechanisms.
Manages the life-cycle of Alpha Bonds.
Cells Module
Maintains a registry of Cell Node identifiers, with associated cryptographic public key material and DNSLink record of the cell's hosting location.
Claims Module
Maintains a registry of Impact Claim digests and claim status, with verification proofs.
Data Assets Module
Maintains a registry of data assets, automates usage rights management and IP ownership/control. Data assets include templates, algorithms, evaluation methods, datasets, etc.
Fees Module
Automates billing, accounting, distribution and settlement of fees for all digital services delivered through the network.
Identity Module
Maintains a registry of trusted root identifiers and revocation lists, based on Web of Trust principles and complying with W3C specifications for digital identifiers and verifiable credentials.
Oracles Module
Maintains a registry of oracles, with staking and insurance mechanisms.
Defines rights for oracles to perform specific functions, such as mint or burn digital assets (using Object Capabilities).
Treasury Module
Issues standard digital assets through mint and burn functions. Maintains a ledger of assets.
Medium Article for Reference: The ixo Keysafe, KYC and becoming an ixo member
The diagram below offers a view of what happens when an 'upload project' message is received from the UI, and which ixo components are involved at every stage, with focus on Cell Node.
How to create your Cell, Project, Oracle, Investment, Data Asset, or Template.
The simplest way to set up a new entity is to use a pre-configured template as a starting document. Search for a relevant template in the web-client Explorer templates library.
Alternatively, initiate the process of setting up your entity through the web-client explorer control panel, where you will find the relevant button in the Actions panel to:
Create a Cell
Create a Project
Create an Oracle
Create a Template
Create a Data Asset
Create an Investment
Optionally, developers can choose to configure as JSON Documents, using the latest ixo-Entity JSON Schema and submit this as a signed message through the ixo-apiModule
Rest API.
Controlled versions of the document data model are maintained in Github.
To understand the concept of an Entity in the Internet of Impact, check out:
Before creating any entity in the Internet of Impact, you must have set up an Impact Wallet and obtained your digital credentials, so that each new entity you create can participate in the web of trust that connects all entities.
To publish your entity onto the Internet of Impact, you will sign a transaction with your cryptographic keys, which are stored in your wallet. A small transaction fee in IXO credits must be paid towards the network costs of processing the data and permanently storing your entity document.
Each entity has its own digital identifier, in the format did:ixo:29wribufwiuw984feuf98348fj9f4
and an associated record which is referred to as the Entity Document (which conforms to the W3C DID-DDO standard).
To create this record, you will need to provide the information described below.
Each entity has a digital Entity Document containing a number of prescribed linked-data Objects. In the following section we will de-mysify these objects and break the document down into 3 sections:
Entity Page
Settings
Advanced Settings
Entity documents can be set up and published using the ixo client software. For this demonstration, we will use the ixo.world web-client interface.
The Entity Page contains information about your entity that you want end-users will view through web and mobile client software. Think of this as your entity's own web page.
This information is input and displayed using cards. The default types of cards available are:
Header card
Body content card
Image in article card
Video embed card
Table card
Profiles card
Linked entities listing card
Cards accept plain text and render this in the pre-formatted style determined by the portal through which the page content is being viewed.
A limited range of markup elements can be used, including hypertext links, which can be included using the standard convention of [link text](link URL)
For the full list of accepted markdown, see Page Formatting
Settings are what define the metadata and operating parameters for your entity. Using the ixo web-client, you can be assisted by the ixo AI Assistant to complete these configurations, which include:
Creator identity, brand and credentials
Owner identity and credentials
Credentials of the entity
Operating parameters, such as start and end dates
Privacy settings and data view permissions
Filter categories and tags
Claims templates for a range of claim types associated with the entity
In this section, you will provide objects such as:
Cell-node binding which determines where the entity data is stored
Associated entities that are linked to this entity, for mapping relationships
Public keys for authentication, message signing and encryption
Services and their associated endpoints
Fund projects to achieve results, using programmable capital. Use financing innovations, such as Alphabonds. Get integrated reporting on financial & development results. Automate agreements and efficiently resolve disputes, using smart contracts. Build and invest in tokenised investment portfolios.
The ixo Protocol
Data standards are the rules by which information is organised, described, formatted, transmitted, and made available for different uses.
These standards include, but are not limited to, data models, data elements (sometimes referred to as schemas), data formats, and data protocols.
The ixo-Protocol describes data standards which are relevant to information about impacts and changes in the observable state of the world. This enables impacts and world states to be described, verified, compared, and transformed into digital assets.
The ixo Protocol provides standards for:
evaluation
Data standards make it easier to publish, share, and use data across diverse communities. Standards can significantly enhance data quality, open new markets, promote innovation, enable the creation of sharable tools and services, lower costs for data production and use, support policy implementation, encourage collaboration, and much more.
ixo-Protocol data standards are based on the W3C specifications for Linked-data, Verifiable Credentials and Decentralised Identifiers.
⚠️ PAGE UNDER CONSTRUCTION
The simplest way to start configuring a claim template is to use a pre-existing template as the basis. Templates can be found in the Templates Explorer section of the ixo-webclient.
Every claim template has three sections, with associated objects:
Form fields, which includes the following types of cards:
Short text
Long Text
Multiple-choice
Radio button
Photo capture / image upload
Picture selector
Sliding scale
Video capture / file upload
Sound recording / file upload
Document scan / file upload
QR code scan
Email with validation
Mobile phone with validation
Identity and credential with validation
Profile photo for identity verification
Settings, which includes metadata about the claim template:
Creator
Owner
Status
Version
Terms of Use
Privacy Settings
Privacy Credentials
Filters
Display Credentials
Embedded Analytics
Advanced Settings
Linked Entities
Payments
Staking
Nodes
Funding
Keys
Services
Data
To create a from scratch, you can ask the ixo-assistant to guide you through the process by asking something like "I want to create a new Service Claim template". This will open up the relevant page in the ixo-webclient where you can complete the claim template setup using the configuration form.
Verifiable Claims are defined as a using JSON-LD.
How to configure a Matrix App for your node
Adding a Matrix app to your cell enables you to organise collaboration rooms for your agents, teams and community. Matrix provides chat, file-sharing, video/voice calls, group conferencing and more.
You can create rooms with different topics and membership groups for your cell and for each of your projects.
The default Matrix Client used by ixo.world is Riot Chat. This has been described as the open-source alternative to Slack. When your user clicks on the Riot app badge in the Control Panel of your cell or project, this opens up an external window that directly brings the user into the default piublic and private rooms for your cell or project.
The default room ID is the DID of your cell or project, which gets automatically created for you. You may choose to create additional human-readible aliases for your room, using the Riot client.
Matrix bridges across to other popular communications and collaboration platforms. This means that your users can channel data and messages to or from the tools they already use and love, including platforms such as Slack and Discord. This brings your cell and projects into your users' chosen collaboration environment/s and workflows.
By default, this Matrix app is configured to use a server hosted by ixo.world, which is physically located in the EU on the island of Malta. The URL of this server is https://comms.ixo.world
This server has been customised to use DID-Auth for security and convenience (so there is no need for separate user names and passwords!). However, you may choose to change your hosting to any other matrix server and you can port all your data if you choose to move servers.
To configure this App for your cell or for each of your projects, you must first connect to the Matrix server. This guideline will describe the process for the ixo.world server. For other servers, see the Matrix documentation.
To register as a Matrix user, you will authenticate into the Matrix server at comms.ixo.world, using your ixo Keysafe (or ixo Mobile Wallet) to sign in. If you have already registered previously using your DID (or !id), just go ahead and sign in.
Now you will be requested to configure:
The room topic
Whether to provision a public room that anyone can access
Whether to provision a private room that is by invitation only
If members of the private room are permitted to invite new members
After submitting these settings, you are done!
The Riot app will now appear in the Control Panel for your cell or project, ready for your agents and community to start communicating!
For more guidance on how to use the powerful features of Matrix, from within the Riot client, see this documentation.
To remove this App from your cell or project and to change the configuration settings, return to the App configuration panel.
Matrix implements state of the art end-to-end encryption to ensure that your private communications remain private.
Configure projects & workflows using shared libraries & developer tools. Rapidly deploy customised apps on an open infrastructure. Plug into the Ethereum Decentralised Application solution space. Integrate with other services (including legacy systems) through web APIs. Extend the core SDKs and contribute to the ixo open-source project.
Guideline for developing and displaying content on the Internet of Impact
The purpose of documents in the Internet of Impact is to record information in a stateful way. The ixo protocol standard is that a document must be:
Verifiable
Attributable
Semantically interoperable
Universal addressable
Human-readable
Machine-readable
Non-repudiable
Tamper-resistant
Persistently available
Private by design
The ixo protocol defines a set of standard document types, which are used as building-blocks.
Each identifiable subject in the Internet of Impact has a Decentralised Identifier (DID). A specifically formatted document is associated with a DID, the DID Document (DDO), which is based on the W3C specification.
The W3C describes a DID Document as "A set of data describing the DID subject, including mechanisms, such as public keys and pseudonymous biometrics, that the DID subject can use to authenticate itself and prove their association with the DID.
A DID document might also contain other attributes or claims describing the subject. These documents are graph-based data structures that are typically expressed using [JSON-LD], but can be expressed using other compatible graph-based data formats.
The following DDO document subjects are defined in the ixo context:
Cell document
Project document
Oracle document
Bond document
Data Asset document
A generic template (in JSON Template standard format) for each of these documents is currently maintained in Github under custodianship of the ixo Foundation.
The generic structure of an ixo protocol DID Document is illustrated below.
[insert illustration]
Document Page is the information which is displayed to an end-user. This uses standard Markdown Format for styling and to embed media into the page. See the Page Formatting guide.
Claims are high-definition data objects which encode information in a way that is portable, self-declarative and verifiable. Claims comply with the document standards by implementing the following features:
Subjects are identified in a way that can be authenticated, using a DID.
A schema context is declared, which resolves the claim data to a set of standard semantic definitions.
An issuer is identified and authenticated, using a DID.
The claim is cryptographically verifiable by its hash value and signatures.
The claim object is content-addressable by its hash value (using the IPLD specification).
The following claims categories are defined in the ixo context:
Identity claim (credential)
Impact claim
Evaluation claim
Dispute claim
Transaction claim
A generic template (in JSON Template standard format) for each category of claims is currently maintained in Github under custodianship of the ixo Foundation.
The basic structure of an ixo protocol Claim is illustrated below.
[insert illustration]
The standard for displaying document information to end-users
Pages are formatted using standard Markdown.
Use the Markdown Lint style checker tool to validate whether your page conforms with a common set of rules.
Develop your page in HackMD and use the Markdown Lint feature to debug your formatting, before copying and pasting into the Page section of your document in the ixo document editor.
Developers are spoilt for choice!
Are you a Validator?
Refer to our Github documentation for details about setting up a testnet node onpandora
or a mainnet node on ixo.
Become a Market Relayer
Refer to this simple guide to combine parts of ixo into a powerful marketplace.
The ixo Blockchain is a Layer 1 blockchain built using the Cosmos SDK, Tendermint, and IBC, and uses CosmWASM for smart contract support. It is recommended that you become very familiar with these technologies if your aim is to contribute to the ixo-blockchain
code base. Hands-on tutorials, training courses, and support channels are available at the links above that will assist your learning. You can find the ixo Blockchain Github repository here.
The ixo MultiClient SDK provides a way for client application developers to interact with the ixo Blockchain. It is a package written in TypeScript and hosted on the npm Registry. You can find the ixo MultiClient SDK Github repository here.
The ixo Mobile Client is a mobile application built using React Native. It uses the ixo MultiClient SDK to implement features supported by the ixo ecosystem. You can find the ixo Mobile Client Github repository here.
JAMBO is a Jamstack application that uses Next.js and deploys to Netlify. It provides developers with a framework for rapid development of dApps compatible with any Cosmos chain. It uses the ixo MultiClient SDK to implement features supported by the ixo ecosystem. You can find the JAMBO Github repository here with detailed instructions.
The ixo Web Client is a web application built using React. It uses the ixo MultiClient SDK to implement features supported by the ixo ecosystem. You can find the ixo Web Client Github repository here.
The ixo BlockSync server provides a means to keep public blockchain data in a non-blockchain database for data aggregation and simple retrieval by client applications. It uses TypeScript and PostgreSQL to provide a GraphQL interface. You can find the ixo BlockSync Github repository here.
The ixo CellNode is a decentralised data processing and storage node for private and public data. It uses TypeScript and PostgreSQL. You can find the ixo CellNode Github repository here.
Reach out to the ixo team via Discord, Telegram, or Slack and we will gladly support or point you in the right direction.
How to Interface with the ixo blockchain SDK
The ixo blockhain SDK provides three interfaces for interacting with a node:
command-line interface
gRPC interface
REST interface
Each interface can be used to query the state. The command-line interface can be used to generate, sign, and broadcast transactions, whereas the gRPC and REST interfaces can only be used to broadcast transactions (a transaction needs to be generated and signed either programmatically or using the command-line interface before it can be broadcasted using the gRPC or REST interfaces).
The most straightforward way to interact with a node is using the command-line interface; also known as CLI.
The ixo binary serves as the node client and the application client, meaning the ixo
binary can be used to both run a node and interact with it. In Quick Start, we started a local node using the ixo
binary and then interact with that node by submitting queries and transactions.
To learn more about the available commands, install ixo and run the following:
For transaction commands:
For query commands:
For more information about the CLI, check out the Cosmos SDK Documentation.
gRPC is a modern RPC framework that leverages protocol buffers for encoding requests and responses between a client and service. The ixo blockchain SDK uses gRPC primarily for querying blockchain state (token balances, data signature records, etc). As a client developer, this means you can query the ixo blockchain state directly by using a gRPC library in your programming language of choice, in combination with the ixo blockchain protobuf definitions .
In addition to using a gRPC library, you can also use grpcurl - a command-line tool that lets you interact with gRPC servers. If you have a local node running, you can list the protobuf services available using the following command:
To execute a call, you can use the following format:
In some programming languages, you may be able to leverage a pre-existing client library to take care of most of the heavy lifting, including compiling protobuf messages. For javascript/typescript developers, the ixo Client-SDK (based on CosmJS) is a good place to start.
For more information about the gRPC interface, check out the Cosmos SDK Documentation.
All gRPC services and methods for the ixo blockchain SDK are available for more convenient REST based queries through gRPC Gateway.
For example, you can query the balance of an address using the following curl
command:
To interact with the REST interface, make sure you have API server and (optionally) Swagger UI enabled in your ~/.ixo/config/app.toml
file. With Swagger UI enabled, you can go to http://localhost:1317/swagger/
to read through the OpenAPI documentation.
For more information about the REST interface, check out the Cosmos SDK Documentation.
A synopsis of the Internet of Impact.
An Internet for sensing and verifying changes in the state of the world. The ixo Protocol defines the new standard for making Verifiable Impact Claims about how people and organisations are changing the state of the world, using high-definition data as evidence.
Claims are independently verified by trusted Prediction Oracle services, who issue Impact Proofs and certified digital credentials. These digital assets replace or enhance legacy instruments, such as Renewable Energy Certificates.
Impact Producers use their verified data, proofs and certified credentials, to mint non-fungible Impact Tokens.
The SignX SDK provides an easy way to integrate mobile-to-web authentication and transaction signing using the IXO blockchain in your applications.
This repo and product is intentionally managed as Open Source and we aim to use this guide to light our way https://opensource.guide/. Let us know how we are doing!
The SignX SDK orchestrates a seamless and secure interaction between client applications, a mobile app, and a server, encapsulating the complexities of mobile-to-web authentication and transaction signing on the IXO blockchain. The flow is initiated when a client application triggers a login request through the SDK, which in turn generates a unique identifier and a secure hash. This information is encoded into a QR code that is displayed to the user. Upon scanning this QR code with the mobile app, the user's account details are securely transmitted to the server.
During this phase, the SDK engages in a polling mechanism, continually checking the server for the authentication response corresponding to the QR code data. This ensures that the client application is updated in near real-time once the user has completed the scanning process. The SDK has built-in error handling and timeout features to manage scenarios where the response from the server is delayed or unsuccessful. Upon receiving a successful response from the server, the SDK triggers an event notifying the client application of the successful login, and provides the user's account details for further interactions.
With the user now authenticated, the SDK facilitates transaction operations. When a transaction is initiated through the SDK, it packages the necessary transaction data and securely transmits this, along with a unique transaction hash, to the server. Similar to the login flow, a QR code is generated for the user to scan using the mobile app. This QR code encodes information required for the mobile app to retrieve the transaction data from the server, sign the transaction, and broadcast it to the IXO blockchain.
Post the QR code generation, the SDK re-engages its polling mechanism, constantly checking the server for updates regarding the transaction status. The mobile app, after broadcasting the transaction, uploads the transaction response to the server. Once the server processes this response, it updates the transaction status which is then picked up by the SDK in one of its polling iterations. Upon receiving a successful or failed transaction response, the SDK emits an event to inform the client application of the outcome, thus completing the transaction flow.
Through this orchestrated flow, the SignX SDK abstracts the technical intricacies, providing a straightforward and secure way for client applications to leverage mobile-to-web authentication and transaction signing on the IXO blockchain.
The SDK is crafted to interact harmoniously with a designated server, which handles the storage and provides the necessary endpoints for polling data during the authentication and transaction processes. To fully leverage the SDK's capabilities and ensure a streamlined operation, it is essential to set up and utilize the accompanying server, the source code for which can be found here.
This SDK exposes a client class SignX which can be instantiated in your client applications to interact with the SignX server and mobile app for various operations.
Import and initialize the SignX client in your application:
Initiate a login request using the login
method:
Subscribe to events for success or failure here
Initiate a transaction using the transact
method:
Subscribe to events for success or failure here. TRANSACT_DTO type can be seen here
Listen for success and error events emitted by the SignX client:
Hashes transaction data for use in the transact method:
Generates a secure hash from a given hash and nonce:
NETWORK: The network type:
TRANSACT_DTO: The data transfer object for transactions:
timeout: The timeout for polling in milliseconds (default is 2 minutes).
pollingInterval: The interval between polling requests in milliseconds (default is 2.5 seconds).
network: The network type.
endpoint: The endpoint URL of the SignX server.
sitename: The name of your site. (shown on mobile app on request)
login: Initiates a login request and starts polling.
transact: Initiates a transaction and starts polling.
stopPolling: Stops the polling process.
Example used in a React project:
This SDK is licensed under the Apache 2 License. See the LICENSE file for more information.
Everything you need to run your own Market Relayer
A seamless experience to access your assets and offset your carbon footprint
Create web-based dApps for any Cosmos chain using simple pre-built actions
The Ixo Message Relayer is a server that facilitates a meticulously coordinated sequence of operations ensuring mobile-to-web authentication and transaction signing on the IXO blockchain. The process kicks off with the Login module, where the SDK generates a random hash and a secureHash (which is a SHA-256 hash of the hash and a secureNonce). A QR code, containing this hash, is then displayed for the mobile app to scan. Once scanned, the mobile app uploads the user data to the server using this hash as an identifier of the login request, which the SDK is polling for. This endpoint is secured with an AUTHORIZATION environment variable, ensuring only the mobile app with the correct authorization can upload this data. Subsequently, the SDK polls the server to fetch the login data, providing a secureNonce in the process. The server validates the request by hashing the provided hash and secureNonce to ensure it matches the secureHash, thereby affirming the authenticity of the user making the request. Upon validation, the server returns the login data to the SDK and purges the data from the server to maintain data cleanliness.
Transitioning to the Transactions module, the SDK creates a transaction request by uploading all the necessary transaction data along with an identifier hash, which is derived from the hash of the transaction data. This hash acts as a unique identifier for the transaction. Upon scanning a QR code generated by the SDK, the mobile app fetches the transaction data from the server using this hash. This endpoint is also protected to ensure only the mobile app can access the transaction data. The mobile app then validates the integrity of the data received from the server by hashing the data and ensuring the hash matches the hash it obtained from the QR code, thereby ensuring data authenticity and thwarting any potential middleman attacks. Following this, the mobile app signs the transaction, broadcasts it to the IXO blockchain, and updates the transaction status on the server, either as success or failure. This update endpoint is also protected to ensure only the mobile app can update the transaction data. Concurrently, the SDK polls the server to fetch the transaction response for the provided hash, allowing it to retrieve the response only for the transaction that was updated by the mobile app.
The server's response to all endpoints is structured in a consistent format, encapsulated in an object. This object always contains a success field indicating the success or failure of the intended operation. Additionally, there's a data field which generally houses a message field explaining the reason for the success or failure of the request. If there's data to be provided, it is encapsulated within this data field. For the polling endpoints like login fetch and transaction response, there's an additional code field in the response. A code value of 418 signifies that even if the success field is false, the SDK should continue polling and not throw an error, ensuring a robust and resilient flow of operations.
Ensuring the secure and efficient operation of the Ixo Message Relayer Nest.js server, various environment variables are configured to govern aspects like authorization, and database management. The .env.example
file illustrates a templated structure of these variables, providing a guideline for environment setup.
Here's an overview of each environment variable and its utility within the application:
PORT: Specifies the port number on which the Nest.js server will run.
AUTHORIZATION: Utilized for authorizing API requests, ensuring they originate from authenticated sources. The Authorization header in API requests must precisely match this value (example: Bearer u4D81XDt4YsbXo6KSynYFChk
).
DATABASE_URL: The full PostgresQL database uri as provided in example.
SENTRY_DSN: Sentry DNS for Sentry error logging to catch production issues.
It is paramount that sensitive variables such as AUTHORIZATION and DATABASE_URL are secured and not exposed to unauthorized personnel or systems. Employ stringent security practices like utilizing secrets management tools, employing strict access controls, and conducting periodic security audits to ensure the confidentiality and integrity of these critical data points.
To implement these configurations, developers need to create an .env
file, using .env.example
as a template, and supply the appropriate values for each variable, ensuring the secure and tailored operation of the server based on the specific deployment environment and use case.
This environment configuration section can serve as a guide to developers, system administrators, and other stakeholders involved in the deployment and maintenance of the server, providing a structured view of the configurable elements that dictate the server’s functionality and security.
If you prefer to run the application inside a Docker container, we've provided a Docker image for convenience. The image is available at ghcr.io/ixofoundation/ixo-message-relayer:v0.0.1
and an example docker-compose file is below for reference:
/login/create
This endpoint is utilized by the mobile app to store login request data on the server. Upon scanning a QR code generated by the SDK, the mobile app initiates a login request by sending the relevant data to this endpoint. The login data is stored on the server under a unique hash identifier generated by the SDK, which facilitates subsequent polling by the SDK to retrieve this data for user login. The endpoint is protected by an authorization mechanism to ensure that only the mobile app can upload login data.
Parameters
hash
: A unique identifier for the login request.
secureHash
: A secure hash generated by hashing the hash
and a secureNonce
.
data
: The login request data.
success
: A boolean indicating the success status of the login request.
Request Body
Response Body
Response Properties
success: Indicates whether the request to server was successful.
data:
message: A message explaining the success or failure of the request.
Usage
/login/fetch
This endpoint facilitates the retrieval of login request data that was previously stored on the server by the mobile app. The SDK polls this endpoint to fetch the login data for a user based on a unique hash identifier. The server validates the request by hashing the provided hash and a secureNonce to ensure it matches the stored secureHash, thereby affirming the authenticity of the user making the request. Upon validation, the server returns the login data to the SDK and deletes the data from the server to maintain data cleanliness.
Parameters
hash
: A unique identifier for the login request.
secureNonce
: A secure nonce generated by the SDK.
Request Body
Response Body
Response Properties
success: Indicates whether the request to server was successful.
code: A code indicating whether the SDK should continue polling (418 if it should continue).
data:
message: A message explaining the success or failure of the request.
data: The login data
success: Wether the login was a sucess or fail due to rejection on mobile for example
Usage
/transaction/create
This endpoint is utilized by the SDK to store transaction request data on the server. The SDK initiates a transaction request by sending the relevant data, along with a unique hash identifier (which is also the hash of the transaction data), to this endpoint. This hash facilitates subsequent retrieval of this data by the mobile app for signing and broadcasting the transaction. The endpoint validates the request by hashing the provided transaction data and ensuring it matches the provided hash, thereby affirming the authenticity of the transaction data.
Parameters
hash
: A unique identifier for the transaction request which is also the hash of the transaction data.
address
: The address involved in the transaction.
did
: The decentralized identifier involved in the transaction.
pubkey
: The public key of the user initiating the transaction.
txBodyHex
: The hexadecimal encoded raw txBodyBytes which can be encoded from the registry exported from @ixo/impactxclient-sdk npm package (eg registry.encodeTxBody({ messages, memo }))
timestamp
: The stringified utc DateTime, add uniqueness for tx hash to prevent duplicates (eg new Date().toISOString())
Request Body
Response Body
Response Properties
success: Indicates whether the request to server was successful.
data:
message: A message explaining the success or failure of the request.
validUntil: The ISO 8601 formatted datetime string indicating the expiry time of the transaction request
Usage
/transaction/fetch
This endpoint allows the mobile app to fetch the data of a specific transaction request based on a unique hash identifier. After scanning the QR code displayed by the SDK, the mobile app uses the hash to retrieve the transaction data from this endpoint for signing and broadcasting the transaction. The endpoint is protected to ensure only the mobile app can access the transaction data, and it validates the request by checking the hash against the stored transaction data to ensure data authenticity.
Parameters
hash
: A unique identifier for the transaction request.
Request Body
Response Body
Response Properties
success: Indicates whether the request to server was successful.
data:
message: A message explaining the success or failure of the request.
address: The address involved in the transaction.
did: The decentralized identifier involved in the transaction.
pubkey: The public key of the user initiating the transaction.
txBodyHex: The hexadecimal representation of the raw encoded transaction body.
timestamp: The The ISO 8601 formatted timestamp when the transaction request was created.
Usage
/transaction/update
This endpoint is leveraged by the mobile app to update a transaction request's data on the server following the signing and broadcasting of the transaction. The mobile app sends the transaction response data to this endpoint, which then updates the corresponding transaction request record on the server. The endpoint is protected to ensure only the mobile app can update the transaction data.
Parameters
hash
: A unique identifier for the transaction request.
data
: The response data of the transaction.
success
: A boolean indicating whether the transaction was successful or failed.
Request Body
Response Body
Response Properties
success: Indicates whether the request to server was successful.
data:
message: A message explaining the success or failure of the request.
Usage
/transaction/response
This endpoint is utilized by the SDK to poll the server for a response to a specific transaction request. By providing the unique hash identifier for the transaction, the SDK can retrieve the response data updated by the mobile app. This endpoint facilitates the flow where after the mobile app signs and broadcasts the transaction, and updates the server with the response data, the SDK polls this endpoint to obtain the response.
Parameters
hash
: A unique identifier for the transaction request.
Request Body
Response Body
Response Properties
success: Indicates whether the request to server was successful.
code: A code indicating whether the SDK should continue polling (418 if it should continue).
data:
message: A message explaining the success or failure of the request.
data: The response data of the transaction.
success: Whether the transaction was a success or fail due to rejection on mobile for example.
Usage
The combination of , and the provides the system components needed to set up and run your own Market Relayer to support impact projects.
Login uses an email link powered by for an easy view of the dashboard containing coins, tokens, and assets.
integration simplifies the purchase of carbon NFTs using the Emerging .
Take a closer look at the ixo Mobile Client .
This handy tool opens the door to with millions of users!
On top of that it plays nicely with the for a seamless Web3 experience.
Detailed instructions in the JAMBO make it really simple to use.
Do you have a non-JAMBO dApp that requires access to ? Take look at the .
The server is designed to work seamlessly with a complementary SDK which facilitates the management of various authentication and transaction flows between web clients, mobile applications, and the server itself. For more comprehensive insights and utilization of the server's capabilities, you may explore the SDK source code hosted on or directly integrate the SDK into your projects via the published .
This SDK is licensed under the Apache 2 License. See the file for more information.
The ultimate utility client for the ixo Blockchain
You can interact with the ixo Blockchain using this SDK written in TypeScript and hosted on the npm Registry. All of the blockchain RPC messages, and more, at your fingertips!
You will find extensive documentation about this powerful tool in the Github repository here.
The tests
folder is especially helpful for understanding how to use the SDK.
The Impact blockchain for the Cosmos ecosystem
The following instructions allow you to run a single node network on your local machine and interact with it using the command line interface (CLI). It is the simplest way to become familiar with the ixo Blockchain.
After completing this guide you can run a node on the pandora
testnet.
We recommend the use of Docker and Docker Compose. The configuration files are provided in the ixo-blockchain
directory.
Another way to interact with a node is the ixo MultiClient SDK, instead of CLI.
You will need the following to install and run the ixo
binary:
Optional:
The ixo
binary is named ixod
and serves as the node client and the application client. In other words, the ixo
binary can be used to both run a node and to interact with it.
Clone the ixo
repository:
Change to the ixo-blockchain
directory:
Check out the latest stable version:
Start a session (let's refer to it as session 1
).
Install the ixo
binary.
Check to make sure the installation was successful.
Start the ixo-blockchain
node using pre-configured data.
The script will start the blockchain and create accounts appropriate for the ixo-blockchain
to enable easy interaction. The blocks will progress and you should see the logs to confirm it.
Start another session (let's refer to it as session 2
).
Use the ixod
CLI to query the total bank balances.
You can now interact successfully with the ixo
binary.
Go back to session 1
.
Stop the running node using CTRL
+ C
.
There are two ways to restart the node:
With the same data and continuing from the same block height.
or with the data reset to the first time the node started successfully and from block height 1.
Create a Docker image called ixo-chain
and tagged devel
.
Compose a Docker container.
Start a Bash session (let's refer to it as bash session 1
).
Install the ixo
binary.
Check to make sure the installation was successful.
Start the ixo-blockchain
node using pre-configured data.
Script will start the blockchain and create accounts appropriate for the ixo-blockchain
to enable easy interaction. The blocks will progress and you should see the logs to confirm it.
Start another Bash session (let's refer to it as bash session 2
).
Use the ixod
CLI to query the total bank balances.
You can now interact successfully with the ixo
binary.
Go back to bash session 1
.
Stop the running node using CTRL
+ C
.bash
There are two ways to restart the node:
With the same data and continuing from the same block height.
or with the data reset to the first time the node started successfully and from block height 1.
⚠︎ Page Under Construction