# Zion v2 Abstract > A purely peer-to-peer version of content distribution would allow information across the web to be sent directly from one party to another without going through a trusted third party. Digital identifiers provide part of the solution, but the main benefits are lost if a trusted third party is still required to store and move that content across the web. We propose the use of distributed data networks, identifiers using [DID](/architecture/did)s, and payments using the [Bitcoin Lightning Network](/architecture/bitcoin-lightning-network). This network stores [DID ION](https://github.com/decentralized-identity/ion) transactions by hashing them into an ongoing chain of hash-based proof-of-work core, forming an unchangeable record. Data would be stored across [Decentralized Web Nodes](/architecture/decentralized-web-nodes) that create an open transport network of information. **Introduction** Digital interactions on the internet have come to rely almost exclusively on trusted third parties. Content aggregation is mostly run by companies serving as trusted third parties to process content distribution across the web. While the system works well enough for most digital services, it still suffers from a few inherent weaknesses: the lack of a trust based model, single points of failure, and a lack of financial transparency. What is needed is a content distribution system based on cryptographic signatures instead of trust. This allows any two willing parties to share content directly with each other without the need for a trusted third party. We propose using a peer-to-peer distributed network of [Decentralized Web Nodes](/architecture/decentralized-web-nodes) to solve the problem of centralized content networks. This gives creators ownership of their data without having to capitulate to the requirements of third parties or a blockchain. This system must be built for [Web5](https://developer.tbd.website/projects/web5/) interoperability so people are no longer gated by what applications they can use with their data. Additionally, through the use of Distributed Data Networks, the single points of failures aggregators and third party services create will cease to exist. Traditional asymmetric cryptography will ensure data is secure and stops mass data theft. With [Decentralized Identifiers](/architecture/did) people can verify who they are communicating with on the web, and encryption with cyptographic signatures to chat. ## Zion Web5 Architecture The [Zion](https://www.zion.fyi/) Architecture is engineered on three new technologies that build a [Web5](https://developer.tbd.website/projects/web5/) Social Network with decentralized payments. **These technologies are:** [**Decentralized Identifiers**](/architecture/did)**:** A globally unique persistent identifier that does not require a centralized registration authority and is registered cryptographically. DIDs can be changed to accommodate different contexts, used to reinforce pseudonymity, or leverage port attributes between identities. This technology will solve many of the problems created by centralized internet services, from intermediary control of identity to unneeded surveillance at successive layers of the technology stack. [**Decentralized Web Nodes**](/architecture/decentralized-web-nodes)**:** Data storage and message relay nodes that serve as the foundation for decentralized apps and protocols [**Bitcoin Lightning**](/architecture/bitcoin-lightning-network)**:** a peer-to-peer payment network that leverages payment channels anchored on the Bitcoin blockchain to enable almost instantaneous transaction settlement between participants with almost no cost. Many such payment channels are chained together to deliver payments to anyone in the network without the need for trust in participants ## Zion App The Zion app is a peer-governed social network where members are the true owners of their data. Because of [Zion's Web5 Architecture](/architecture/overview) and [DWN](/architecture/decentralized-web-nodes)s, members own their data unlike normal applications that store your data centrally. **The Zion App has the following features:** [**Communities**](/social/zion-app/creator-communities)**:** Zion is about connecting with peers they share interest with. To do this Zion has created peer governed communities focused around topics that a person is interested in. Community rules can be enforced by user post staking and other anti-spam tools in communities. This means every post/comment/message that is a violation of community rules can penalize a user with a monetary fine. [**Messages**](/architecture/decentralized-web-nodes/messages)**:** Zion believes that people deserve privacy and security when conversing on the web. With Zion your messages are only viewable by you and the people you are conversing with. All messages are secured with your DID and stored on a DWN.\ \ [**Bitcoin Lightning Wallet**](/social/zion-app/lightning-wallet)**:** Every Zion account has an attached [Zion wallet ](/social/zion-app/lightning-wallet)that utilizes the [Bitcoin Lightning Network](/architecture/bitcoin-lightning-network). Wallets are used in all transactions while on the Zion app. # Overview Zion is a [Web5](https://developer.tbd.website/projects/web5/) Architecture built through the utilization of [DID](/architecture/did)s,[ DWN](/architecture/decentralized-web-nodes)s, and [Bitcoin Lightning](/architecture/bitcoin-lightning-network) Network. The [Zion Architecture ](/)paves the way for true interoperability of all data, and with the addition of decentralized financial payments developers can build almost any app and service. Data will no longer be bound to one network or service. DID owners can access other networks using their [DID](/architecture/did)s and [DWN](/architecture/decentralized-web-nodes)s while utilizing their [Lightning wallets](/architecture/bitcoin-lightning-network) for financial services. The first use case for the [Zion Architecture](/) is the [Zion App](broken://pages/1CquTU7hd2ZhZLs3OCD4). With the [Zion App](broken://pages/1CquTU7hd2ZhZLs3OCD4) members create a Zion account that consists of a [DID:ION](https://github.com/decentralized-identity/ion), access to our [DWN](/architecture/decentralized-web-nodes), and [Bitcoin Lightning](/architecture/bitcoin-lightning-network) wallet. Members can create and join communities, message, post, comment, and support creators by boosting posts with Satoshis. Additionally, the [Zion App ](broken://pages/1CquTU7hd2ZhZLs3OCD4)only acts as an aggregator only and is moderated by individual communities that create their own rules for self governance within their community.
# Decentralized Identifiers DIDs [Decentralized Identifiers](https://w3c.github.io/did-core/#dfn-decentralized-identifiers) are a new form of identifier that allows for verifiable and decentralized identities. Unlike federated identities, DIDs can operate without the need for centralized registries, identity providers, and certificate authorities. This allows people to verify without the need for a trusted third party. Zion utilizes the [DID:ION ](https://github.com/decentralized-identity/ion)method to act as a person's identifier, and contain cryptographic materials for the purpose of authentication and verification while on the Zion network. They are created when someone creates their Zion account. DIDs are a form of Self Sovereign Identity(SSI) which means that they are owned solely by individuals or entities that make them. Once created, only the owner of the DID can delete it. A DID can identify any subject (person, organization, data model, abstract entity, etc.) based on its controller, which has [DID document](#did-document) write-privileges. A [DID document](#did-document) specifies the syntax, common data mode, core properties, serialized representations, operations and an explanation of the DID resolution process. A DID is represented by a [Uniform Resource Identifier (URI) ](/architecture/did/did-universal-resource-identifier)for trusted interactions between a DID subject and a [DID document](#did-document). A DID is verified by associating a [DID document](#did-document) and [URI](/architecture/did/did-universal-resource-identifier), and can be universally resolvable with DID methods such as [DID:ION](https://github.com/decentralized-identity/ion) Method. **Example DID:** ```json { "@context": "https://w3id.org/did-resolution/v1", "didDocument": { "id": "did:ion:test:EiBYyFomj3igVP18KzzkpiKXq8BBScaITb5iX4byCJgWFg", "@context": [ "https://www.w3.org/ns/did/v1", { "@base": "did:ion:test:EiBYyFomj3igVP18KzzkpiKXq8BBScaITb5iX4byCJgWFg" } ], "service": [ { "id": "#zion_dwn", "type": "DecentralizedWebNode", "serviceEndpoint": { "nodes": [ "https://dwn.zion.fyi", ] } } ], "verificationMethod": [ { "id": "#key_d7124cf0", "controller": "did:ion:test:EiBYyFomj3igVP18KzzkpiKXq8BBScaITb5iX4byCJgWFg", "type": "JSONWebKey2020", "publicKeyJwk": { "crv": "secp256k1", "kty": "EC", "x": "SNE1sISNI4oI31Z-dj7khMhNF2XKCmsmPDlroyOXZdA", "y": "5IDbE7vkqR2YsPRBZ-HKH2vTwdE2Jf1zjvaxvyRrFLI" } } ], "authentication": [ "#key_d7124cf0" ], "assertionMethod": [ "#key_d7124cf0" ], "keyAgreement": [ "#key_d7124cf0" ] }, "didDocumentMetadata": { "method": { "published": true, "recoveryCommitment": "EiAuqEi0iNnp6XjLg5LhVnkBIBOIEbMwOPmEeQXRpClF4w", "updateCommitment": "EiBOjgm4WzIVKhbeU4PqhA4Oz-v81LxO3jWONK0OWCwVYw" }, "canonicalId": "did:ion:test:EiBYyFomj3igVP18KzzkpiKXq8BBScaITb5iX4byCJgWFg" } } ``` ## DID Document A DID document contains all information for a DID to be able to function. This includes authentication keys, service endpoints, short-name alias, free-form text, and other attributes as specified by the controller. Use cases can also be implemented with a protocol modification by updating a DID Document. ## Service Endpoints

