{"id":29142441,"url":"https://github.com/think2011/matrixprotocol","last_synced_at":"2026-02-05T19:32:51.516Z","repository":{"id":76615809,"uuid":"415310522","full_name":"think2011/MatrixProtocol","owner":"think2011","description":null,"archived":false,"fork":false,"pushed_at":"2021-10-06T13:32:18.000Z","size":908,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-06-30T19:52:57.452Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://www.bilibili.com/video/BV1Tf4y1n7FD","language":null,"has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/think2011.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2021-10-09T13:01:38.000Z","updated_at":"2022-08-29T09:54:59.000Z","dependencies_parsed_at":null,"dependency_job_id":"c459dd95-351f-4790-a5bb-cdb6d8448843","html_url":"https://github.com/think2011/MatrixProtocol","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/think2011/MatrixProtocol","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/think2011%2FMatrixProtocol","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/think2011%2FMatrixProtocol/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/think2011%2FMatrixProtocol/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/think2011%2FMatrixProtocol/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/think2011","download_url":"https://codeload.github.com/think2011/MatrixProtocol/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/think2011%2FMatrixProtocol/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29130450,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-05T18:55:47.139Z","status":"ssl_error","status_checked_at":"2026-02-05T18:55:04.010Z","response_time":65,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-06-30T19:37:37.487Z","updated_at":"2026-02-05T19:32:51.507Z","avatar_url":"https://github.com/think2011.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Matrix Protocol - limit order book trading with sharable liquidity\n\n\u003ca href=\"https://discord.gg/bGF7eEAgdR\"\u003e\u003cimg src=\"https://discord.com/assets/ff41b628a47ef3141164bfedb04fb220.png\" width=\"250\"\u003e\u003c/a\u003e\n\n[Official Discord Server](https://discord.gg/bGF7eEAgdR)\n\nProject Name: Matrix\n\nTeam Name: Hash Pocket Team\n\nBrief introduction: To achieve limit orderbooks on Chia Network and provide sharable fundamental liquidity.\n\n## Project Overview\n### Background\nDeFi's total value locked has already reached 110 billion, while Ethereum occupies 78 billion. In a few years, DeFi has developed incredibly rapidly. During this process, primitive users have been suffering from Ethereum’s high gas fee, extremely low TPS and MEV problems. Until EIP1559 and some organizations like Flashbots appear, those problems are alleviated. Thanks to repeated attempts of early adopters, DeFi has taken shape.\n\nCurrently, DeFi is based on some smart contract platforms with Account Model such as Ethereum. Therefore, as it grows, performance bottlenecks inevitably emerge, resulting in a variety of Layer 2 solutions. Although Layer 2 solutions alleviate the performance and transaction friction problems of smart contract platforms, they break the composability in DeFi of Layer 1.\n\nBut why does no one pay attention to Bitcoin, the UTXO model that can almost expand capacity unlimitedly?\n\nBitcoin itself has limitations such as its Turing-incomplete scripting system and the low-efficiency of its POW consensus. Even though UTXO is powerful, with these limitations, it is difficult to implement the base function of DeFi.\n\nChia, however, makes all this possible. It makes Coin a first-class citizen and brings Chialisp, which is not as easy to understand as the account model of Ethereum, but this transformation makes UTXO-based DeFi a reality on Chia. As the superset of Lisp, Chialisp brings the advantage of Lisp into Chia’s Smart Coin. The coin set model and Chialisp complement each other.\n\n### Why CLOB?\nWhy do we prefer to achieve CLOB(Central Limit Order Book), compared with AMM?\n\nReasons are shown below.\n1. The efficiency of AMM's price discovery is quite low.\n2. AMM can not provide liquidity for specific prices.\n3. AMM requires users to add liquidity to both sides.\n4. In AMM, users can not quote prices according to their wills.\n5. AMM has larger slippages in the big deal.\n6. In AMM, the liquidity is fragmented and trapped in pools respectively.\n\n### Vision for Matrix Protocol\nThe foundation of Matrix Protocol is based on Chialisp. Numerous computations are done off chain and verification are done on chain, which means Matrix Protocol can almost expand capacity unlimitedly. Moreover, Smart Coin, based on Chialisp, can use formal verification to ensure security, which makes the contract more reliable and auditable.\n\nSmart Coin can be considered as a coin contains a program, when you spend it, the program got executed. And Coins in other Chia DApps, also as first-class citizens, can be seamlessly compatible with Matrix Protocol to achieve interoperability of fundamental liquidity.\n\nFrom our perspective, Chia Coin Set Model, based on the design concept of UTXO, is a true electronic cash and programmable money. It is a \"banknote\" that exists independently in the virtual space. This inspired us to use first principle thinking to go back to the original starting point of \"Exchange\", to think about how an exchange should be conducted on DeFi, and to explore and experiment with shared fundamental liquidity on Chia Network.\n\n## Project Detail\n\nMatrix Protocol is a trading protocol of decentralized orderbooks. Users can create orders, cancel orders, fill orders, and view order history in the frontend which they need to synchronize with Full Node. The whole transaction process is completely independent of any centralized node. Thanks to UTXO-based Coin Set Model and Chialisp, users can trade on Matrix with near-centralized exchange speed with extremely low fees.\n\nFrom a functional perspective, key implementation and standard definition of Matrix Protocol are shown below.\n\n![Figure 1](https://github.com/HashPocket/MatrixProtocol/raw/b9094d3ec0361c77873a5f796d70b6601b3de4a0/images/Figure_1.png)\n\n![Figure 2](https://github.com/HashPocket/MatrixProtocol/raw/b9094d3ec0361c77873a5f796d70b6601b3de4a0/images/Figure_2.png)\n\n1. Maker establishes Maker Puzzle and Taker Puzzle based on order information. Taker Puzzle contains order information, such as the address and order amount of Makers. Taker Puzzle Hash and related order information are included in the Maker Puzzle. Maker Coin (Its puzzle is called Maker Puzzle and amount is called Maker Amount) is generated when Maker uses the corresponding wallet (Standard Wallet or Colorful Wallet).\n2. According to the public Matrix Gateway Puzzle, Gateway Coin is generated temporarily. Order params are passed to gateway when you make a solution contains order data to spend the gateway coin.\n3. The transaction is conducted through SpendBundle which is consisted of Gateway Coin Spend and Maker Coin Spend.\n4. Broker monitors puzzles and coins that they are interested in on chain, gathers order information from the Solution of Matrix Gateway Coin and update order status from the Solution of Maker Coin.\n5. Broker maintains orderbooks, creates new orders, updates order status and cancels expired orders\n6. Taker gets order information from the orderbooks.\n7. Taker builds an ephemeral Taker Coin according to order information and spends Maker Coin and Taker Coin simultaneously.\n8. Taker can consume it again, if it is still left in Maker Coin, which can recreate itself.\n\n## Basic Order Structure\n\nIn Matrix Protocol, each order is a unique puzzle with `genesis_maker_coin_id` as its order ID. The specific structure and meanings are shown below.\n\n| Field Name                                                    | Comment                                                                                  |\n| ----                                                          | ----                                                                                     |\n| latest_maker_coin_id                                          | latest_maker_coin_id                                                                     |\n| status                                                        | 0 initialization 1 Confirm on chain 3 Cancel 4 Partial filled orders 5 All filled orders |\n| fee                                                           | service fee                                                                              |\n| expired_in                                                    | expire time, timestamp of Unix, seconds                                                  |\n| coin_amount                                                   | the rest amount of maker coin in current order                                           |\n| taker_puzzle_has                                              |                                                                                          |\n| taker_amount                                                  |                                                                                          |\n| maker_amount                                                  |                                                                                          |\n| maker_cc_id                                                   | If it is colorful coin，it is colorful id. If it is standard coin, it is \"chia\".         |\n| taker_cc_id                                                   | same as maker_cc_id                                                                      |\n| receiver_taker_coin_address                                   | receive the address of taker coin                                                        |\n| receiver_maker_coin_address                                   | receive the address of maker coin                                                        |\n| pubkey                                                        | authentication                                                                           |\n| confirmed_at_index                                            |                                                                                          |\n| created_at_time                                               |                                                                                          |\n| genesis_maker_coin_id                                         | the parent coin name of first Maker Coin                                                 |\n\n## Orderbook\nThe orderbook is a list of the order structure above. So far, orderbooks are established by Broker. In the future, we will index orderbooks and provide global orderbook apis for querying orders.\n\nThe orderbook is generated from parsing on-chain transactions. Let’s suppose that we start from a certain block, keep tracking the latest block, use its transactions_filter to check whether it contains MATRIX_GATEWAY_PUZZLE (there will be further introduction about this contract below) or Maker Puzzles and get all related coins. If a new coin with MATRIX_GATEWAY_PUZZLE shows up, which means there is a new order, the order status will be updated, and the new order will be saved in the local SQLite database.\n\n### Create Orders\nWe will open-source MATRIX_GATEWAY_PUZZLE which can be called by any user. Actually, the order data is stored in the Solution. Considered of the extremely low transaction fees, Solution may contain a simple verification or a low commission to ensure the economical security, preventing from malicious attacks.\n\n### Match Orders\nUsers can create their Taker Puzzle which contains order information, such as Maker’s address and amount, after querying the Solution of Maker Coin and Gateway Coin through Broker. Once the Spend Bundle, which is composed of Gateway Coin Spend and Maker Coin Spend, is broadcast to the network, and gets included in a block, the transaction is completed.\n\n![Figure 3](https://github.com/HashPocket/MatrixProtocol/raw/b9094d3ec0361c77873a5f796d70b6601b3de4a0/images/Figure_3.png)\n\nTo fill the order, firstly, users must create Taker Coin according to the order information. And then spend both Maker Coin and Taker Coin to ensure the integrity of the transaction, mainly to ensure that the information of Taker Coin (transfer address, transaction price and amount) is correct. The address is embedded in the PUZZLE, and the transaction price and amount are submitted in Solution. In order to ensure proper execution of TAKER COIN, all these information is collected in the Message of CREATE_PUZZLE_ANNOUNCEMENT and use ASSERT_PUZZLE_ANNOUNCEMENT in Maker Coin.\n\nIn the aspect of against front-running, in a centralized exchange, once a user submits a market order, it will be filled. Therefore, front-running is a common concern in centralized exchange. But in Matrix, the market price comes from a specific order that the driver module has already matched, and maker coin has been spent. Even if someone attempts to front run the order, the interests of the user will not be harmed, because the user can see the pre-execution result of his order before submitting it, and naturally will not submit it if it is unfavorable to him. Therefore, there is no guarantee that the front-runner will be able to \"profit from the front-run\", so the rational service provider will not risk it.\n\nThe Broker’s orderbook serves as a centralized service that provides users with extremely fast service, but without compromising the interests of Matrix users. This is only possible due to Chia’s UTXO-like Coin Set Model and is not possible on chains that use global state machines such as Ethereum.\n\n### Cancel Orders\n\n* Cancelled by users\n\nUsers call the `cancel_by_me` function in maker coin which will transform the amount of maker coin to the `receiver_maker_coin_address`. (There will be subtle arbitrage. )\n\n* Cancelled by others\n\nThe current maximum expiration time for orders is 90 days, and users can also set their own expiration time, taking the minimum value of both. The puzzle restricts that only after the expiration time others can call this cancellation function, and when calling cancel you can pass an address of your own to transfer the handling fee from the initialization of the order to that address. This measure is used to incentivize third parties to control the size of the order book.\n\n### Fill Orders\n\nWhen users are placing orders, they do not know whether they play the role as a Maker, or the order is filled automatically. (Afterall, order information has been changing.) We will implement order-routing function in Matrix SDK. If all orders are filled, it will execute taker module. If orders are partially filled, the rest will execute recreate_self function, and a new puzzle will be there. (A new order will appear.)\n\nWhen users initiate a market order, firstly, they need to choose one order or multiple combined orders which meet the conditions in the orderbooks and merge all the transactions in one SpendBundle. Users sign transactions and wait until the order is filled. If there is not such an order, a limit order is generated and waits for other users to fill.\n\n![Figure 4](https://github.com/HashPocket/MatrixProtocol/raw/b9094d3ec0361c77873a5f796d70b6601b3de4a0/images/Figure_4.png)\n\n### Order History\nUsers can get their full transaction history by running the open-source Matrix Client. In fact, Matrix Client just help users filter the pubkey of orders. When the pub key of orders matches the users, then that order belongs to that user.\nAlso, by partnering with an SPV wallet like Nucle.io, users will be able to see their historical orders placed through the Matrix Protocol directly within their usual wallet.\n\n## Core Team\n\n### Dimitry Suen\n\n* Ele.me, Baixing.com Backend Engineer\n* Technical Director \u0026 Advisor for a startup (supply chain finance)\n* Trusted Data Platform Manager (Based on blockchain for some local governments)\n\n### Even Ma\n\n* Baixing.com Backend Engineer, Project Leader\n* DeBank.com Backend Engineer\n* Individual Investor and Developer\n\n### Jolie Ji\n\n* High-frequency trading expert\n* Hedge fund manager\n\n\n## Future Plans\n### Price Oracle\nWith a certain amount of trading volume on Matrix, time-weighted price oracle can be carried out with the help of Singleton pattern.\n\n### Margin trade\nBuild a lending pool that Matrix Protocol will automatically help users borrow/repay when they choose to trade with leverage. The user is trading on margin, and if a large price deviation occurs, it triggers a forced liquidation of the position.\n\n### Derivative trade\nUsers can tokenize a stable coin like xUSD, carbon credits or $APPL on Matrix Protocol. And they can synthesize and trade any asset on Matrix Protocol. Also, users can mint NFTs to explore the metaverse on Chia Network.\n\n### Research on Layer 2\n* Focus on Infinite Scaling of Performance\n\nIn the future, after Matrix reaches a certain trading volume and trading frequency, we can establish a Layer 2 network to aggregate several transactions and then send them together to the chia network. At the same time, orders of Maker can be shared among layer 2 nodes, to achieve the goal of sharing liquidity. Other projects can easily access Matrix Protocol through the Driver module provided by us, and orders can also be routed to Matrix Protocol for processing through the Matrix Gateway.\n\n## License\nApache Licence 2.0\n\n## Additional Information\n* What work has been done so far?\n\nWe have completed the MVP (Minimum Viable Product) and are building the frontend page and auditing the economical security.\n\n* Are there any other teams doing the same kind of projects?\n\nNot yet. If so, we are willing to communicate with them and collaborate to improve the underlying liquidity design for Chia Network.\n\n* How to cooperate with Chia ecosystem?\n\nWe will try to simplify and abstract the puzzle design and make Matrix Protocol a more fundamental component. And we will try to communicate more with other DeFi project designers to make the design more adaptive.\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthink2011%2Fmatrixprotocol","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fthink2011%2Fmatrixprotocol","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthink2011%2Fmatrixprotocol/lists"}