DID Operations Flow

A [DID document ](#did-document)must include all metadata necessary for the respective service endpoint type. Service endpoints can be duplicated and hosted across multiple providers (URLs) for enhanced resilience. A controller can specify which service endpoint receives message information, either through code or configuration. \ See the W3C DID Specification Registries for a standardized list of service endpoints and supporting appropriate documentation: . # Sidetree [DID:ION](https://github.com/decentralized-identity/ion) leverages the blockchain-agnostic [Sidetree](https://identity.foundation/sidetree/spec/) protocol to anchor tens of thousands of DID/DPKI (Decentralized Public Key Infrastructure) operations into one single on-chain Bitcoin transaction. These transactions are encoded so [DID:ION](https://github.com/decentralized-identity/ion) nodes can fetch, store, and replicate hash-associated DID operation batches via IPFS (InterPlanetary File System). [DID:ION](https://github.com/decentralized-identity/ion) nodes process operations in batches that independently arrive at the corrected DPKI state for system IDs, without the need for consensus mechanisms, blockchain, or sidechain. Nodes can work in parallel to fetch, process, and assemble DIDs, allowing nodes to run tens of thousands of operations per seconds. This allows Zion to create a robust decentralize identifier network that does not require trusted intermediaries, centralized authorities, or secondary consensus mechanisms.
## Sidetree Network Topology

Sidetree Network Topology

**Bitcoin Ledger:** Global [anchoring ](https://identity.foundation/sidetree/spec/#anchoring-system)and linear sequencing system for DID operations **Sidetree nodes:** Nodes that interact with the [anchoring system](https://identity.foundation/sidetree/spec/#anchoring-system) to anchor operations, as well as fetch and replicate CAS network data. **Content Accessible Storage(CAS):** A IPFS Network that Sidetree nodes utilize to distribute and replicate DID operation files. # DID Universal Resource Identifier All DID Methods on sidetree share the same identifier format. The unique identifier segment is known as a [DID Suffix](https://identity.foundation/sidetree/spec/#did-suffix). This is derived from the initial state of the DID’s state data. Additionally, the [DID Suffix](https://identity.foundation/sidetree/spec/#did-suffix) is cryptographically bound to the initial PKI state of the DID, making sidetree DIDs self certifying. This enables a person who creates a DID knows their unique identifier at the moment of DID generation, and is secured cryptographically for instant use.\ \ The URI resolves to a [DID document](/architecture/did#did-document) based on the implementation of the specific DID method. This infrastructure could be a web server (similar threat model to current URL API calls), peer-to-peer discovery, anchor to the Bitcoin blockchain, IPFS or custom implementation devised by the controller. In our case we use DID:ION our implementation. ## Short Form URI Upon DID creation a short form DID URI is generated. Short-Form DID URI Format: ```json did:METHOD: ``` Short-Form DID URI Example: ```json did:ion:EiDahaOGH-liLLdDtTxEAdc8i-cfCz-WUcQdRJheMVNn3A ``` ## Long Form URI After DID generation there is an indeterminate period of time before DID operation is anchored, propagated, and processed by anchoring systems. To account for this, Sidetree generates a long-form DID URI that is an equivalent to Sidetree-based DIDs that is both self-certifying and self resolving. This allows DIDs to be immediately resolvable by including the DIDs initial state data within long-form DID URI. Long form DID URI are the same as short for DID URI with an additional colon-separated segment appended at the end. This segment is a JSON data payload that contains information required for DID operation.This JSON data is encoded and added after the [DID Suffix](https://identity.foundation/sidetree/spec/#did-suffix). Long-Form URI JSON Payload data ```json { "delta": { "patches": [ { "action": "replace", "document": { "publicKeys": [ { "id": "anySigningKeyId", "publicKeyJwk": { "crv": "secp256k1", "kty": "EC", "x": "H61vqAm_-TC3OrFSqPrEfSfg422NR8QHPqr0mLx64DM", "y": "s0WnWY87JriBjbyoY3FdUmifK7JJRLR65GtPthXeyuc" }, "purposes": [ "auth" ], "type": "EcdsaSecp256k1VerificationKey2019" } ], "services": [ { "id": "anyServiceEndpointId", "type": "anyType", "serviceEndpoint": "http://any.endpoint" } ] } } ], "updateCommitment": "EiBMWE2JFaFipPdthcFiQek-SXTMi5IWIFXAN8hKFCyLJw" }, "suffixData": { "deltaHash": "EiBP6gAOxx3YOL8PZPZG3medFgdqWSDayVX3u1W2f-IPEQ", "recoveryCommitment": "EiBg8oqvU0Zq_H5BoqmWf0IrhetQ91wXc5fDPpIjB9wW5w" } } ``` Format of Long-Form DID URI: ```json did:METHOD:: ``` Example of Long-Form DID URI: {% code overflow="wrap" %} ```json did:ion:EiAnKD8-jfdd0MDcZUjAbRgaThBrMxPTFOxcnfJhI7Ukaw:eyJkZWx0YSI6eyJwYXRjaGVzIjpbeyJhY3Rpb24iOiJyZXBsYWNlIiwiZG9jdW1lbnQiOnsicHVibGljS2V5cyI6W3siaWQiOiJzaWdfNzJiZDE2ZDYiLCJwdWJsaWNLZXlKd2siOnsiY3J2Ijoic2VjcDI1NmsxIiwia3R5IjoiRUMiLCJ4IjoiS2JfMnVOR3Nyd1VOdkh2YUNOckRGdW14VXlQTWZZd3kxNEpZZmphQUhmayIsInkiOiJhSFNDZDVEOFh0RUxvSXBpN1A5eDV1cXBpeEVxNmJDenQ0QldvUVk1UUFRIn0sInB1cnBvc2VzIjpbImF1dGhlbnRpY2F0aW9uIiwiYXNzZXJ0aW9uTWV0aG9kIl0sInR5cGUiOiJFY2RzYVNlY3AyNTZrMVZlcmlmaWNhdGlvbktleTIwMTkifV0sInNlcnZpY2VzIjpbeyJpZCI6ImxpbmtlZGRvbWFpbnMiLCJzZXJ2aWNlRW5kcG9pbnQiOnsib3JpZ2lucyI6WyJodHRwczovL3d3dy52Y3NhdG9zaGkuY29tLyJdfSwidHlwZSI6IkxpbmtlZERvbWFpbnMifV19fV0sInVwZGF0ZUNvbW1pdG1lbnQiOiJFaUR4SWxJak9xQk5NTGZjdzZndWpHNEdFVDM3UjBIRWM2Z20xclNZTjlMOF9RIn0sInN1ZmZpeERhdGEiOnsiZGVsdGFIYXNoIjoiRWlBLXV3TWo3RVFheURmWTRJS3pfSE9LdmJZQ05td19Tb1lhUmhOcWhFSWhudyIsInJlY292ZXJ5Q29tbWl0bWVudCI6IkVpQ0czQ1M5RFJpeU1JRVoxRl9sSjZnRVRMZWVHREwzZnpuQUViMVRGdFZXNEEifX0#sig_72bd16 ``` {% endcode %} Long-Form DID URIs support the follow features: * Resolving DID Documents of unpublished DIDs * Authentication of unpublished DIDs * Verification of credentials signed against unpublished DIDs # DID Operations All Sidtree-based DID operations require DID owners to generate specific data values and cryptographic material. These operations are: * Create: Used to generate a side tree based DID. [More information](https://identity.foundation/sidetree/spec/#create) * Update: Used to update the state of a DID. [More information](https://identity.foundation/sidetree/spec/#update) * Recover: Used to recover a DID. [More information](https://identity.foundation/sidetree/spec/#recover) * Deactivate: Used to deactivate a DID. [More information](https://identity.foundation/sidetree/spec/#recover) ## **Signing** Sidetree relies on JSON Web signatures(JWS)( [RFC7515](https://tools.ietf.org/html/rfc7515)) for authentication and integrity protections of all DID operations, except with create operations which contain key material and are self certifying. More information on key singing can be found [here](https://identity.foundation/sidetree/spec/#signing). ## Verification Sidetree operations are only valid when the JWS can be verified with the correct key pair for the type of operation that is invoked(with the exception of the create operation). These operations and associated key pairs keys are: * [Update:](https://identity.foundation/sidetree/spec/#update) must be signed by a valid Update Key Pair. * [Recovery](https://identity.foundation/sidetree/spec/#recover): must be signed by a valid Recovery Key Pair. * [Deactivate](https://identity.foundation/sidetree/spec/#deactivate): must be signed by a valid Recovery Key Pair.
# Verifiable Credentials The one drawback to fully decentralized verification system like DIDs is that it lacks the security that centralized can bring verification brings. To solve this, [Verifiable Credentials](https://www.w3.org/TR/vc-data-model/)(VC) will be added to DIDs. Credentials are part of every person's daily life in society. We use credentials such as driver's licenses to show we are legally able to operate a motor vehicle, and for identification purposes when register to vote, fly domestically, and when signing up for Know Your Customer(KYC) verification services. Credentials also used for various membership cards for government services like community pool passes, library cards, and fishing permits. These credentials provide a way for people in society to verify who someone is and to ensure they have the proper authority to do something [Verified Credentials](https://www.w3.org/TR/vc-data-model/) are digital credentials that act as digital counterparts to physical credentials. They store all data digitally that a normal credential would. #### Example Credential information * Personal Identifying Information(photo, name, DOB, physical attributes) * The Issuing Authority(governmental body, organization, company, etc) * Credential Type(Goverment issued licenses, passport, library card, etc) * Unique Identifier(license ID, employee ID, SSN, etc) * Evidence to how this credential was derived * Credential restraints(expiration date, credential uses and restrictions) VCs can contain additional data for technologies that can digital sign VCs and that can also enable safeguards against fraudulent credentials. Also, Unlike normal credentials, VCs can be transmitted rapidly allowing for instant use across the web. ## How Do VCs authenticate

VC authorization flow

[**Holder**](https://www.w3.org/TR/vc-data-model/#dfn-holders): A role an entity may take when processing one or more VC and when generating a [verifiable presentation](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations). [**Issuer**](https://www.w3.org/TR/vc-data-model/#dfn-issuers): An entity that transmits VCs to a holder. Examples: government bodies, corporations, member clubs, and more. [**Subject**](https://www.w3.org/TR/vc-data-model/#dfn-subjects)**:** An entity a claim(a request for a VC) is made about. In most cases the Holder is also the Subject, however in some cases a holder may hold VCs for other subjects. An example of this would be a parent holding VCs representing their children's passports or SSNs. [**Verifier**](https://www.w3.org/TR/vc-data-model/#dfn-verifier): An entity requesting the processing of a VC. Examples: TSA agents at airports, employers, security personal, and online services. [**Verifiable Data Registry**](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-data-registries)**:** A system responsible for the creation and verifications of all VC related data. Registries can provide any data need to process VCs and create [verifiable presentations](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations). [**Verifiable Presentations**](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations)**:** A tamper-evident presentation that is encoded so the authorship of the data can be verified cryptographically. Not all Verifiable Presentaions will include all data from VCs, but may choose to include data derived from VCs. # Decentralized Web Nodes Most activities online between two entities require the exchange of messages and data. To make these exchanges, entities require an interface to store, discover, and fetch data related to the action an entity is participating in. A [Decentralized Web Node](https://github.com/TBD54566975/dwn-sdk-js) (DWN) is a data storage and message relay mechanism entities can use to locate public or private permissioned data related to a given [Decentralized Identifier (DID)](/architecture/did). Decentralized Web Nodes are a mesh-like datastore construction that enable an entity to operate multiple nodes that sync to the same state across one another, enabling the owning entity to secure, manage, and transact their data with others without reliance on location or provider-specific infrastructure, interfaces, or routing mechanisms. This allows anyone to build on the [Zion](https://github.com/getzion) architecture, and utilize an entity's DWN for their applications and services. Almost any form of data can be stored on a DWN. Zion DWNs currently store data in the form of the following schemas (more to be added in the future): * [COMMUNITY](https://github.com/getZION/whitepaper-documents/blob/master/schemas/COMMUNITY.md) * [PERSON](https://github.com/getZION/whitepaper-documents/blob/master/schemas/PERSON.md) * [POST](https://github.com/getZION/whitepaper-documents/blob/master/schemas/POST.md) * [COMMENT](https://github.com/getZION/whitepaper-documents/blob/master/schemas/COMMENT.md) * [USER INTERACTION](https://github.com/getZION/whitepaper-documents/blob/master/schemas/USERINTERACTION.md) * [IMAGE](https://github.com/getZION/whitepaper-documents/blob/master/schemas/IMAGE.md) * [VIDEO](https://github.com/getZION/whitepaper-documents/blob/master/schemas/VIDEO.md) * [DATETIME](https://github.com/getZION/whitepaper-documents/blob/master/schemas/DATETIME.md) All this data is stored locally on an entity’s personal devices and in remote locations Multi Master Replicas, which are highly available. Owners of a DWN choose what information is public or private. Permission access is resolved through DID authentication and object capabilities, which can only be given by the DWN owner. This new form of data storage creates true ownership of one’s data and removes the single points of failure caused by centralized storage of data. Additionally, data on a DWN can only be edited or deleted by the DWN owner and those they give access to. # Messages All data requests in a DWN are made in Message JSON objects. These messages contain all data required to process a request in a DWN network including execution parameters, signing/encryption information, signatures, and authorization material. Messages can be modified or changed to fit the needs of a developer provided the data stored follows the Message Object’s format and has an accompanied Schema to store the data. #### Basic Message Object(Without Signing or Authorization) ```json { // Request Object "messages": [ // Message Objects { "recordId": GENERATED_CID_STRING, "data": BASE64URL_STRING, "descriptor": { "method": INTERFACE_METHOD_STRING, "dataCid": DATA_CID_STRING, "dataFormat": DATA_FORMAT_STRING, }, "processing": { "nonce": "4572616e48616d6d65724c61686176", "author": "did:example:alice", "recipient": "did:example:bob", } }, {...} ] } ``` In order to enable data replication features for a DWN, all data listed above must be included in a Message Object. More information on the specific formatting of Message Objects can be found [here](https://identity.foundation/decentralized-web-node/spec/#messages). ### Signed Data If the Message is to be attested by the signer(the owner of the Node) then it must be formatting as the following: ```json { // Message "data": {...}, "recordId": "b65b7r8n7bewv5w6eb7r8n7t78yj7hbevsv567n8r77bv65b7e6vwvd67b6", "descriptor": { "method": "CollectionsWrite", "schema": "https://schema.org/InviteAction", "dataCid": CID(data), "dateCreated": 123456789, "dataFormat": "application/json" }, "processing": { "nonce": "4572616e48616d6d65724c61686176", "author": "did:example:alice", "recipient": "did:example:bob", }, "attestation": { "payload": "89f5hw458fhw958fq094j9jdq0943j58jfq09j49j40f5qj30jf", "signatures": [{ "protected": "4d093qj5h3f9j204fq8h5398hf9j24f5q9h83402048h453q", "signature": "49jq984h97qh3a49j98cq5h38j09jq9853h409jjq09h5q9j4" }] } ... } ``` This object must include an attestation property that contains a signature and payload. More information on this object’s formatting can be found [here](https://identity.foundation/decentralized-web-node/spec/#signed-data) ### Authorization Messages may require authorization if the DWN owner set permissions to require it. A message must include an authorization property that is a JSON Web Signature(JWS) if it requires authorization. It's format is as follows: ```json { // Request Object "messages": [ // Message Objects "data": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi", "recordId": "b65b7r8n7bewv5w6eb7r8n7t78yj7hbevsv567n8r77bv65b7e6vwvd67b6", "descriptor": { "method": "CollectionsWrite", "schema": "https://schema.org/SocialMediaPosting", "dataCid": CID(data), "dateCreated": 123456789, "dataFormat": "application/json" }, "processing": { "nonce": "4572616e48616d6d65724c61686176", "author": "did:example:alice", "recipient": "did:example:bob", }, "attestation": { "payload": "89f5hw458fhw958fq094j9jdq0943j58jfq09j49j40f5qj30jf", "signatures": [{ "protected": "4d093qj5h3f9j204fq8h5398hf9j24f5q9h83402048h453q", "signature": "49jq984h97qh3a49j98cq5h38j09jq9853h409jjq09h5q9j4" }] }, "authorization": { "payload": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi", "signatures": [{ "protected": "f454w56e57r68jrhe56gw45gw35w65w4f5i54c85j84wh5jj8h5", "signature": "5678nr67e56g45wf546786n9t78r67e45657bern797t8r6e5" }] } }, {...} ] } ``` Unlike the basic Message Object, the authorization property includes payload and signature data in order to properly process a Message. More information on this object’s formatting can be found [here](https://identity.foundation/decentralized-web-node/spec/#message-authorization). ### Encrypted Data All encrypted Messages must include the following: ```json { // Message "data": { "protected": ..., "recipients": ..., "ciphertext": ..., "iv": ..., "tag": ... }, "recordId": "b65b7r8n7bewv5w6eb7r8n7t78yj7hbevsv567n8r77bv65b7e6vwvd67b6", "descriptor": { "method": "CollectionsQuery", "schema": "https://schema.org/SocialMediaPosting" }, "processing": { "nonce": "4572616e48616d6d65724c61686176", "author": "did:example:alice", "recipient": "did:example:bob", } ... } ``` The additional information under "data" is used for message encryption and utilizes JSON Web Encryption. More information on message encryption can be found [here](https://identity.foundation/decentralized-web-node/spec/#encrypted-data) # DWN Requests

Zion Aggregator Framework

In the Zion Aggregator, [DWN](/architecture/decentralized-web-nodes)s feed messages that the user designates through the use of handlers. Data that meets certain conditions set by the user and aggregator is sent to the aggregator for indexing, and unlike traditional aggregators, permission for data can be revoked by [DWN ](/architecture/decentralized-web-nodes)owners at any time thus removing the aggregator's access to that data. Currently Zion [DWN](/architecture/decentralized-web-nodes)s have three types of requests. These requests are formatted as Messages. Currently, Zion DWNs utilize three types of Messages: CollectionsWrite, CollectionsCommit and CollectionsDelete. ### CollectionsWrite CollectionWrite requests are for posting a new item in a collection. The format for a CollectionsWrite request is: ```json { // Request Object "target": "did:zion:123",// Community DID "messages": [ // Message Objects { "data": { "image": "...", "text": "Some stuff I ate for lunch", ... }, // Base64URL String Representation of this object "descriptor": { "nonce": "9b9c7f1fcabfc471ee2682890b58a427ba2c8db59ddf3c2d5ad16ccc84bb3106", "method": "CollectionsWrite", "recordId": "b6464162-84af-4aab-aff5-f1f8438dfc1e", // the record ID you are creating "dataCid": "", //CID V1 of the data field "dataFormat": "application/json", "dateCreated": 123456789, "schema": "https://schema.org/SocialMediaPosting", // Can be a key for a hardcoded custom ZION schema "protocol": "zion.fyi/social-protocol/v1" }, "attestation": { "protected": { "alg": "ES256K", "kid": "did:example:123#key-1" }, "payload": "", // CID V1 of the descriptor, "signature": "" //JWS of (protected + payload) } // JWS Compact Object string }, ] } ``` ### CollectionsCommit CollectionsCommit requests are for updating an existing item in a collection. This will effectively replace that item. The format for a CollectionsCommit request is: ```json { // Request Object "target": "did:zion:123",// Community DID "messages": [ // Message Objects { "data": { "image": "...", "text": "Some stuff I ate for lunch, and a snack", ... }, // Base64URL String Representation of this object "descriptor": { "nonce": "9b9c7f1fcabfc471ee2682890b58a427ba2c8db59ddf3c2d5ad16ccc84bb3106", "method": "CollectionsCommit", "recordId": "b6464162-84af-4aab-aff5-f1f8438dfc1e", // ID for the record looking to update "dataCid": "", //CID V1 of the data field "dataFormat": "application/json", "dateCreated": 123456789, // Should be the time of the original creation "datePublished": 123456789, // Should be now "schema": "https://schema.org/SocialMediaPosting", // Can be a key for a hardcoded custom ZION schema "protocol": "zion.fyi/social-protocol/v1" }, "attestation": { "protected": { "alg": "ES256K", "kid": "did:example:123#key-1" }, "payload": "", // CID V1 of the descriptor, "signature": "" //JWS of (protected + payload) } // JWS Compact Object string }, ] } ``` ### CollectionsDelete CollectionsDelete requests are for removing an item of a collection. Once deleted an item will be unrecoverable. The format for a CollectionsDelete request is: ```json { // Request Object "target": "did:zion:123",// Community DID "messages": [ // Message Objects { "descriptor": { "nonce": "9b9c7f1fcabfc471ee2682890b58a427ba2c8db59ddf3c2d5ad16ccc84bb3106", "method": "CollectionsDelete", "recordId": "b6464162-84af-4aab-aff5-f1f8438dfc1e", // the record for deletion "schema": "https://schema.org/SocialMediaPosting", // Can be a key for a hardcoded custom ZION schema "protocol": "zion.fyi/social-protocol/v1" }, "attestation": { "protected": { "alg": "ES256K", "kid": "did:example:123#key-1" }, "payload": "", // CID V1 of the descriptor, "signature": "" //JWS of (protected + payload) } // JWS Compact Object string }, ] } ``` # Bitcoin Lightning Network The[ Bitcoin Lightning Network](https://docs.lightning.engineering/the-lightning-network/overview) is a peer-to-peer payment network that leverages payment channels anchored on the Bitcoin blockchain to enable near instant settlement of Bitcoin between participants at a low cost. Multiple such payment channels are chained together to deliver payments to anyone in the network without requiring trust in participants. ## Invoices The Lightning Network uses invoices instead of addresses. Invoices are generated by the recipient. Each invoice includes a specified amount, time of expiration, the destination public key, as well as any other data required. Invoices can be canceled by the recipient at any time before the invoice is filled. Lighting invoices us the [BOLT(Basis of Lightning Technology) 11](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md) QR-code-ready protocol. BOLT specifications are required to enable separate implementations to function and interact with each other within the same network. These specifications allow any client or tool to be able to understand any Lightning invoice created, regardless of the creator. Each Lightning invoice includes an amount, expiration time, destination public key, supported features and other data as needed. [More information on Lightning Invoice specifications](https://docs.lightning.engineering/the-lightning-network/payment-lifecycle/understanding-lightning-invoices). ## **Payments(HTLC)** All payments utilize Hash Time-lock Contracts(HTLC), an output of an unconfirmed transaction to a “smart contract”. HTLCs can be settled by revealing a preimage as defined by it's hash. All payments along the HTLC route are made to this hash, and can be claimed only when the preimage is revealed. If the preimage is not revealed, the payment is sent back to the sender. Although HTLCs can be settled on blockchain, they are generally resolved off-chain between peers. When an Lightning transaction is initiated the receiver must first send a random number that has been hashed to the sender. For example, If Alice wants to create a contract with Dave to send funds, Dave must generate a random number R, and hash it thus creating number H. Then Dave sends H. Alice then creates a conditional payment to Bob(a node she is connected to) that is completed if he can produce the preImage of H if he does within a 3 days(in this example). If that time period passes only Alice would be able to redeem the payment. This ensures Alice can redeem the funds if Bob never finds out what R is. However, this transaction is not broadcasted on chain because they expect it to clear out.

Lightning Payment Channels

In order to create a payment to Dave, Bob routes a transaction through Carol, who is associated with Dave. In this transaction Dave agrees to pay Carol if she can produce the preimage of H.

First Attomic Swap

Once this happens Carol can send R to Bob who in turn sends it to Alice, settling all transactions. If any member of the chain is uncooperative, the transaction between the uncooperative person would be broadcasted on chain and R could then be recovered by looking at the on-chain transaction. This allows the rest of the payment channel to settle off-chain.

All Transactions settle once R is sent along the payment route

# Taro [Taro](https://docs.lightning.engineering/the-lightning-network/taro) is a protocol for issuing assets on the Bitcoin blockchain. These assets can be fungible assets such as stablecoins, Non-Fungible Tokens(NFTs), and other collectable assets. With the utilization of the Lightning network, Taro can transfer these assets with atomic transactions fast and at a low cost.\ \ To store assets, Taro utilizes taproot to store hashed data on Bitcoin blockchain transactions. While storing this data on the blockchain could be expensive, Taro uses Lightning [HTLC](broken://pages/IWILjc4NpxlycMNEuoam) to keep costs low.

Taro Transaction on Lightning

### Non Fungible Assets Non Fungible Assets are issued on a single on-chain transaction. Ownership transfer is done off chain by transferring the unique Identifier and a verification file containing transaction history data for authentication. This information is stored in Taro Asset Universes which are similar to Bitcoin Block explorers and can be run by any interested party in an asset. ### Assets/Stablecoins Because assets can be split and merged, any Taro asset owner can change ownership inside an existing user group that has assets in the same Merkle tree, or a different one. ### Multi-Hop Taro Transfers Taro create a payment routing method that enables Lightning Network channels to utilize taro assets when building payment channels. Payment routes with multiple assets can occur provided that the nodes opt into receiving taro assets while agreeing to forward the Taro value in Satoshi when creating new channels.

Lightning transaction with Taro asset

Taro also allows for Taro assets to be transferred via the Lightning Network without the need for other Lightning nodes to opt into Taro, maintaining the standard Lightning [invoice](broken://pages/lKk5LnB3Vn7QDPClopCy) scheme.

Taro Asset exchange on the Lightning Network

### Asset Exchange Taro asset exchange rates are determined by peers in a lightning invoice. Rates can be determined through markets or individually. Any Lightning node can act as an edge node, competing with other nodes over fees collected during forwards and swaps. These fees include routing and swap fees, or a spread. When creating an invoice to exchange Taro assets, The recipient and peer agree on an exchange rate before generating an invoice. They use the agreed upon price to generate a[ Lightning invoice](/architecture/bitcoin-lightning-network#invoices). Once an invoice is created a payment channel is made through the BTC Lightning Network. Once the recipient acknowledges it has received the agree upon asset amount(ex. L-EUR), they will release the preimage.

Multi-asset Taro asset exchange on the Lightning Network

# Zion App The Zion App is an application built on [Web5](https://developer.tbd.website/projects/web5/) Architecture that facilitates transparent and direct flow of content and payments between creators and their audiences. With Zion, you can post and share content, boost posts to support your favorite creators, and message with other Zion Members. Additionally, Zion sidesteps corporate profit motives and empowers every user with full sovereignty and irrevocable custody of their personal information and data. This creates a network free of targeted ads, centralized moderation, and arbitrary censorship. ## Zion Aggregator Framework The Zion Application functions through the utilization of [TBD Web5](https://developer.tbd.website/projects/web5/) Architecture and Bitcoin [Lightning](https://lightning.engineering/) Network. With this technology Zion members can post, message, and transact on the Zion App.

Zion Client Framework

The Zion Application enables the use of [DWN](/architecture/decentralized-web-nodes)s to store posts and messages securely, and in a way that prevents aggregators from deleting data from a [DWN](/architecture/decentralized-web-nodes) without the owner's permission. The Zion protocol is able to use [Message](/architecture/decentralized-web-nodes/messages) requests to interact with [DWN](/architecture/decentralized-web-nodes/dwn-requests) data. \ \ Once [DWN](/architecture/decentralized-web-nodes) data is given permission to be used as defined by the [DWN](/architecture/decentralized-web-nodes) owner and is verified with [DID](/architecture/did) verification it can be used by the Zion Aggregator. Data is then stored and indexed in a database like a normal data aggregator for use in the Zion App. For payments, all in app transactions utilizes Zion lightning payments with a Zion Ledger that stores all in app transaction data. When funds are removed off Zion through a Bitcoin Lightning Network transaction, the Zion App contacts an entities DWN to pay a lightning invoice. # DID Account Creation When members create a [Zion](https://www.zion.fyi/) account, members generate their [DID:ION](/architecture/did), [DWN](/architecture/decentralized-web-nodes/dwn-requests), and [Bitcoin Lightning Wallet](/architecture/bitcoin-lightning-network). To create an account: 1. Open [Zion](https://www.zion.fyi/) App and click create account 2. Record 12 word BIP39 generated recovery phrase. This is your [DID:ION](/architecture/did) Recovery Key Pair. (Note: Accounts can only be recovered with the recovery phrase. Zion is not responsible for lost recovery keys) 3. Input the recovery phrase correctly into the input screen to ensure it was recorded correctly 4. Input an email to attach to the Zion account (optional) 5. Input an alphanumeric passcode for the Zion app 6. Fill out the account creation page with a display name, username, profile picture, and bio Once members are finished they will be given full access to the Zion app and [lightning wallet](/social/zion-app/lightning-wallet).

# Social Profiles Each Zion account has an associated profile page. Profile pages include: * Public [post](/social/zion-app/community-posts) feed of Zion account * Follower/following list * Conversation count * List of joined [communities](/social/zion-app/creator-communities) While a member is viewing their own profile they can do the following: * Add and remove followers and following * Edit profile picture, bio, and display name * Change username * Leave communities * Create or delete posts
# Lightning Wallet Every Zion account includes a Zion wallet that utilizes [Lightning](/architecture/bitcoin-lightning-network) payments to ensure near instant payments for virtually no cost. ### Adding Funds To add funds to a Zion [Lightning](/architecture/bitcoin-lightning-network) wallet: 1. Click fund/request on the lightning wallet splash page 2. Decide the amount of SATS to add and click continue 3. Copy the generated [Lightning Invoice ](/architecture/bitcoin-lightning-network#invoices)and pay it with your favorite Lightning wallet or Lightning supporting exchange As mentioned earlier, through the utilization of [Taro](/architecture/bitcoin-lightning-network/taro), Zion wallets will eventually be able to store and send [NFTs](/architecture/bitcoin-lightning-network/taro#non-fungible-assets), [stablecoins](/architecture/bitcoin-lightning-network/taro#assets-stablecoins), and other [assets](/architecture/bitcoin-lightning-network/taro#assets-stablecoins). ### Sending Funds To send funds to another wallet: 1. Click send on the [Lightning](/architecture/bitcoin-lightning-network) wallet splash page 2. Use a camera to scan a invoice QR code or manually input the desired invoice address 3. Click send. If the amount requested in the invoice is not available, an error message will appear

# Creator Communities Communities are hubs for creator expression and also the center of the Zion Network. Anyone can create a community where they define the community’s purpose and they set the rules for posting. ### Community Features: * **Community Feed:** A feed of all community posts. Only community members can see and comment on posts. * **OpenChat:** A chat that is accessible by community members only and is encrypted via DID verification.
### Community Monetization Owners who would like their members to have a vested interest in their community can turn on community payment features. These features allow community owners to monetize from community management while also adding safeguards from malicious actors and bots. These features are: * **Membership Fee:** One time membership fee for all community members when joining the community. This is not refundable if a member is kicked or leaves * **Posting Fee:** A non-refundable fee for creating a post in a community feed. This makes members choose what content they feel is important enough to invest in a post creation. * **Staking Fee:** A refundable fee for posting content. This is a tool to prevent spam posts and malicious members from using sock puppets and bot accounts. Staking fees are kept for up to 8 hours and returned if the post is not taken down by community admins. Members who's posts that are penalized for breaking the rules will not be returned their staking fee. **Omni-Directional Payments:** \ Micropayments can move seamlessly through bi-directional payment channels: * **Audience to Creator:** Securely pay to see exclusive, premium, or unreleased content, send tips and directly support a creator’s career * **Audience to Audience:** Boost top comments and reward valuable contributions from fellow users * **Creator to Audience:** Release new content and facilitate meaningful engagement by rewarding fans’ contributions to the community # Community Posts With the Zion Client you can make posts on your personal feed or in a community. Posts can contain the following data: * Rich text * Pictures * Videos * Embed links All messages are signed using your [DID](/architecture/did) when posted.
### Boosting If a Zion member likes a post from a creator, they can boost it which gives the post's creator SATS. Members decide how many SATS they want to give when boosting.
# Why Web5? With the utilization of [TBD's Web5](https://developer.tbd.website/projects/web5/) Platform, entities on the internet will be able to interact with others online without the need for trusted third parties. Without aggregators like Zion, [DWN](/architecture/decentralized-web-nodes)s can still communicate with each other using [DID](/architecture/did) for verification. This means data from a [DWN](/architecture/decentralized-web-nodes) is still accessible even if certain services are down. It also allows for people to transfer data and create their own contracts without the need for a service to act as a middle man thanks to [Lightning](/architecture/bitcoin-lightning-network) payments and [DID ](/architecture/did)verification. As shown above, with the use of the Zion [DID:ION](https://github.com/decentralized-identity/ion) resolver (Or any [DID:ION](https://github.com/decentralized-identity/ion) resolver) for verification, [DWN](/architecture/decentralized-web-nodes)s can send [messages](/architecture/decentralized-web-nodes/messages) independently of any aggregator. This ends a prevalent problem in the digital age where businesses who rely on internet services to function are often forced to shut down when the services they use stop functioning. Since [DWN](/architecture/decentralized-web-nodes)s are stored locally and in Master Replicas, entities can now to continue to function and have access to their data even if a service they use stops functioning.\ \ In addition, because of [DID](/architecture/decentralized-web-nodes) verification and decentralized storage, data has never been more secure. Data is no longer stored in a centralized cloud meaning an end to admin accounts with backdoor privileges into a user's data. This not only prevents the deletion of data from a centralized authority on a network, but it also prevents hackers from using exploits to gain access to all data on a network

Alice and Bob communicating on Web5

## Building on Web5 Almost any web application or service can be built utilizing [TBD's Web5 Decentralized Platform](https://developer.tbd.website/projects/web5/) for data storage, messaging, and verification. By adding decentralized payments with the [Bitcoin Lightning Network ](/architecture/bitcoin-lightning-network)the possibilities become endless. These are the pillars of the [Zion Architecture](/architecture/overview)

Zion Web5 Pillars

In a Web5 future, almost all web services will utilize these features. With the use of [DID:ION](https://github.com/decentralized-identity/ion) verification there will no longer be a need for creating accounts on centralized networks to use services. Thanks to [DWN](/architecture/decentralized-web-nodes) technology, any entity will be able to use their data in a variety of applications and services while still maintaining ownership. Additionally, the use of [Bitcoin Lightning](/architecture/bitcoin-lightning-network) enables developers to create financial based services on Web5. This means everything from social media to even going on a vacation utilizing [Zion’s Web 5 Architecture](/).

Plan Trip with Web5 Platform

**Thank you to the following contributors that helped bring this document together:** [Liran Cohen](https://twitter.com/itsLIRAN), [Daniel Buchner](https://twitter.com/csuwildcat), [Ryan Gentry](https://twitter.com/RyanTheGentry), [Justin Rezvani](https://twitter.com/justinrezvani), [Eric Ziouane](https://twitter.com/noFiatLeft), Jason Charter, Evgen Scherbina, # Future Thoughts Zion's vision is to be the **primary payment processor** for the rapidly-expanding **creator economy** by utilizing [Bitcoin Lightning Payment](/architecture/bitcoin-lightning-network)s on social networks. Why are social networks like Facebook, Instagram and Twitter free to use? Because *users* are the product. More specifically, the “products” that social media companies deliver to their customers (advertisers) are as much data as they can collect from a user(shopping habits, hobbies, personal identifying information, and other metadata) Capitalizing on their role as gatekeepers of digital content, social media companies harvest and large stores of user data. Bought and sold as a commodity, this personal information calibrates algorithms that manipulate what users see, buy and interact online. These algorithms are undetected: they’re deceptive, sneaky, and pinpointed, secluding users in echo chambers that misinform, polarize and sow discord across society. Tasked with the daunting responsibility of moderating content posted by billions of users, social media companies have asserted themselves as the de facto “arbiters of truth” online. On the pretext of protection, their “Trust & Safety” departments act with impunity to censor dissenting voices. Public opinion of social media companies has deteriorated as the abuse of their power has become clearer in recent years. Unfortunately, there’s not much that individuals can do: fully participating in online discourse requires the use of digital infrastructure controlled by a handful of internet oligarchs. These data-rich companies that enjoy an ['advantageous feedback loop'](https://www.businessinsider.com/facebook-google-personal-data-privacy-congress-house-antitrust-report-2020-10) that continuously entrenches their monopolies. As a social networking platform built on [Web5](/interoperability/why-web5), Zion is meaningfully positioned to push the bounds of “social media.” We believe the future of online communication is: * **Peer-to-Peer:** Direct transactions between peers are transparent, simple and efficient. * **Built on Digital Money:** Digital communication and commerce infrastructure are equally critical to a modern, functioning society. It only makes sense that the next generation of social networks are built on the most secure, censorship-resistant and antifragile foundation available. * **Incentivizes Creation + Value-Additive Consumption:** Financial rewards encourage creativity and originality. There’s no way for creators to promote their content, and users only see what they opt into. Because there is no way to fake engagement, users are incentivized to create content that others actually want to see. ## Open Source Zion will open source license the relay code base. Open source software, led and driven by community requirements is often closer to the needs of the individuals and entities using it. Users of open source software have the freedom to make modifications to suit their requirements more closely. Contributing these modifications back to the community allows them to be adopted - and maintained - by the community of support, rather than remaining a burden on the developer. * **Bug-fixing** When bugs are identified in commercial proprietary software, there's nothing to do but wait for the original developers to fix them. Furthermore, commercial vendors are often driven by sales to prioritize new features rather than fixing existing problems. * **Open source software is different.** Once a bug is identified, anyone with the expertise and resources can provide a fix. * **Reliability and Elegance** Open source software is peer reviewed by merit-based open source communities, leading to greater reliability. Peer review and peer pressure in open source communities often leads to reduction in the complexity of code, making it easier to maintain. Elegance is not as obviously an objective of commercial proprietary code. * **Stability** Users of proprietary software often face a tension between the day to day needs of their business, and their vendor's need to develop a regular revenue stream. Often this tension is expressed in the provision of unsought-for upgrades. The tension -termed vendor push - effectively requires the user of proprietary software to fit their IT strategy to the financial needs of their supplier. The history of the software industry shows a tendency to develop near-monopolies which then act to force upgrades onto users - producing high profits but less user satisfaction. A user that resists an upgrade will eventually find they are using unsupported software. Open source communities take a different approach, often offering support for two or more recent versions of software. Such communities proceed at their own pace in a more collaborative manner. * **Security** - Anyone can view the source code of open source software, as the name suggests. In addition to the early identification of general defects, this enables the identification and remediation of defects specifically impacting security. Community driven peer review and openness trump "security by obscurity". * **Audit-ability and Privacy** - Audit-ability is of growing importance in a world increasingly concerned not only with security, but also the privacy of users data. Open source code allows for external audit of software - ensuring compliance with software standards and legal requirements. Proprietary software essentially asks for a leap of faith. # FAQs **Why is it called Zion?** \ Zion is often used to share a peaceful ideal place for society, it stands for a utopian place of unity, peace and freedom. For the Matrix fans, it is also the last city NOT controlled by machines, the last remaining human city. We thought it fitting for what we have built. **Why is Zion built on Lightning, instead of another blockchain?** \ The innovation of the Lightning Network is the use of time­-locked transactions and cryptographic nonces to allow many two ­party payment channels to form a connected network where payments can be sent over many channels without trusting the intermediate nodes. The topology is similar to IP networks (the internet): packets of information are routed over many physical links, and the communicating end nodes don't worry about the route as long as data gets to the destination. This works via a decrementing time­ lock that permits every intermediate node along the routing path to accept funds only if they forward it along to the next participant, using disclosure of pre images of cryptographic hashes. In the Lightning Network, nodes are not able to seize funds traveling through their channels even if they fail to forward payments or refuse to perform any actions. A node operates without custody of third party funds, which is enforced by a time­ limited cryptographic script. Zion uses these same cryptographic functions to move data across the same packet layers. **What is staking for Anti-Spam?** \ If a creator has staking turned on for the community, when you make a comment inside the community a certain amount SATS, which is outlined in the stake contract when you join the community, will be held in escrow. If the creator of the community deems your comment Spam they will delete the comment from the thread and you will lose your stake. If you comment stays on the community page for the duration of the staking contract you funds will be returned. This is how we use SATS to prevent spam. **What is the Lightning Network, and what does it have to do with Bitcoin?** \ Bitcoin is a decentralized digital currency that allows participants in the network to send and receive payments without relying on a third party (i.e. a bank). First introduced in 2008, the Bitcoin protocol’s scalability is hampered by its relative latency and high transaction fees. The Lightning Network was proposed as a solution to Bitcoin’s scalability issue by enabling a high volume of participants to transact micropayments instantly. The Lightning Network is a “Layer 2” solution, which means that users can exchange funds internally and only pay settlement costs when they want to withdraw the money. # Contact Us Our goal is to develop this as an open source project and we have a lot to do! There are numerous challenges associated with realizing Zion at scale, and there are many things we know we have yet to consider. We welcome your input on how to improve, please let us know or join us!
DeptEmail & Links
Support support@zion.fyi
Questions hello@zion.fyi
Jobshttps://bitcoinerjobs.com/company/zion
# Social Media
the ironyURL
Twitterhttps://twitter.com/get_zion
Instagramhttps://www.instagram.com/get_zion/
Telegramhttps://t.me/getZION