# Portfolio > Technical writing portfolio: API references, SDK guides, tutorials, and case studies across web3, fintech, and AI tooling. Written for developers and AI agents alike. > For the complete documentation index, see [llms.txt](/llms.txt). --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Welcome (/) Hi! I'm Dmytro. I am senior technical writer with strong knowledge of APIs, docs-as-code tools, blockchain ecosystems, and AI workflows. I ship apps, CLIs and content that reduce support overhead by double digits, speed up product integration for international clients, and create a seamless developer experience. This vault is a collection of my work. Below are my main case studies. Event cover OMG Network Case Study Event cover Chainlink Case Study Event cover Myria Case Study Event cover Paytomat Case Study --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Chainlink Case Study (/case-studies/chainlink) * **Role:** Technical Writer, embedded with the developer relations team * **Engagement:** February 2021 to September 2021 ## Background [#background] Chainlink is a decentralized oracle network that connects smart contracts to off-chain data, external APIs, and other blockchains. Its documentation needed to serve a fast-growing range of integration patterns, from price feeds to automation, while staying approachable to engineers building on EVM-compatible chains for the first time. ## Goal [#goal] My role was to make the developer portal something the community could contribute to directly, give engineers runnable examples for the integration patterns they actually needed, and close the gap on the questions that kept resurfacing in support channels and at hackathons. ## Key problems solved [#key-problems-solved] ### Problem 1: No option for community to contribute to the docs [#problem-1-no-option-for-community-to-contribute-to-the-docs] **Challenge**: The portal was hosted on Read the Docs, with no path for external contributions and a structure that hadn't kept pace with the growing number of integrations and data providers Chainlink supported. **Solution**: I helped structure and migrate the Chainlink developer portal into an open-source, Eleventy-based site, with content organized so both the internal team and outside contributors could submit changes directly instead of routing everything through a closed process. **Impact**: Developer engagement increased 25–35%. portal ### Problem 2: A continuously expanding integration surface outpacing documentation [#problem-2-a-continuously-expanding-integration-surface-outpacing-documentation] **Challenge**: Chainlink kept expanding new price and data feeds, new integration points, new Automation features. Each addition needed its own guide before engineers could use it, with new ones landing as fast as the product shipped. **Solution**: I delivered guides and tutorials as each new integration shipped, covering it end to end: making job requests, pulling Arbitrum price feeds, working with Flight Aware data, checking L2 sequencer health, and registering Automation upkeep among them. **Impact**: Gave engineers a self-serve path through the most common integrations, reducing the back-and-forth needed to get a first integration working. upkeep-1 ### Problem 3: No feedback loop between support and the docs [#problem-3-no-feedback-loop-between-support-and-the-docs] **Challenge**: The same gaps surfaced repeatedly, both in general developer support and during hackathons, where teams under time pressure ran into the same blockers as engineers integrating outside of an event. **Solution**: I participated in hackathons and hang out in developer's Discord, gathering developer feedback in real time and feeding it back into the docs rather than answering the same questions individually each time they came up. **Impact**: Support question volume dropped 30–40%. ## Final deliverables [#final-deliverables] * An open-source [developer portal](https://github.com/smartcontractkit/documentation) * [Chainlink API Calls](/portfolio/chainlink/api-calls) guide * [Arbitrum Feeds](/portfolio/chainlink/arbitrum-feeds) integration guide * [Flight Aware](/portfolio/chainlink/flight-aware) integration guide * [L2 Sequencer Health Flag](/portfolio/chainlink/health-flag) guide * [How to Register Upkeep](/portfolio/chainlink/register-upkeep) * [How to Make an Existing Job Request](/portfolio/chainlink/job-requests) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Myria Case Study (/case-studies/myria) * **Role:** Technical Writer, embedded with the engineering team * **Engagement:** June 2022 to December 2022 ## Background [#background] Myria is a gaming ecosystem built to help developers launch and scale games on Ethereum. The project needed a scalable solution to serve public-facing documentation for integration partners. ## Goal [#goal] My role was to build Myria's developer documentation from nothing: give partners a self-serve way to integrate, cut down the manual steps standing between a new partner and a working integration, and reduce how often the same questions landed in support. ## Key problems solved [#key-problems-solved] ### Problem 1: No developer portal to integrate against [#problem-1-no-developer-portal-to-integrate-against] **Challenge**: Myria had no public developer documentation. Partners evaluating or building on the platform had nothing to work from and depended entirely on direct access to the engineering team. **Solution**: I built the developer portal from scratch, covering SDK references, guides, and samples for the platform. **Impact**: Attracted multiple high-quality partners within the first few weeks, including AB de Villiers, LeapBlock Studios, and Crystal of Fate. portal ### Problem 2: No reference for partners' recurring questions [#problem-2-no-reference-for-partners-recurring-questions] **Challenge**: Before a partner could do anything with the SDK, they had to generate a Stark key, a manual step with no tooling behind it. From there, the SDK itself spanned collections, minting, and project management, with no runnable example to show how the pieces fit together. **Solution**: I built an SDK helper on the developer portal to generate a Stark key directly, removing that manual step, and a TypeScript SDK samples app covering the SDK's core flows as runnable examples partners could start from. **Impact**: Decreased partner integration time by 70–80%. sdk ### Problem 3: No feedback loop between support and the docs [#problem-3-no-feedback-loop-between-support-and-the-docs] **Challenge**: Beyond the core SDK, partners needed answers on things like marketplace interactions and other day-to-day tasks, and without documented references for them, the same questions kept landing in support. **Solution**: I wrote a broad set of SDK references, along with smaller guides for tasks like marketplace mint transactions. **Impact**: Reduced technical support ticket volume by 50–60%. ## Final deliverables [#final-deliverables] * A developer portal built from scratch, covering SDK references, guides, and samples * A Stark key generator helper built into the portal (no longer publicly accessible; Myria's docs are no longer open source) * A [TypeScript SDK samples app](/portfolio/myria/samples-app) * SDK references including [Collections](/portfolio/myria/collections), [Minting](/portfolio/myria/minting), and [Projects](/portfolio/myria/projects), among others * Smaller guides for marketplace interactions and related tasks, including [mint transactions](/portfolio/myria/mint-transactions) * A [quickstart guide](/portfolio/myria/quickstart) for new partners ## What happened next [#what-happened-next] The role was eliminated during a company-wide restructuring following multiple rounds of layoffs. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # OMG Network Case Study (/case-studies/omg-network) * **Role:** Technical Writer, embedded with the engineering team * **Engagement:** March 2020 to December 2020 ## Background [#background] OMG Network is a Layer 2 scaling solution for Ethereum. Its growth depended on exchanges, wallet providers, and other platforms being able to integrate without first becoming experts in the protocol's UTXO model and Plasma architecture. ## Goal [#goal] My role was to shorten that integration path so partners could ship without extended back and forth with the core engineering team, and to keep the developer portal accurate as the protocol kept changing under it. ## Approach [#approach] Over the course of the engagement, I rebuilt the documentation around how partners actually integrate: a docs-as-code portal that stayed in sync with releases, a runnable samples app for engineers who wanted to start from working code, end-to-end use-case guides for exchanges and wallets, a no-code quickstart for non-developers doing early evaluation, and a technical specification written to withstand jury-level scrutiny for Reddit's scaling competition. ## Key problems solved [#key-problems-solved] ### Problem 1: Public docs couldn't keep pace with a protocol in motion [#problem-1-public-docs-couldnt-keep-pace-with-a-protocol-in-motion] **Challenge**: A protocol was under active development, however documentation had a separate cycle from the code. Internal docs existed but there wasn't a clear structure, clarity, and direction about public ones. **Solution**: I built and maintained the Docusaurus-based developer portal on a docs-as-code workflow: content lived as React and Markdown in version control, went through the same review process as code changes, and shipped alongside protocol releases instead of trailing them. **Impact**: 10 hours a week saved on average compared to the previous maintenance process. portal ### Problem 2: No fast path from omg-js to a working transaction [#problem-2-no-fast-path-from-omg-js-to-a-working-transaction] **Challenge**: The `omg-js` library exposed a wide surface area: deposits, transfers, UTXO splitting and merging, standard exits, and in-flight exits. A partner's engineering team could read every page of documentation and still spend hours assembling a working project around the library before seeing a single transaction succeed. **Solution**: I built and documented a JavaScript samples application covering each of these operations as a runnable example, with a pre-filled testnet configuration so a new integrator could clone the project, drop in their own keys, and watch a transaction go through within minutes instead of days. The app became the reference engineers used before opening a support ticket. **Impact**: Integration time dropped from 2 hours to 3 minutes for partners using the samples app directly. omg-samples-app ### Problem 3: Integrators had no single path through the protocol [#problem-3-integrators-had-no-single-path-through-the-protocol] **Challenge**: There was no single resource that covered the full scope of integration with the OMG Network, causing engineers to piece things together from the protocol's source code and scattered documentation, then surfacing gaps as support requests. **Solution**: I wrote two use-case guides, one for exchanges and one for wallets, that walked an integrator through the entire scope as a single linear path. Each guide opened with the relevant personas and user stories, then worked through address generation, querying patterns, UTXO merge strategy, Watcher setup, and the wallet rebalancing steps needed before go-live. The guides also called out the parts of the process specific enough to each partner's stack that they were intentionally left open, rather than prescribing a UI flow that wouldn't fit every exchange. **Impact**: Integration time for key partners dropped 60 to 70 percent after these guides shipped. omg-wallet-2 ### Problem 4: Non-developers couldn't evaluate the protocol without writing code [#problem-4-non-developers-couldnt-evaluate-the-protocol-without-writing-code] **Challenge**: Before a partner's development team commited time to a full integration, someone on their side, needed to see the entire lifecycle work: deposit funds, send a transaction, then withdraw back to Ethereum. Doing that through raw `omg-js` calls meant writing a project just to confirm the protocol behaves the way the docs say it does. **Solution**: I wrote a quickstart built around the network's hosted Web Wallet, giving non-developers a way to see the full deposit-to-exit lifecycle with no code involved. It covered connecting a Web3 wallet, including hardware signing through a Ledger device, funding an Ethereum wallet, depositing ETH and ERC20 tokens, sending a transfer, then submitting and processing a standard exit through its challenge period, entirely through the browser. It was written for a wider audience than the integration guides: partners doing early due diligence, exchange and wallet teams sizing up the work, and developers who wanted to see Plasma's deposit and exit mechanics firsthand. **Impact**: Gave non-technical evaluators and early-stage partners a self-serve way to confirm the protocol worked as documented, without involving engineering time on either side. omg-7 ### Problem 5: Reddit's bake-off jury needed an implementable spec, not a pitch [#problem-5-reddits-bake-off-jury-needed-an-implementable-spec-not-a-pitch] **Challenge**: OMG Network was a finalist in Reddit's Great Scaling Bake-Off, a public competition to select the scaling solution behind Reddit's Community Points program. The submission was read by a technical jury and by Reddit's own engineering team, and a marketing-style proposal was inappropriate and coudln't hold up to that scrutiny. **Solution**: I authored the bulk of the Community Points Engine technical specification: personas and user stories for community members, moderators, and Reddit's internal team, the full system architecture covering the browser extension client, fee-relayer server, smart contracts, and MultiBaaS admin dashboard, the transaction lifecycle as a step by step flow, and the relayer API's endpoints. The spec also included real load-test results rather than projected ones. The team ran a multi-hour stress test against the live integration environment, executing over 100,000 simulated claim and transfer transactions, and the spec published the methodology along with queryable transaction hashes so the numbers could be independently verified. **Impact**: The submission received the highest ranking from the Reddit team and community among the bake-off entries. cm-1 ## Final deliverables [#final-deliverables] * A React-based [developer portal](https://github.com/omgnetwork/omgnetwork.github.io) maintained on a docs-as-code workflow * [Wallet](/portfolio/omg-network/wallet-use-case/) and [exchange](/portfolio/omg-network/exchange-use-case) integration use-case guides * [A Web Wallet quickstart](/portfolio/omg-network/web-wallet) covering deposits, transfers, and exits through the hosted browser wallet * A documented [JavaScript samples application](/portfolio/omg-network/samples-app) covering deposits, transfers, UTXO management, and exits * Maintenance and updates to three existing API references: [Info](/portfolio/api/omg-info), [Operator](/portfolio/api/omg-operator), and [Watcher](/portfolio/api/omg-watcher) * [The Community Points Engine technical specification](/portfolio/omg-network/community-points) submitted to [Reddit's Great Scaling Bake-Off](https://www.reddit.com/r/ethereum/comments/i19us9/omg_networks_great_reddit_scaling_bakeoff_proposal/) * Operational how-tos for partners running their own infrastructure: [running a Watcher](/portfolio/omg-network/run-watcher), [managing a Watcher](/portfolio/omg-network/manage-watcher), [managing a VPS](/portfolio/omg-network/how-to-manage-vps), and [working with the MultiBaaS](/portfolio/omg-network/multibaas) admin dashboard ## What happened next [#what-happened-next] OMG Network was acquired in late 2020, followed by a cross-department restructuring that eliminated the technical writer role. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Paytomat Case Study (/case-studies/paytomat) * **Role:** Technical Writer / Content Manager * **Engagement:** January 2017 to September 2019 ## Background [#background] Paytomat built infrastructure for merchants to accept cryptocurrency through existing point-of-sale systems. The company started with a small bootstrap raise from Dash DAO. Once that early product validated the idea, the team began building toward a bigger product vision and needed to start building an audience around it. ## Goal [#goal] My role covered the company's audience and content work as it scaled past its initial bootstrap, plus maintaining the API documentation and coordinating with point-of-sale partners as integrations shipped. ## Key problems solved [#key-problems-solved] ### Problem 1: There was no content strategy around the product [#problem-1-there-was-no-content-strategy-around-the-product] **Challenge**: Paytomat had no content strategy at all. Early traction from the Dash DAO-funded bootstrap had validated the idea, but there was nothing in place to build an audience as the company moved toward a larger product vision. **Solution**: I helped to build and ran the company's content strategy, aligned with the broader push toward that bigger product. **Impact**: Increased audience engagement by 35–45% within the first few weeks. ptm-15 ### Problem 2: No material for non-technical clients to evaluate [#problem-2-no-material-for-non-technical-clients-to-evaluate] **Challenge**: Outside of a technical audience, prospective clients had no in-depth material explaining what Paytomat was building or why it mattered. **Solution**: I contributed to two whitepapers laying out the product and its direction in more depth than the content strategy alone covered. **Impact**: Increased interest from non-technical clients by 30–40%. ptm-7 ### Problem 3: API docs needed to stay current as POS integrations shipped [#problem-3-api-docs-needed-to-stay-current-as-pos-integrations-shipped] **Challenge**: Paytomat was integrating with multiple point-of-sale providers, including NCR, Poster, and 1C. Each integration meant the API documentation had to track what was actually shipping, and coordination was needed between Paytomat's team and each provider to keep both sides aligned. **Solution**: I maintained the API documentation as these integrations went live and coordinated between Paytomat's engineering team and the POS providers' teams to keep the integrations and the docs in sync. **Impact**: Kept documentation accurate across three concurrent POS integrations without it trailing behind what partners were shipping. ptm-9 ## Final deliverables [#final-deliverables] * A content strategy supporting Paytomat's broader product push * Contributions to two [whitepapers](https://github.com/thisonedev/thisonedev.github.io/blob/master/content/portfolio/paytomat/paytomat-2.0.pdf) * Maintained [API documentation](/portfolio/paytomat/console-api) for the Console Panel REST API * Integration coordination with point-of-sale providers NCR, Poster, and 1C ## Notable participation [#notable-participation] Alongside this work, I represented Paytomat at Malaysia's MaGIC Accelerator Program over a four-month period, joined a Google Design Sprint, and took part in a National Ukrainian Record for the largest number of cryptocurrency purchases at a single location within three hours. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # API Calls Tutorial (/chainlink/api-calls) ## Prerequisites [#prerequisites] This tutorial requires basic knowledge about Ethereum, smart contracts, and the Chainlink Request & Receive cycle. If you're unfamiliar with those concepts, follow the [The Basics](https://docs.chain.link/getting-started/conceptual-overview) or [Random Numbers](https://docs.chain.link/tutorials/random-numbers) tutorials. By the end of the tutorial, you should know the following: * How to request data from a public API in a smart contract. * Understand what Core Adapters and External Adapters are and how Oracle Jobs use them. * Be able to find the Oracle Jobs and Adapters for your contract. *** ## How to request data from an Oracle Job [#how-to-request-data-from-an-oracle-job] ### 1. Requesting API Data [#1-requesting-api-data] #### 1a. Request & Receive Recap [#1a-request--receive-recap] The request and receive cycle describes how a smart contract requests data from an oracle and receives the response in a separate transaction. If you need a refresher, check out the [Basic Request Model](https://docs.chain.link/getting-started/basic-request-model). In the Random Numbers tutorial, we request randomness from a VRF oracle, then await the response. The fulfillment function is already given to us from the `VRFConsumerBase` contract, so oracles already know where to send the response to. However, with API calls, our contract defines which function it wants to receive the response to. However, before we go into the implementation, let's first understand how Oracle jobs can get data on-chain. #### 1b. Initiators [#1b-initiators] Initiators are what kick off a job inside an Oracle. In the case of a Request and Receive job, the **RunLog initiator** watches the blockchain for when a smart contract makes a request. Once it catches a request, it initiates the job. This runs the adapters (both core and external) that the job is configured to run, eventually returning the response to the contract that made the request. #### 1c. Core Adapters [#1c-core-adapters] Each oracle job has a configured set of tasks it needs to carry out when it is run. These tasks are defined by what Adapters they support. For example: if a job needs to make a GET request to an API, find a specific unsigned integer field in a JSON response, then submit that back to the requesting contract, it would need a job with the following Core Adapters: * **HttpGet** - Call the API. * **EthTx** - Submit the transaction to the chain, completing the cycle. Let's walk through a real example, where we retrieve 24 volume of the ETH/USD pair from the cryptocompare API. #### Core Adapters Example [#core-adapters-example] * **HttpGet** - Calls the API and returns the body of an HTTP GET result for ETH/USD pair. * **JsonParse** - walks a specified path (`"RAW.ETH.USD.VOLUME24HOUR"`) and returns the value found at that result. Example: `703946.0675653099`. * **Multiply** - parses the input into a float and multiplies it by the 10^18. Example: `703946067565309900000000`. * **EthUint256** - formats the input into an integer and then converts it into Solidity's `uint256` format. Example: `0xc618a1e4`. * **EthTx** - takes the given input, places it into the data field of the transaction, signs a transaction, and broadcasts it to the network. Example: transaction result. **Important:** Some core adapters accept parameters to be passed to them to inform them how to run. For example: `JsonParse` accepts a `path` parameter which informs the adapter where to find the data in the JSON object. Let's see what this looks like in a contract. #### Contract Example [#contract-example] ```json { "RAW": { "ETH": { "USD": { "VOLUMEDAYTO": 953806939.7194247, "VOLUME24HOUR": 703946.0675653099, "VOLUME24HOURTO": 1265826345.488568 } } } } ``` ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.7; import "@chainlink/contracts/src/v0.8/ChainlinkClient.sol"; /** * THIS IS AN EXAMPLE CONTRACT WHICH USES HARDCODED VALUES FOR CLARITY. */ contract APIConsumer is ChainlinkClient { using Chainlink for Chainlink.Request; uint256 public volume; address private oracle; bytes32 private jobId; uint256 private fee; /** * Network: Kovan * Oracle: 0xc57B33452b4F7BB189bB5AfaE9cc4aBa1f7a4FD8 (Chainlink Devrel Node) * Job ID: d5270d1c311941d0b08bead21fea7747 * Fee: 0.1 LINK */ constructor() { setPublicChainlinkToken(); oracle = 0xc57B33452b4F7BB189bB5AfaE9cc4aBa1f7a4FD8; jobId = "d5270d1c311941d0b08bead21fea7747"; fee = 0.1 * 10 ** 18; // (Varies by network and job) } /** * Create a Chainlink request to retrieve API response, find the target * data, then multiply by 1000000000000000000 (to remove decimal places) */ function requestVolumeData() public returns (bytes32 requestId) { Chainlink.Request memory request = buildChainlinkRequest(jobId, address(this), this.fulfill.selector); // Set the URL to perform the GET request on request.add("get", "https://min-api.cryptocompare.com/data/pricemultifull?fsyms=ETH&tsyms=USD"); // Set the path to find the desired data in the API response request.add("path", "RAW.ETH.USD.VOLUME24HOUR"); int timesAmount = 10**18; request.addInt("times", timesAmount); // Sends the request return sendChainlinkRequestTo(oracle, request, fee); } /** * Receive the response in the form of uint256 */ function fulfill(bytes32 _requestId, uint256 _volume) public recordChainlinkFulfillment(_requestId) { volume = _volume; } // function withdrawLink() external {} - Implement a withdraw function } ``` \[Deploy this contract using Remix ↗]\(Deploy this contract using Remix) \[What is Remix?]\(What is Remix?) Let's walk through what's happening here: * **Constructor** - Setup the contract with the Oracle address, Job ID, and LINK fee that the oracle charges for the job. * **requestVolumeData** - This builds and sends a request, which includes the fulfillment functions selector, to the oracle. Notice how it adds the `get`, `path` and `times` parameters. These are read by the Adapters in the job to perform the tasks correctly. `get` is used by `HttpGet`, `path` is used by `JsonParse` and `times` is used by `Multiply`. * **fulfill** - Where the result is sent once the Oracle job is complete. **Important:** The calling contract should own enough LINK to pay the specified fee (by default 0.1 LINK). You can use this \[tutorial to fund your contract]\(tutorial to fund your contract). This was an example of a basic HTTP GET request. However, it requires defining the API URL directly in the smart contract. This can, in fact, be extracted and configured on the Job level inside the Oracle. #### 1d. External Adapters [#1d-external-adapters] We split Adapters into two subcategories: * **Core Adapters** - These are what we described earlier and come built-in to each node. * **External Adapters** - perform specific tasks like calling a particular endpoint with a specific set of parameters (like authentication secrets that shouldn't be publicly visible smart contracts). Here are some examples of external adapters: * **Markets data**: AlphaChain. * **Real-world events**: SportsData, COVID Tracker. * **Social media proofs**: MUBC Retweet Verifier. * **Cryptocurrency aggregators**: Coingecko, CoinAPI. All of these can be found on \[Chainlink Market]\(Chainlink Market). If all the parameters are defined within the Oracle job, the only thing a smart contract needs to define to consume it is: * JobId. * Oracle address. * LINK fee. * Fulfillment function. This makes for a much more succinct smart contract, where the `requestVolumeData` function from the code example above would look more like this: ```solidity function requestVolumeData() public returns (bytes32 requestId) { Chainlink.Request memory request = buildChainlinkRequest(jobId, address(this), this.fulfill.selector); // Extra parameters don't need to be defined here because they are already in the job return sendChainlinkRequestTo(oracle, request, fee); } ``` ### 2. Exercise: Construct your own Contract [#2-exercise-construct-your-own-contract] Now that we know how core adapters and external adapters are used to construct jobs and how smart contracts can use jobs to make requests let's put that to use! Head to [Make an Existing Job Request](https://docs.chain.link/any-api/get-request/examples/existing-job-request) to see how a smart contract can get any city's temperature using an existing oracle job found on Chainlink Market, without having to specify the URL inside the contract. Then, using your knowledge of external adapters, find a different adapter on the market, and create another contract that consumes that data. Let us know the cool things you come up with in our discord! ### 3. Further Reading [#3-further-reading] * [Blog: Connect a Smart Contract to the Twitter API](https://blog.chain.link/connect-smart-contract-to-twitter-api/). * [Blog: Connect a Tesla Vehicle API to a Smart Contract](https://blog.chain.link/create-tesla-smart-contract-rental/). * [Blog: OAuth and API Authentication in Smart Contracts](https://blog.chain.link/oauth-and-api-authentication-in-smart-contracts-2/). ### What's Next [#whats-next] * [Make a GET Request](https://docs.chain.link/any-api/get-request/examples/get-request). * [Make an Existing Job Request](https://docs.chain.link/any-api/get-request/examples/existing-job-request). --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Arbitrum Feeds (/chainlink/arbitrum-feeds) To learn how to implement these feeds, see the [Ethereum Examples for Consuming Data Feeds](https://docs.chain.link/data-feeds/using-data-feeds). For LINK token and Faucet details, see the [LINK Token Contracts](https://docs.chain.link/resources/link-token-contracts) page. Note, onchain equity and ETF assets are only traded during standard market hours (9:30 am - 4pm ET M-F). Using these feeds outside of those windows is not recommended. > It is recommended to use the [L2 Sequencer Health Flag](https://docs.chain.link/chainlink-sequencer-health-flag) for all contracts on the Arbitrum network. *** ### Arbitrum Mainnet [#arbitrum-mainnet] **Show Heartbeat and Deviation Details** **Pair | Decimals | Proxy Address** ```text AAVE / USD 8 0xaD1d5344AaDE45F43E596773Bcc4c423EAbdD034 AUD / USD 8 0x9854e9a850e7C354c1de177eA953a6b1fba8Fc22 BTC / USD 8 0x6ce185860a4963106506C203335A2910413708e9 CNY / USD 8 0xcC3370Bde6AFE51e1205a5038947b9836371eCCb DAI / USD 8 0xc5C8E77B397E531B8EC06BFb0048328B30E9eCfB ETH / USD 8 0x639Fe6ab55C921f74e7fac1ee960C0B6293ba612 EUR / USD 8 0xA14d53bC1F1c0F31B4aA3BD109344E5009051a84 KRW / USD 8 0x85bb02E0Ae286600d1c68Bb6Ce22Cc998d411916 LINK / USD 8 0x86E53CF1B870786351Da77A57575e79CB55812CB PHP / USD 8 0xfF82AAF635645fD0bcc7b619C3F28004cDb58574 SUSHI / USD 8 0xb2A8BA74cbca38508BA1632761b56C897060147C UNI / USD 8 0x9C917083fDb403ab5ADbEC26Ee294f6EcAda2720 USDC / USD 8 0x50834F3163758fcC1Df9973b6e91f0F0F0434aD3 USDT / USD 8 0x3f3f5dF88dC9F13eac63DF89EC16ef6e7E25DdE7 YFI / USD 8 0x745Ab5b69E01E2BE1104Ca84937Bb71f96f5fB21 ``` *** ### Arbitrum Rinkeby [#arbitrum-rinkeby] **Show Heartbeat and Deviation Details** **Pair | Decimals | Proxy Address** ```text BTC / ETH 18 0x6eFd3CCf5c673bd5A7Ea91b414d0307a5bAb9cC1 BTC / USD 8 0x0c9973e7a27d00e656B9f153348dA46CaD70d03d DAI / USD 8 0xcAE7d280828cf4a0869b26341155E4E9b864C7b2 ETH / USD 8 0x5f0423B1a6935dc5596e7A24d98532b67A0AeFd8 LINK / ETH 18 0x1a658fa1a5747d73D0AD674AF12851F7d74c998e LINK / USD 8 0x52C9Eb2Cc68555357221CAe1e5f2dD956bC194E5 USDC / USD 8 0xe020609A0C31f4F96dCBB8DF9882218952dD95c4 USDT / USD 8 0xb1Ac85E779d05C2901812d812210F6dE144b2df0 ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # FlightAware Chainlink (Testnet) (/chainlink/flight-aware) This Chainlink has a dedicated connection to [FlightAware](https://uk.flightaware.com/). ### Steps for using this oracle [#steps-for-using-this-oracle] 1. **Write and deploy** your Chainlink contract using the network details provided. 2. **Fund** the contract with [LINK](https://docs.chain.link/resources/link-token-contracts). 3. **Call** your request method. *** ### Chainlink Network Details [#chainlink-network-details] Use the following addresses and Job IDs for the Kovan network to create requests: * **LINK Token address:** `0xa36085f69e2889c224210f603d836748e7dc0088` * **Oracle address:** `0x2f90A6D021db21e1B2A077c5a37B3C7E75D15b7e` * **JobID:** `a644d4e30977459d9a596bef89c09e71` * **Sleep JobID:** `f0003b2c52024e7fa931d6ee9a947c87` *** ### Create your Chainlink contract [#create-your-chainlink-contract] To inherit Chainlink behavior, you must import `ChainlinkClient.sol`. **Basic Contract Structure (Solidity 0.6.0):** ```solidity pragma solidity ^0.6.0; import "@chainlink/contracts/src/v0.6/ChainlinkClient.sol"; contract FlightAwareChainlink is ChainlinkClient { uint256 oraclePayment; constructor(uint256 _oraclePayment) public { setPublicChainlinkToken(); oraclePayment = _oraclePayment; } // Additional functions here... } ``` ### Tasks [#tasks] The oracle performs the following tasks: * FlightAware * Copy * Ethuint256 * EthTx *** ### Request Parameters [#request-parameters] * **endpoint**: The endpoint to query (optional, defaults to `FlightInfoEx`). * **flight**: The flight identification or number (required). * **departure**: The unix timestamp of the departure (required). * **until**: Required for the Sleep job. **Solidity Code Examples for Parameters:** ```solidity req.add("endpoint", "FlightInfoEx"); req.add("flight", "NAX105"); req.addUint("departure", 1594378824); req.addUint("until", now + 1 hours); ``` *** ### Chainlink Examples [#chainlink-examples] **The `createRequest` Method:** ```solidity function createRequest ( address _oracle, bytes32 _jobId, string memory _flight, uint256 _departure ) public onlyOwner { Chainlink.Request memory req = buildChainlinkRequest(_jobId, address(this), this.fulfill.selector); req.add("flight", _flight); req.addUint("departure", _departure); sendChainlinkRequestTo(_oracle, req, oraclePayment); } ``` **The `fulfill` Method:** ```solidity uint256 public result; function fulfill(bytes32 _requestId, uint256 _result) public recordChainlinkFulfillment(_requestId) { result = _result; } ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # The Graph App (/chainlink/graph-app) [The Graph App](https://github.com/thisonedev/vault/tree/master/chainlink-graph-app) is a demo for The Graph queries that monitor address changes for given Chainlink price feed. ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` https://github.com/thisonedev/vault.git ``` ### 2. Enter chainlink-graph-app directory [#2-enter-chainlink-graph-app-directory] ``` cd chainlink-graph-app ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ### 4. Set up configs [#4-set-up-configs] Create `.env` file and add the following keys: * `ENS_API` - an API endpoint for [ENS subgraph queries](https://thegraph.com/explorer/subgraph/ensdomains/ens) * `RESOLVER_ADDRESS` - a Chainlink resolver address for your price feed (e.g. `BTC/USD`) * `FEED_DOMAIN_ID` - an ENS domain id for a corresponding Chainlink price feed (e.g. `0xfb3362a97947a1804738d871b660275dff443b48fb7da009b2c605969b2045e9`) * `AGGREGATOR_DOMAIN` - an ENS domain for a corresponding Chainlink price feed (e.g. `aggregator.btc-usd.data.eth`) The `.env.example` file has default values for BTC/USD pair. ### Run one of the scripts [#run-one-of-the-scripts] #### Aggregator Address Monitoring. Method A [#aggregator-address-monitoring-method-a] This script monitors aggregator address changes for BTC/USD price feed via Resolver entity. ``` npm run ens-aggregator-a ``` #### Aggregator Address Monitoring. Method B [#aggregator-address-monitoring-method-b] This script monitors aggregator address changes for BTC/USD price feed via Domain entity. ``` npm run ens-aggregator-b ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # L2 Sequencer Health Flag (/chainlink/health-flag) The idea behind an **Optimistic Rollup (OR)** type of protocol is to move all execution **off-chain** and keep all transaction data available on-chain. Such protocols have a special off-chain component, a [Sequencer](https://medium.com/stakefish/optimistic-rollups-how-they-work-and-why-they-matter-3f677a504fcf), that executes and rolls up the Layer 2 transactions by batching multiple transactions into a single one. If a sequencer becomes unavailable, it becomes impossible to access read/write APIs that consumers are using, so every dapp will be down for 95% of the users, except those that know how to interact with the **Layer 1 OR contracts**. In this case, it would be unfair to continue providing service on your dApp, as only 5% of the users can use it. Note, this doesn't mean that the Layer 2 network has stopped, as OR is not an actual chain. ### Overview [#overview] The **L2 Sequencer Health Flag** helps mitigate potential exploits when the Sequencer is unavailable by notifying the corresponding OR protocol to raise a **flag** on Layer 2. The L2 Sequencer Health Flag consists of three actors: * **Chainlink Cluster** (a group of validator nodes): Executes the OCR Job every heartbeat "T" (the minimum frequency the Chainlink feed is configured to be updated). * **The actual OCR feed**: Reports the Sequencer status; it could be used for external users on Layer 1 to check OR protocol (e.g., Arbitrum) status. * **Validator**: Gets triggered by the OCR feed and executes the raise or lower flag action if the current answer is different from the previous one. ### Checking the Sequencer Status [#checking-the-sequencer-status] If you have contracts that rely on Layer 2 Chainlink Data Feeds, you should add an extra check for each of your contracts. To implement, use the following sample: ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.7; import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol"; import "@chainlink/contracts/src/v0.8/interfaces/FlagsInterface.sol"; contract ArbitrumPriceConsumer { // Identifier of the Sequencer offline flag on the Flags contract address constant private FLAG_ARBITRUM_SEQ_OFFLINE = address(bytes20(bytes32(uint256(keccak256("chainlink.flags.arbitrum-seq-offline")) - 1))); AggregatorV3Interface internal priceFeed; FlagsInterface internal chainlinkFlags; /** * Network: Arbitrum Rinkeby * Flags Address: 0x491B1dDA0A8fa069bbC1125133A975BF4e85a91b */ constructor() { priceFeed = AggregatorV3Interface(0x5f0423B1a6935dc5596e7A24d98532b67A0AeFd8); chainlinkFlags = FlagsInterface(0x491B1dDA0A8fa069bbC1125133A975BF4e85a91b); } /** * Returns the latest price */ function getThePrice() public view returns (int) { bool isRaised = chainlinkFlags.getFlag(FLAG_ARBITRUM_SEQ_OFFLINE); if (isRaised) { // If flag is raised we shouldn't perform any critical operations revert("Chainlink feeds are not being updated"); } ( uint80 roundID, int price, uint startedAt, uint timeStamp, uint80 answeredInRound ) = priceFeed.latestRoundData(); return price; } } ``` #### Important Notes [#important-notes] * The flag should be checked using: `address(bytes20(bytes32(uint256(keccak256("chainlink.flags.arbitrum-seq-offline")) - 1)))`, which translates into **`0xa438451D6458044c3c8CD2f6f31c91ac882A6d91`**. * A **raised flag** indicates that the feed wasn't updated in "T" time and its data can be considered stale. This means the Sequencer went offline and your contract should not perform any critical operations. * When the Sequencer comes back up and feeds are updated, you can continue using your contracts as usual. ### Contract Addresses [#contract-addresses] *Note: These contract addresses are on L2 and should therefore only be read from L2.* | Name | Address | | :---------------------------------- | :------------------------------------------- | | **Arbitrum Mainnet Flags Contract** | `0x3C14e07Edd0dC67442FA96f1Ec6999c57E810a83` | | **Arbitrum Rinkeby Flags Contract** | `0x491B1dDA0A8fa069bbC1125133A975BF4e85a91b` | **Healthcheck Proxy Feed** returns **1** when the Sequencer is offline and **0** when the Sequencer is available. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Make an Existing Job Request (/chainlink/job-requests) Using an existing Oracle Job makes your smart contract code more succinct. This page explains how to retrieve the current weather temperature (in Kelvin) for a defined city using an existing Oracle job. ### OpenWeather Consumer [#openweather-consumer] In [Make a GET Request](https://docs.chain.link/any-api/get-request/introduction), the example contract code declared which URL to use, where to find the data in the response, and how to convert it so that it can be represented on-chain. In this example, we're using a job found on the Chainlink Market that is pre-configured to perform these tasks. This means that our contract doesn't need to specify additional parameters for various adapters, it only needs the Oracle address and the Job ID. The remaining adapters are configured by the external adapter, in particular `weather_cl_ea`. This example uses the Alpha Chain Kovan Oracle, which runs the OpenWeather Data Job. > Remember to fund your contract with LINK! > Making a job request will fail unless your deployed contract has enough LINK to pay for it. Learn how to [Acquire testnet LINK](https://docs.chain.link/resources/acquire-link) and Fund your contract. > [Deploy this contract using Remix ↗](https://remix.ethereum.org/#version=soljson-v0.6.7+commit.b8d736ae.js\&optimize=false\&evmVersion=null\&url=https://docs.chain.link/samples/APIRequests/OpenWeatherConsumer.sol\&lang=en) ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.7; import "@chainlink/contracts/src/v0.8/ChainlinkClient.sol"; /** * THIS IS AN EXAMPLE CONTRACT WHICH USES HARDCODED VALUES FOR CLARITY. * PLEASE DO NOT USE THIS CODE IN PRODUCTION. */ contract OpenWeatherConsumer is ChainlinkClient { using Chainlink for Chainlink.Request; address private oracle; bytes32 private jobId; uint256 private fee; uint256 public result; /** * Network: Kovan * Oracle: * Name: Alpha Chain - Kovan * Listing URL: [Alpha Chain - Kovan Listing](https://market.link/nodes/ef076e87-49f4-486b-9878-c) * Address: 0xAA1DC356dc4B18f30C347798FD5379F3D77ABC5b * Job: * Name: OpenWeather Data * Listing URL: [OpenWeather Data Job Listing](https://market.link/jobs/e10388e6-1a8a-4ff5-bad6-dd) * ID: 235f8b1eeb364efc83c26d0bef2d0c01 * Fee: 0.1 LINK */ constructor() { setPublicChainlinkToken(); oracle = 0xAA1DC356dc4B18f30C347798FD5379F3D77ABC5b; jobId = "235f8b1eeb364efc83c26d0bef2d0c01"; fee = 0.1 * 10 ** 18; // (Varies by network and job) } /** * Initial request */ function requestWeatherTemperature(string memory _city) public { Chainlink.Request memory req = buildChainlinkRequest(jobId, address(this), this.fulfillWeatherTemperature.selector); req.add("city", _city); sendChainlinkRequestTo(oracle, req, fee); } /** * Callback function */ function fulfillWeatherTemperature(bytes32 _requestId, uint256 _result) public recordChainlinkFulfillment(_requestId) { result = _result; } // function withdrawLink() external {} - Implement a withdraw function to a } ``` For more information on finding existing jobs, see **Find Existing Jobs**. ### What's Next [#whats-next] * **Find Existing Jobs** * **API Reference** * **Contract Addresses** --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Register Keeper Upkeep for a Contract (/chainlink/register-upkeep) After you deploy a Keeper-compatible contract, you must register it with the Chainlink Keeper Network. You can do this via the [Chainlink Keepers App](https://automation.chain.link/). After you register, you can interact directly with the registry contract functions such as `cancelUpkeep` and `addFunds`. ### Register and fund Upkeep on the Chainlink Keeper Network [#register-and-fund-upkeep-on-the-chainlink-keeper-network] 1. Connect your wallet with the button in the top right corner and choose a chain. The Chainlink Keeper Network currently supports Ethereum Mainnet or Kovan. upkeep-1 2. Click the Register new upkeep button upkeep-2 3. Fill out the registration form The information you provide will be publicly visible on the blockchain. Your email address will be encrypted. Make sure you have LINK to fund your Upkeep with. [Learn how to acquire testnet LINK](https://docs.chain.link/docs/acquire-link/). > **FUNDING NOTE** > You should fund your contract with more LINK that you anticipate you will need. The network will not check or perform your Upkeep if your balance could be too low based on current exchange rates. Your balance will be charged LINK based on a 20% premium over the gas cost to `performUpkeep`. There's currently a \~80k gas overhead from the registry. The premium and overhead are not fixed and will change over time. The gas limit of the example counter contract should be set to 200,000. 4. Press Register upkeep and confirm the transaction in MetaMask This will send a request to the Chainlink Keeper Network which will need to be manually approved. This is a temporary step during the Beta, and requests are automatically approved on testnets, so you should be up and running in a matter of minutes. upkeep-3 **Upkeep registration request submitted successfully** You can view your upkeep registration via button below. If it's pending approval, you will receive an email once it's approved. View transaction on Etherscan: [0xae676cf57fbcf8f998cd71653f30eb6d3b0f4b8c44c2a03d7c454c88e7a29e54](https://kovan.etherscan.io/tx/0xae676cf57fbcf8f998cd71653f30eb6d3b0f4b8c44c2a03d7c454c88e7a29e54) 5. Add funds to your Upkeep Your contract was provided initial funding as part of the registration step, but once this runs out, you'll need to add more LINK to your Upkeep. * Click **View Upkeep** or navigate back to the home page of the **[Chainlink Keepers App](https://automation.chain.link)** and click on your recently registered Upkeep. * Press **Add funds** button. * Approve the LINK spend allowance. upkeep-4 * Confirm LINK transfer transaction in MetaMask. upkeep-5 * Receive a success message and verify that the funds were added to the Upkeep. upkeep-6 ### How funding works [#how-funding-works] Your balance is reduced each time a Keeper executes your `performUpkeep` method. There is no cost for `checkUpkeep` calls. If you want to automate adding funds, you can directly call the `addFunds()` function on the `KeeperRegistry` contract. Anyone can call the `addFunds()` function, not just the Upkeep owner. To withdraw funds, cancel the Upkeep. ### Maintaining a minimum balance [#maintaining-a-minimum-balance] To ensure that the Chainlink Keepers are compensated for performance, there is an expected minimum balance on each Upkeep. If your funds drop below this amount, the Upkeep will not \[be performed] for your Upkeep, and the max gas multiplier (see `gasCeilingMultiplier` in configuration of the registry). It is recommended that you maintain a balance that is a multiple (3-5x) of the minimum balance to account for gas price fluctuations. ### Congratulations! [#congratulations] After you register your Upkeep, it has been approved, and you have added sufficient funds, the Chainlink Keeper Network will begin to simulate `checkUpkeep` calls and execute your contract's `performUpkeep` function as needed. You have now built and registered a Keeper Compatible contract with the Chainlink Keeper Network. Wohoo! --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Hive Apps Explorer (/hive/hive-apps-explorer) [Hive Apps Explorer](https://github.com/thisonedev/vault/tree/master/hive/hive-apps-explorer) is a blockchain explorer for Hive dapps. demo ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` https://github.com/thisonedev/vault.git ``` ### 2. Enter hive/hive-apps-explorer directory [#2-enter-hivehive-apps-explorer-directory] ``` cd hive/hive-apps-explorer ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ### Config [#config] Please add the following api endpoints to your .env file (root folder): ``` VITE_HIVE_MAINNET = 'https://api.openhive.network' VITE_STEEMENGINE_API = 'https://api.steem-engine.com/rpc' ``` ### Running a project [#running-a-project] ``` npm run dev ``` ### Building a project [#building-a-project] ``` npm run build ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Hive DAO (/hive/hive-dao) [Hive DAO](https://github.com/thisonedev/vault/tree/master/hive/hive-dao-vue) is a governance/proposal system for Hive blockchain. demo ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` https://github.com/thisonedev/vault.git ``` ### 2. Enter hive/hive-dao-vue directory [#2-enter-hivehive-dao-vue-directory] ``` cd hive/hive-dao-vue ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ### Config [#config] Please add the following api endpoints to your .env file (root folder): ``` VUE_APP_HIVE_MAINNET = https://api.openhive.network ``` ## Running a project [#running-a-project] ``` npm run dev ``` ### Building a project [#building-a-project] ``` npm run build ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # HivedScan (/hive/hivedscan) [Hivedscan](https://github.com/thisonedev/vault/tree/master/hive/hivedscan) is an all-in-one blockchain explorer for Hive-based dapps. The project contains the following components: 1. Hive DAO - a decentralized budgeting and governance system 2. Hive Engine - a platform for creating tokens via smart contracts 01 ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` https://github.com/thisonedev/vault.git ``` ### 2. Enter hive/hivedscan directory [#2-enter-hivehivedscan-directory] ``` cd hive/hivedscan ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ## Running a project [#running-a-project] ```bash npm start ``` ## Building a project [#building-a-project] ```bash npm build ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Collections SDK Reference (/myria/collections) This document is a reference to the **Collections module** of the Myria Core SDK. The module contains information about Myria collections. ### Interfaces [#interfaces] #### **CreateCollectionParams** [#createcollectionparams] Data structure passed to `createCollection()` method, which contains required data to create a new collection. **Attributes**: * **name** - collection name * **collectionImageUrl** - url for main collection image * **description** - collection description * **iconUrl** - url for collection icon * **contractAddress** - contract address used to withdraw assets to the Ethereum network * **ownerPublicKey** - public key of the collection owner * **metadataApiUrl** - api url that will store collection metadata * **starkKey** - Stark Key, has to start with 0x * **projectId** - project id of the collection ```typescript interface CreateCollectionParams { name: string; collectionImageUrl?: string; description?: string; iconUrl?: string; contractAddress: string; ownerPublicKey: string; metadataApiUrl: string; starkKey: string; projectId: number; } ``` #### **CreateCollectionResponse** [#createcollectionresponse] Data structure returned by the `createCollection()` method. **Attributes**: * **id** - collection id * **createdAt** - when the collection was created * **updatedAt** - when the collection was updated last time * **name** - collection name * **collectionImageUrl** - url for main collection image * **description** - collection description * **iconUrl** - url for collection icon * **contractAddress** - contract address used to withdraw assets to the Ethereum network * **ownerPublicKey** - public key of the collection owner * **metadataApiUrl** - api url that will store collection metadata * **starkKey** - Stark Key, has to start with 0x * **pubicId** - public id of the collection ```typescript interface CreateCollectionResponse { id: number; createdAt: string; updatedAt: string; name: string; collectionImageUrl: string; description: string; iconUrl: string; contractAddress: string; ownerPublicKey: string; metadataApiUrl: string; starkKey: string; pubicId: string; } ``` #### **GetCollectionParams** [#getcollectionparams] Data structure passed to `getCollectionList()` method, which contains required parameters for querying collections. **Attributes**: * **limit** - the max number of collections to return per response * **page** - the page number of returned collections based on the defined limit * **isHot** - whether the collection should be included in the hot section on the marketplace ```typescript interface GetCollectionParams { limit?: number; page?: number; isHot?: boolean; } ``` #### **CollectionDetailsResponse** [#collectiondetailsresponse] Data structure that contains collection details response. ```typescript interface CollectionDetailsResponse {} ``` #### **CollectionDetailsResponseData** [#collectiondetailsresponsedata] Data structure that contains collection details response data. **Attributes**: * **id** - collection id * **createdAt** - when the collection was created * **updatedAt** - when the collection was updated last time * **name** - collection name * **collectionImageUrl** - url for main collection image * **description** - collection description * **iconUrl** - url for collection icon * **contractAddress** - contract address used to withdraw assets to the Ethereum network * **ownerPublicKey** - public key (wallet address) of the collection owner * **metadataApiUrl** - api url that will store collection metadata * **starkKey** - Stark Key, has to start with 0x * **publicId** - public id of the collection * **metadataSchema** - an array of MetaDataShema * **project** - ProjectResponseData object ```typescript interface CollectionDetailsResponseData { id: number; createdAt: string; updatedAt: string; name: string; collectionImageUrl: string; description: string; iconUrl: string; contractAddress: string; ownerPublicKey: string; metadataApiUrl: string; starkKey: string; publicId: string; metadataSchema: any[]; project: ProjectResponseData; } ``` #### **CollectionListResponse** [#collectionlistresponse] Data structure returned by the `getCollectionList()` method. **Attributes**: * **id** - collection id * **createdAt** - when the collection was created * **updatedAt** - when the collection was updated last time * **name** - collection name * **collectionImageUrl** - url for main collection image * **description** - collection description * **iconUrl** - url for collection icon * **contractAddress** - contract address used to withdraw assets to the Ethereum network * **ownerPublicKey** - public key of the collection owner * **metadataApiUrl** - api url that will store collection metadata * **starkKey** - Stark Key, has to start with 0x * **publicId** - public id of the collection * **isHot** - whether the collection should be included in the hot section on the marketplace * **metadataSchema** - an array of MetaDataShema * **project** - ProjectResponseData object ```typescript interface CollectionListResponse { id: number; createdAt: string; updatedAt: string; name: string; collectionImageUrl: string; description: string; iconUrl: null; contractAddress: string; ownerPublicKey: string; metadataApiUrl: string; starkKey: string; publicId: string; isHot: boolean; metadataSchema: MetaDataSchema[]; project: ProjectResponseData; } ``` #### **MetaDataSchema** [#metadataschema] Data structure that contains metadata schema each item in the collection will follow. **Attributes**: * **god**: string * **name**: string * **type**: number * **attack**: number * **rarity**: number * **element**: string * **product**: number * **imageUrl**: string * **collectable**: true * **animationUrl**: string * **animationUrlMimeType**: string ```typescript interface MetaDataSchema { god: string; name: string; type: number; attack: number; rarity: number; element: string; product: number; imageUrl: string; collectable: true; animationUrl: string; animationUrlMimeType: string; } ``` #### **CollectionMetadataSchemaParams** [#collectionmetadataschemaparams] Data structure passed to `createCollectionMetadataByAddress()` method. **Attributes**: * **name** - metadata schema field name * **type** - metadata schema field type * **filterable** - whether a field should be filterable in the marketplace ```typescript interface CollectionMetadataSchemaParams { name: string; type?: string; filterable?: boolean; } ``` #### **CollectionMetadataResponse** [#collectionmetadataresponse] Data structure returned by the `getCollectionMetadataByAddress()` method. **Attributes**: * **name** - metadata schema field name * **type** - metadata schema field type * **filterable** - whether a field should be filterable in the marketplace ```typescript interface CollectionMetadataResponse { name: string; type?: string; filterable?: boolean; } ``` #### **CreateCollectionMetadataResponseType** [#createcollectionmetadataresponsetype] Data structure that contains an array of metadata schema fields. **Attributes**: * **metadata** - metadata schema fields ```typescript interface CreateCollectionMetadataResponseType { metadata: any[]; } ``` *** ### Methods [#methods] #### **createCollection()** [#createcollection] Creates a collection. **Parameters**: * CreateCollection object **Returns**: * Returns a collection object. **Example** ```typescript createCollection(payload: CreateCollectionParams): Promise; import { CollectionManager, CreateCollectionParams, CreateCollectionResponse, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const collectionManager: CollectionManager = new CollectionManager(env); const params: CreateCollectionParams = { name: "COLLECTION_NAME", description: "COLLECTION_DESCRIPTION", contractAddress: "CONTRACT_ADDRESS", metadataApiUrl: "METADATA_API_URL", ownerPublicKey: "OWNER_PUBLIC_KEY", projectId: "PROJECT_ID", starkKey: "STARK_KEY", }; const newCollectionResponse: CreateCollectionResponse | undefined = await collectionManager.createCollection(params); })(); ``` **Response**: * CreateCollectionResponse #### **getCollectionList()** [#getcollectionlist] Returns a list of collections. **Parameters**: * GetCollectionParams object **Returns**: * Returns an object with response call status and the data object that contains a list of collections. **Example** ```typescript getCollectionList(params?: GetCollectionParams): Promise> | undefined>; import { CollectionManager, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const collectionManager: CollectionManager = new CollectionManager(env); const collectionListResponse = await collectionManager.getCollectionList(); })(); ``` **Response**: * CreateCollectionResponse #### **getCollectionById()** [#getcollectionbyid] Returns a collection by its id. **Parameters**: * **id** - collection id **Returns**: * Returns an object with response call status and the data object that contains information about the project. **Example** ```typescript getCollectionById(id: number): Promise; import { CollectionManager, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const collectionManager: CollectionManager = new CollectionManager(env); const collectionResponse = await collectionManager.getCollectionById(COLLECTION_ID); })(); ``` **Response**: * CollectionDetailsResponse #### **getCollectionMetadataByAddress()** [#getcollectionmetadatabyaddress] Returns metadata of the collection. **Parameters**: * **contractAddress** - contract address used to withdraw assets to the Ethereum network **Returns**: * Returns an object with response call status and the data object that contains information about the collection's metadata. **Example** ```typescript getCollectionMetadataByAddress(contractAddress: string): Promise | undefined>; import { CollectionManager, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const collectionManager: CollectionManager = new CollectionManager(env); const collectionResponse = await collectionManager.getCollectionMetadataByAddress("CONTRACT_ADDRESS"); })(); ``` **Response**: * CollectionMetadataResponse #### **getCollectionByPublicId()** [#getcollectionbypublicid] Returns a collection by its public id. **Parameters**: * **publicId** - public id of the collection **Returns**: * Returns an object with response call status and the data object that contains information about the collection. **Example** ```typescript getCollectionByPublicId(publicId: string): Promise | undefined>; import { CollectionManager, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const collectionManager: CollectionManager = new CollectionManager(env); const collectionResponse = await collectionManager.getCollectionByPublicId(COLLECTION_PUBLIC_ID); })(); ``` **Response**: * CollectionDetailsResponseData --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Mint Transactions (/myria/mint-transactions) **Adding an ERC721 asset** to a collection is commonly known as **"minting"** that asset. You can mint assets by running a **mint transaction** through the **Myria SDK**. After the assets are minted, you can use them in your project or game, or show them together with other items in a collection. Currently, Myria supports mint transactions for **ERC721 tokens** (also known as NFTs), which are used to identify items in a unique way. You can read more about **ERC721 tokens here**. Upcoming versions of Myria's developer platform will include support for fungible **ERC20 tokens**. ### Creating ERC721 mint transactions [#creating-erc721-mint-transactions] #### Prerequisites [#prerequisites] * Generate a **Web3 public key and Stark Key**, and register your developer account entity as described in the **quickstart**. * Create a **project** as described here. * Create a **collection** as described here. #### ERC721 minting flow [#erc721-minting-flow] 1. Run a **script** to submit a new mint transaction. 2. Myria will attempt to **mint an asset** based on the data provided. 3. If the mint succeeds, the asset status is set to `MINTED`, and Myria creates a transaction with `Prepare` status. When a transaction is confirmed on the **Myria chain**, its status is set to `Success`. 4. If the mint fails, Myria returns an asset object with `MINT_FAILED` status. No asset is minted and transaction details are not included. ### Asset Token Id [#asset-token-id] Each asset has a `tokenId` that represents a **unique identifier** of that asset within the collection. If you provided the correct `metadataApiUrl` format as an argument when you were creating a collection, then you will be able to access your minted asset via the following URL structure: * **URI** - `metadataApiUrl` from a given collection. * **TOKEN\_ID** - unique token identifier of the mintable asset within that collection, which should be an **incremental value**. **Example URL:** [https://gateway.pinata.cloud/ipfs/QmSjWbBS3rPu5K2TnhyXmwGE1GcVZMRFKg5K3iML](https://gateway.pinata.cloud/ipfs/QmSjWbBS3rPu5K2TnhyXmwGE1GcVZMRFKg5K3iML) ### Limitations [#limitations] The following are known **limitations** for all mint transactions: * You can create a **maximum of 50,000 mint transactions** per collection every month. * A mintable asset **has to belong to a collection** and cannot be removed after it's created. * You cannot perform a mint transaction if the collection's contract doesn't implement the `mintFor()` function. * The mintable assets should follow the **ERC721 standard**. * Each `tokenId` should be **unique**. If a non-unique `tokenId` is submitted, you will not be able to mint your asset. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Minting SDK Reference (/myria/minting) This document is a reference to the Minting module of the Myria Core SDK. The module contains information about Myria mint transactions. ### Interfaces [#interfaces] #### **MintERC721Params** [#minterc721params] Data structure passed to `createMintTransactionERC721()` method, which contains required data to create a new ERC721 mint transaction. **Attributes**, * **starkKey** - Stark Key, has to start with 0x * **contractAddress** - contract address used to withdraw assets to the Ethereum network * **uri** - URL path to the mintable asset metadata * **tokenId** - unique identifier of a given asset, should be an incremental numeric value starting from 1 * **description** - description of a given asset * **fees** - an array of fees details for a given asset. FeeType accepts: ROYALTY , TAKER , ```typescript interface MintERC721Params { starkKey: string; contractAddress: string; uri: string; tokenId: string; description?: string; fees: [ { percentage: number; receiptAddress: string; feeType: FeeType; } ]; } ``` #### **MintERC721Response** [#minterc721response] Data structure returned by the `createMintTransactionERC721()` method. **Attributes** * **status** - response status: success, fail * **data** - response data ```typescript interface MintERC721Response { status: string; data: any; } ``` #### **GetMintedTransactionParams** [#getmintedtransactionparams] Data structure passed to `getMintTransactionList()` method, which contains required parameters to get details of a given minted transaction. **Attributes** * **transactionId** - unique id of a minted transaction ```typescript interface GetMintedTransactionParams { transactionId: number; } ``` #### **GetMintedTransactionResponse** [#getmintedtransactionresponse] Data structure passed to `getMintTransactionList()` method, which contains required data to get details of the minted asset., **Attributes**, * **status** - response status: success, failure * **data** - response data * **updatedAt** - date of the latest transaction update * **vaultId** - vault id * **transactionStatus** - transaction status * **createdAt** - date of transaction creation * **starkKey** - Stark Key, has to start with 0x * **transactionId** - unique transaction id * **transactionType** - transaction type * **batchId** - batch id * **quantizedAmount** - quantized amount * **assetId** - unique asset id ```typescript interface GetMintedTransactionResponse { status: string; data: { data: string; updatedAt: number; vaultId: number; transactionStatus: string; createdAt: number; transactionType: string; batchId: number; quantizedAmount: string; assetId: string; }; } ``` #### **GetMintedAssetsParams** [#getmintedassetsparams] Data structure passed to `getMintedAssetByStarkKey()` method, which contains required parameters to get a list of minted assets. **Attributes** * **starkKey** - Stark Key, has to start with 0x ```typescript interface GetMintedAssetsParams { starkKey: string; } ``` #### **GetMintedAssetsResponse** [#getmintedassetsresponse] Data structure returned by the `getMintedAssetByStarkKey()` method. **Attributes** * **status** - response status: success, fail * **data** - response data *** ### Methods [#methods] #### **createMintTransactionERC721()** [#createminttransactionerc721] Creates a mint transaction of an ERC721 asset. **Parameters** * MintERC721Params object **Returns** * Returns an object with response call status and the data object that contains details of the mint transaction., **Example** ```typescript interface GetMintedStarkKeyResponse { status: string; } createMintTransactionERC721(data: MintERC721Params): Promise; import { MintingManager, MintERC721Params, MintERC721Response, FeeType, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const mintingManager: MintingManager = new MintingManager(env); const params: MintERC721Params = { starkKey: "STARK_KEY", contractAddress: "CONTRACT_ADDRESS", uri: "TOKEN_URI", tokenId: "TOKEN_ID", description: "DESCRIPTION", royalties: [ { percentage: 10, receiptAddress: "ROYALTY_RECIPIENT_ADDRESS", }, ], }; const mintTransactionResponse: MintERC721Response | undefined = await mintingManager.createMintTransactionERC721(params); })(); ``` > **INFO** > Currently, royalties aren't supported. **Response** * MintERC721Response #### **getMintTransactionList()** [#getminttransactionlist] Returns details of the minted asset by a given transaction id. **Parameters** * GetMintedTransactionParams object **Returns** * Returns an object with response call status and the data object that contains details of the minted asset. **Example** ```typescript getMintTransactionList(data: GetMintedTransactionParams): Promise; import { MintingManager, GetMintedTransactionParams, GetMintedTransactionResponse, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const mintingManager: MintingManager = new MintingManager(env); const params: GetMintedTransactionParams = { transactionId: TRANSACTION_ID, }; const mintTransactionResponse: GetMintedTransactionResponse | undefined = await mintingManager.getMintTransactionList(params); })(); ``` **Response** * GetMintedTransactionResponse #### **getMintedAssetByStarkKey()** [#getmintedassetbystarkkey] Returns a list of minted assets by a given Stark Key. **Parameters** * GetMintedAssetsParams object **Returns** * Returns an object with response call status and the data object that contains a list of minted assets by a given Stark Key., **Example** ```typescript getMintedAssetByStarkKey(data: GetMintedAssetsParams): Promise; import { MintingManager, GetMintedTransactionParams, GetMintedTransactionResponse, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const mintingManager: MintingManager = new MintingManager(env); const params: GetMintedAssetsParams = { starkKey: "STARK_KEY", }; const mintStarkKeyResponse: GetMintedAssetsResponse | undefined = await mintingManager.getMintedAssetByStarkKey(params); })(); ``` **Response** * GetMintedAssetsResponse --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Projects SDK Reference (/myria/projects) This document is a reference to the **Projects module** of the Myria Core SDK. The module contains information about Myria projects. ### Interfaces [#interfaces] #### **CreateProjectParams** [#createprojectparams] Data structure passed to `createProject()` method, which contains required data to create a new project. **Attributes** * **name** - project name * **companyName** - company name that will be working on the project * **contactEmail** - contact email * **starkKey** - Stark Key, has to start with 0x ```typescript interface CreateProjectParams { name: string; companyName: string; contactEmail: string; starkKey: string; } ``` #### **ProjectResponse** [#projectresponse] Data structure returned by the `createProject()` method. **Attributes** * **status** - registration status: success, failure * **data** - an object or array of `ProjectResponseData` ```typescript interface ProjectResponse { status: string; data: ProjectResponseData[] | ProjectResponseData | undefined; } ``` #### **ProjectResponseData** [#projectresponsedata] Data structure that contains data value of `ProjectResponse`. **Attributes** * **id** - project id on the Myria network * **createdAt** - when the project was created * **updatedAt** - when the project was updated last time * **name** - project name * **companyName** - company name that will be working on the project * **contactEmail** - contact email * **collectionLimitExpiresAt** - expiration date of your current limit to create collections * **collectionMonthlyLimit** - the max number of collections to create each month for a given project * **collectionRemaining** - the number of collections remained to create this month * **publicId** - public id of your project within the Myria network * **starkKey** - Stark Key, has to start with 0x ```typescript interface ProjectResponseData { id: number; createdAt: string; updatedAt: string; name: string; companyName: string; contactEmail: string; collectionLimitExpiresAt?: string | null; collectionMonthlyLimit?: number; collectionRemaining?: number; publicId?: string; starkKey: string; } ``` #### **UpdateProjectParams** [#updateprojectparams] Data structure passed to `updateProject()` method, which contains required data to update a project. **Attributes** * **id** - project id on the Myria network * **name** - project name * **companyName** - company name that will be working on the project * **contactEmail** - contact email * **starkKey** - Stark Key, has to start with 0x ```typescript interface UpdateProjectParams { id: number; name: string; companyName: string; contactEmail: string; starkKey: string } ``` *** ### Methods [#methods] #### **createProject()** [#createproject] Creates a new Myria project. **Parameters** * `CreateProjectParams` object **Returns** * Returns a project object. **Example** ```typescript createProject(payload: CreateProjectParams): Promise; import { ProjectManager, CreateProjectParams, ProjectResponse, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const projectManager: ProjectManager = new ProjectManager(env); const params: CreateProjectParams = { name: "PROJECT_NAME", companyName: "COMPANY_NAME", contactEmail: "COMPANY_EMAIL", starkKey: "STARK_KEY", }; const newProjectResult: ProjectResponse | undefined = await projectManager.createProject(params); })(); ``` **Response** * `ProjectResponse` #### **getProjectDetail()** [#getprojectdetail] Returns details of the Myria project. **Parameters** * **id** - project id **Returns** * Returns an object with response call status and the data object that contains information. **Example** ```typescript getProjectDetail(id: string): Promise; import { ProjectManager, ProjectResponse, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const projectManager: ProjectManager = new ProjectManager(env); const projectDetailResponse: ProjectResponse | undefined = await projectManager.getProjectDetail("PROJECT_ID"); })(); ``` **Response** * `ProjectResponse` #### **getProjectList()** [#getprojectlist] Returns a list of available Myria projects. **Parameters** * No parameters. **Returns** * Returns an object with response call status and the data object that contains the list of projects. **Example** ```typescript getProjectList(): Promise; import { ProjectManager, ProjectResponse, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const projectManager: ProjectManager = new ProjectManager(env); const projectListResponse: ProjectResponse | undefined = await projectManager.getProjectList(); })(); ``` **Response** * `ProjectResponse` #### **updateProject()** [#updateproject] Updates a Myria project by a given id. **Parameters** * `UpdateProjectParams` object **Returns** * Returns a project object. **Example** ```typescript updateProject(payload: UpdateProjectParams): Promise; import { ProjectManager, UpdateProjectParams, ProjectResponse, EnvTypes } from "myria-core-sdk"; (async (): Promise => { // STAGING or PRODUCTION const env = EnvTypes.STAGING; const projectManager: ProjectManager = new ProjectManager(env); const params: UpdateProjectParams = { id: PROJECT_ID name: "PROJECT_NAME", companyName: "COMPANY_NAME", contactEmail: "COMPANY_EMAIL", starkKey: "STARK_KEY" }; const updatedProjectResult: ProjectResponse | undefined = await projectManager.updateProject(params); })(); ``` **Response** * `ProjectResponse` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Myria Quickstart (/myria/quickstart) Learn how to start integrating with Myria. *By the end of the quickstart, you will:* * Learn how to interact with MetaMask * Generate a Stark Key * Register a developer account on Myria ### Prerequisites [#prerequisites] * **Browser that supports MetaMask**: Chrome, Firefox, Brave, or Edge *** ### 1. Web3 Setup [#1-web3-setup] Myria integration requires a Web3 wallet address and the corresponding Stark Key derived from that wallet. The steps below show how to generate both of them. #### 1.1 Create a Web3 wallet [#11-create-a-web3-wallet] If you don’t have a Web3 wallet already, you need to create one. MetaMask is the most commonly used wallet. You can download it from the [official website](https://metamask.io/). After you install the wallet, follow these steps: 1. Select Create a Wallet 2. In the Help us to improve MetaMask section choose No Thanks to avoid data collection 3. Fill out and confirm your password 4. Backup your secret phrase 5. Finish the installation You should see your MetaMask wallet in the upper right corner. quickstart-1 #### 1.2 Export a private key [#12-export-a-private-key] Each wallet represents a set of public and private keys: * **The public key** - wallet address to receive funds * **The private key** - "master password" for making transaction signatures As a developer, you will often use public and private key pairs. Make sure to store them safely but have quick access when needed. To export the private key, open your MetaMask and follow these steps: 1. Click on **⋮** and select Account details 2. Select Export private key 3. Enter your password 4. Copy and save your private key quickstart-2 > Don't lose your private keys and seed phrases. Otherwise, you won't be able to recover your funds. #### 1.3 Generate a Stark Key [#13-generate-a-stark-key] Myria solution uses Starkware technology that implements different hash functions and signatures from Ethereum. Therefore, you must have a separate Stark Key to handle authentication and identity on Myria. You can generate your Stark Key Pair by deriving it from the Ethereum Key Pair via the [SDK Helper tool](https://myria.com/developer/sdk-helper). quickstart-3 **Things to consider:** * Each address can generate only one Stark Key. * The Stark Key format used in your app should look like this: `0x + STARK_KEY`. **Example:** ```text 0x43be26f8a75d1fc532a871ed88561f75fadd1a901b4fed01d0c8ef48762f1a9 ``` *** ### 2. Register a Developer Account [#2-register-a-developer-account] Developer accounts represent developer identities on Myria and required to do most of the operations on the network. You can register a developer account using the [Myria NFT Marketplace](https://myria.com/marketplace) as follows: 1. Select Connect Wallet 2. Click AGREE AND SIGN 3. Sign a transaction in your MetaMask quickstart-4 --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Myria Samples App (/myria/samples-app) ## Overview [#overview] [Myria Samples App](https://github.com/thisonedev/vault/tree/master/myria-samples-app) is a Typescript application that shows how to interact with the `myria-core-sdk` library. The code samples provided in this project will help create new Myria projects, launch collections, and mint assets on the Myria Chain. > [Original repo](https://gitlab.com/myriaworld/myrianet/blockchain/myria-ts-samples) ## Prerequisites [#prerequisites] 1. [Web3 Wallet: public and private key](https://docs.myria.com/docs/getting-started/myria-quickstart#1-web3-setup) 2. [Stark Key](https://docs.myria.com/docs/getting-started/myria-quickstart#13-generate-a-stark-key) 3. [Deployed Contract](https://docs.myria.com/docs/collections/collection-create#1-deploy-a-contract) 4. [Metadata API URL](https://docs.myria.com/docs/collections/collection-create#2-create-the-metadata-api-url) ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` https://github.com/thisonedev/vault.git ``` ### 2. Enter myria-samples-app directory [#2-enter-myria-samples-app-directory] ``` cd myria-samples-app ``` ### 3. Install dependencies [#3-install-dependencies] ``` yarn ``` ### 4. Provide environment variables [#4-provide-environment-variables] Rename the`.env.example` file into `.env` and provide the required configuration values: ``` # common PUBLIC_KEY= PRIVATE_KEY= STARK_KEY= # collection CONTRACT_ADDRESS= METADATA_API_URL= PROJECT_ID= # mint TOKEN_URI= TOKEN_ID= ``` ## Running the app [#running-the-app] ### 1. Common [#1-common] #### 1.1 Generate a Stark Key [#11-generate-a-stark-key] Generates a Stark Key derived from a given Web3 private key. Requirements: 1. Provide `PRIVATE_KEY` environment variable ```bash npm run generate-stark-key ``` ### 2. Projects [#2-projects] #### 2.1 Create a project [#21-create-a-project] Creates a project on Myria. Requirements: 1. Provide the `CONTRACT_ADDRESS` environment variable 2. Replace [params](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/projects/create-project.ts#L14) values with your project details: * `name` - the project name * `companyName` - the company name that will be working on the project * `contactEmail` - the contact email ```bash npm run create-project ``` #### 2.2 Get project list [#22-get-project-list] Returns a list of projects created on Myria. ```bash npm run get-project-list ``` #### 2.3 Get project details [#23-get-project-details] Returns details of a given Myria project by its id. Requirements: 1. Replace [projectId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/projects/project-details.ts#L7) value with your project id ```bash npm run get-project-details ``` #### 2.4 Update a project [#24-update-a-project] Update the project by its id. Requirements: 1. Provide the `PROJECT_ID` environment variable 2. Replace [params](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/projects/update-project.ts#L16) values with new project details: * `name` - new project name * `companyName` - new company name that will be working on the project * `contactEmail` - new contact email ```bash npm run update-project ``` ### 3. Collections [#3-collections] #### 3.1 Create a collection [#31-create-a-collection] Creates a collection on Myria. Requirements: 1. Provide `CONTRACT_ADDRESS`, `METADATA_API_URL`, `PUBLIC_KEY`, `PROJECT_ID`, `STARK_KEY` environment variables 2. Replace [params](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/collections/create-collection.ts#L18) values with your collection details: * `name` - collection name * `description` - collection description ```bash npm run create-collection ``` #### 3.2 Create a metadata schema [#32-create-a-metadata-schema] Creates a metadata schema for existing collections on Myria. Requirements: 1. Provide `CONTRACT_ADDRESS` and `STARK_KEY` environment variables 2. Replace [metadataSchema](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/collections/create-metadata-schema.ts#L16) values with your metadata schema details. Each object of the array contains the following properties: * `name` - the name of the metadata schema attribute. Should match `trait_type` in the [Opensea metadata schema](https://docs.opensea.io/docs/metadata-standards#attributes) * `type` - the type of the metadata schema attribute. Accepts `enum`, `string`, and `number`. In most cases, you should use `enum` * `filterable` - the flag that defines if the attribute should be filterable on the Myria marketplace. Accepts `true` or `false` ```bash npm run create-metadata-schema ``` #### 3.3 Get the collection list [#33-get-the-collection-list] Returns a list of collections created on Myria. Requirements: 1. Replace [params](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/collections/collection-list.ts#L8) values with your request parameters: * `limit` - the max number of items per request * `page` - the page number. Each page will contain the number of items based on the `limit` * `isHot` - the flag that defines if the returned items are listed as hot on the Myria marketplace ```bash npm run get-collection-list ``` #### 3.4 Get collection by id [#34-get-collection-by-id] Returns details of a given Myria collection by its id. Requirements: 1. Replace [collectionId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/collections/collection-by-id.ts#L7) value with your collection id ```bash npm run get-collection-by-id ``` #### 3.5 Get collection by public id [#35-get-collection-by-public-id] Returns details of a given Myria collection by its public id. Requirements: 1. Replace [publicId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/collections/collection-by-public-id.ts#L7) value with your collection public id ```bash npm run get-collection-by-public-id ``` ### 4. Mint transactions [#4-mint-transactions] #### 4.1 Create ERC721 mint transaction [#41-create-erc721-mint-transaction] Create an ERC721 mint transaction of a given asset on Myria. Requirements: 1. Provide `STARK_KEY`, `CONTRACT_ADDRESS`, `TOKEN_URI`, `TOKEN_ID` environment variables 2. Replace [feePercentage](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/mints/create-erc721-mint-transaction.ts#L13) value with a royalty fee percentage for secondary sales 3. Replace [description](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/mints/create-erc721-mint-transaction.ts#L26) value with a description for your asset ```bash npm run create-erc721-mint-transaction ``` #### 4.2 Mint multiple ERC721 assets [#42-mint-multiple-erc721-assets] Mint multiple ERC721 assets on Myria. There are two options you can use to achieve the same result. #### Option 1 [#option-1] The first option represents multiple `createMintTransactionERC721` calls. The number of calls equals the number of assets you need to mint. Requirements: 1. Provide `STARK_KEY`, `CONTRACT_ADDRESS`, `METADATA_API_URL`, `PUBLIC_KEY` environment variables 2. Replace [feePercentage](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/mints/create-bulk-erc721-mint-transaction.ts#L14) value with a royalty fee percentage for secondary sales 3. Replace [startTokenId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/mints/create-bulk-erc721-mint-transaction.ts#L15) value with a starting token id 4. Replace [endTokenId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/mints/create-bulk-erc721-mint-transaction.ts#L16) value with an ending token id ```bash npm run create-bulk-erc721-mint-transaction ``` #### Option 2 [#option-2] The second option represents a single `bulkMintableNftERC721` call that mints an array of assets passes as the `assets` parameter. It's recommended to use less than 100 items at a time with this option. Requirements: 1. Provide `STARK_KEY`, `CONTRACT_ADDRESS`, `METADATA_API_URL`, `PUBLIC_KEY` environment variables 2. Replace [feePercentage](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/mints/create-bulk-erc721-mint-transaction-v2.ts#L14) value with a royalty fee percentage for secondary sales 3. Replace [startTokenId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/mints/create-bulk-erc721-mint-transaction-v2.ts#L15) value with a starting token id 4. Replace [endTokenId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/mints/create-bulk-erc721-mint-transaction-v2.ts#L16) value with an ending token id ```bash npm run create-bulk-erc721-mint-transaction-v2 ``` #### 4.2 Get mint transaction details [#42-get-mint-transaction-details] Returns details of a given mint transaction by its id. Requirements: 1. Provide `STARK_KEY`, `CONTRACT_ADDRESS`, `TOKEN_URI`, `TOKEN_ID` environment variables 2. Replace [transactionId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/mints/mint-transaction-details.ts#L11) value with desired mint transaction id ```bash npm run get-mint-transaction-details ``` #### 4.3 Get mint transactions by Stark Key [#43-get-mint-transactions-by-stark-key] Returns a list of mint transactions by a given Stark Key. Requirements: 1. Provide `STARK_KEY` environment variable ```bash npm run get-mint-transactions-by-stark-key ``` ### 5. Assets [#5-assets] #### 5.1 Get assets by id [#51-get-assets-by-id] Returns details of a given Myria asset by its id. Requirements: 1. Replace [assetId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/assets/asset-by-id.ts#L6) value with your asset id ```bash npm run get-asset-by-id ``` #### 5.2 Get assets by Stark Key [#52-get-assets-by-stark-key] Returns assets by its Stark Key. Requirements: 1. Provide `STARK_KEY` environment variable ```bash npm run get-assets-by-stark-key ``` #### 5.3 Get assets by a public key [#53-get-assets-by-a-public-key] Returns all assets minted by a given public key. Requirements: 1. Provide `PUBLIC_KEY` environment variable ```bash npm run get-assets-by-public-key ``` #### 5.4 Get asset vault details [#54-get-asset-vault-details] Returns details of a given asset vault by its asset id. Requirements: 1. Provide `STARK_KEY` environment variable 2. Replace [assetId](https://github.com/MyriaPlatform/myria-ts-samples/blob/master/src/assets/asset-vault-details.ts#L7) value with your asset id ```bash npm run get-asset-vault-details ``` #### 5.5 Refresh asset metadata [#55-refresh-asset-metadata] Refresh metadata for a given asset by its asset id Requirements: 1. Provide `STARK_KEY` environment variable 2. Provide `ASSET_ID` environment variable ```bash npm run refresh-asset-metadata ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Community Points Engine (/omg-network/community-points) ## 1. Introduction [#1-introduction] ### 1.1 Overview [#11-overview] The main goal of the product is to give communities a means to create scalable points and rewards systems in a trustless manner. Due to technical limitations, the public blockchain infrastructure such as Ethereum cannot handle the required load of the modern points applications, thus a corresponding scaling solution should be introduced. [Community Points Engine](https://github.com/omgnetwork/community-points) (CPE) is a working proof of concept application that utilizes OMG Network as a trustless, high throughput settlement rail for community points transactions. The full demonstration consists of a working application, and this document which contains details on how special claim, burn, and subscription transactions can be implemented on the network. We demonstrate a full picture of how end users can have true ownership of community points and transact them in a manner that is fast, fee-less, trustless, and usable. All with the security guarantee offered by the Ethereum blockchain. The demonstration consists of 5 different components: * **Community Points Client**: a chrome plugin that simulates client application that demonstrates Web 2.0 usability. * **Community Points Server**: a fee relayer server that absorbs transaction fees for users. * **Community Points Contracts**: a set of smart contracts that govern ERC20 Tokens. * **Community Points Claim demo**: a script that demonstrates claim transaction. * **Community Points Admin Dashboard**: a MultiBaaS dashboard that gives an administrator/moderator simple access to make transactions and treasury management. The working application doesn't include the following components: * Design blueprint for complete implementation. * 25,000 subscriptions: due to time constraints, we were not able to demonstrate subscription transactions. However, we have proposed 2 designs for how this functionality could be implemented. ### 1.2 Glossary / Terminology [#12-glossary--terminology] * **CPE** - Community Points Engine. * **Community Points platform** - a platform where the Community Points system is being hosted, such as Reddit. * **Community Points server** - a server that allows performing fee-less transactions for users of a given Community Points platform. * **OMG Network** - a Layer 2 scaling solution for the Ethereum network. * **Rootchain** - the Ethereum network. * **Child chain** - the OMG Network. * **Plasma** - the name of a scaling solution of the OMG Network. * **Smart contract** - a self-executing contract that is running on a blockchain network, such as Ethereum. * **Mint/minting** - an event of issuing/creating new tokens on the Ethereum network. * **KARMA** - a reputation token that can be distributed by the Community Points platform to users on the OMG Network. These tokens allow users to claim points of a given community. * **ROCK** - a community point token for r/OMGnetwork. * **Burn/burning** - an event of eliminating existing tokens out of circulation on the Ethereum or OMG Network. This event implies that the tokens are sent to the non-recoverable address. * **Fee Relay** - a method to allow for a third party wallet application to absorb the transaction fee for an end-user. * **TCO** - a total cost of ownership. ### 1.3 Product Requirements [#13-product-requirements] ##### User Personas [#user-personas] * **Customers/community members** (e.g. subreddit community) - participants of a given Community Points system, service, network, website, portal, app, or forum who want to receive rewards, prizes, or discounts to stay more engaged. * **Moderator or admin** (e.g. subreddit moderator) - a person(s) who creates rules, coordinates users' activity, helps to solve problems within a particular Community Points system. * **Management team** (e.g. Reddit Community Points team) - a group of people who manage technical and operational requirements for a given Community Points system. ##### User Stories [#user-stories] * As a user, I can send tokens to another user via OMG Network in my browser while engaging with my community. * As a user, I can see the balance of my tokens and my username in the browser while engaging with my community. * As a user, I can view the history of transactions while engaging with my community. * As a user, I can purchase various digital items while engaging with my community. * As a moderator, I can mint, distribute, and burn tokens. * As a management team, I can absorb transaction fees for users. * As a management team, I'm sure that my production service can run on the OMG Network with an expected load. ### 1.4 Requirements [#14-requirements] The proposal fulfills all the below requirements. ##### Scaling [#scaling] Over a 5 day period, your scaling PoC should be able to handle: * 100,000 point claims (minting & distributing points) * 75,000 one-off points burning * 100,000 transfers ##### Decentralization [#decentralization] The solution takes numerous trade-offs in having a central point of control, but still maintains trustless ownership of user funds. ##### Usability [#usability] * Transactions complete in a reasonable amount of time (seconds or minutes, not hours or days). * Exiting is fast & simple. ##### Interoperability [#interoperability] * Scaling solution should be extensible and allow third parties to build on top of it. * APIs should be well documented and stable. * Documentation should be clear and complete. * Third-party permissionless integrations should be possible & straightforward. * Simple is better. Learning an uncommon or proprietary language should not be necessary. Advanced knowledge of mathematics, cryptography, or L2 scaling should not be required. Compatibility with common utilities & toolchains is expected. ##### Bonus Points [#bonus-points] * Build an extra use case for Community Points. ##### Security [#security] The proposed solution fulfills the following security criteria: * Balances and transactions cannot be forged, manipulated, or blocked by Reddit or anyone else. * Users should own their points and be able to get on-chain ERC20 tokens without permission from anyone else. * Points should be recoverable to on-chain ERC20 tokens even if all third-parties involved go offline. * A public, third-party review attesting to the soundness of the design should be available. ##### Bonus points [#bonus-points-1] * Public, third-party implementation review available or in progress. * Compatibility with HSMs & hardware wallets. ## 2. Proposed Solution / Design [#2-proposed-solution--design] ### 2.1 Demo Application Architecture [#21-demo-application-architecture] cm-1 ##### Community Points Client [#community-points-client] We are utilizing the web browser as the user interface for this demonstration due to the simplicity of integration with current ecosystem tooling. The currently supported browsers are Brave and Chrome. Here are different components to the interface: * **r/OMGnetwork**: the application is designed to work while the user is interacting in a specific community, in this case, it is r/OMGnetwork. This is also a way to introduce the product in a seamless manner and not risk breaking the experience of the Community Points platform. * **Web3 provider**: any Web3 provider that injects a Web3 object into the DOM, exposes the current user's Ethereum account balance, and supports EIP712 transaction signing. Because we are reliant on a non-custodial solution, users will have full ownership of funds. For the demonstration, we push the responsibility of Web3 and wallet provider to MetaMask. * **Community Points extension**: the user interface and core business logic for the user. It interacts with a few different services including the public Reddit API, Web3 provider, and fee relayer service. It currently offers multiple functionalities: * Transact community points without fee tokens. * Purchase items (e.g. Flair) with community points token. * Address identity via community usernames. * View balance, and transaction history. A browser extension is the easiest way to deploy and develop as a PoC. The Community Points client could be running on any other platform including natively on desktop and mobile as long as wallet signing APIs are provided. Our extension demonstrates how Community Points functionality can be introduced in a manner that is abstracted away from typical blockchain usability thus allowing the end-user to retain the same experience as community points transactions on regular Web 2.0. ##### Community Points Platform: Reddit [#community-points-platform-reddit] The Community Points Engine runs on top of an existing Community Points platform. In our case, we leverage Reddit's public API for the following functions: * **User identity**: to reduce complexity around maintaining usernames and wallet address relation, we rely on the Community Platform's API as the sole identity provider. However, a more robust or trustless identity approach could be introduced. * **Online items purchases**: we rely on authenticated API to fetch and redeem online items of each user. This allows a user on our platform to burn points in exchange for premium flair. ##### Community Points Server [#community-points-server] The server-side of the Community Points Engine is where most of the complexity is handled. The server consists of multiple horizontally scaled Node.js services connected to a relational database. The services can perform the following features: * **Fee-relayed transactions**: the clients of the CPE can make fee-less transactions. From the usability perspective, it means that the user can make transactions on the network without paying transaction costs. This is also a useful abstraction for user onboarding without requiring additional ERC20 tokens and ETH. Fee-relay transactions is a design pattern and can be implemented natively on the OMG Network's UTXO transaction model. * **Serve multiple concurrent client transactions**: we utilize different services as a way of handling complex UTXO management. This means that the higher load on the network will not deteriorate the experience of other users. More client applications may transact with Points at the same time. This service meets the requirements for better transactional scalability and usability while preserving Plasma security. * **Cloud-based HSM module**: Given that compromised private keys can have catastrophic consequences for operators, we ensure that different key management approaches and standards are possible. High throughput hot wallet transactors like fee relayers are best managed on a Cloud-based hardware security module to be compliant with enterprise best practices. This implementation utilizes the MultiBaaS module along with Azure Vault. We support modern operational standards and run this application inside a Docker container, orchestrated on Kubernetes with Google Cloud as the deployment target. However, infrastructure requirements can change based on the client's demand. ###### Admin/Moderator Dashboard [#adminmoderator-dashboard] Treasury and fund management are difficult to achieve on a public blockchain, especially for platform administrators and moderators who are non-crypto natives. We show that we can provide a highly usable abstraction for back-office operations via an admin dashboard provided on the MultiBaaS. Our community moderators can sign in via role-based access (RBAC) to make deposits, transactions, and Community Points distribution right on the dashboard without prior Web3 experience. They can have a choice to choose between non-custodial wallets such as MetaMask and Cloud HSM. ###### Blockchain Infrastructure [#blockchain-infrastructure] This is the settlement layer of community points transactions as well as how the Community Points Engine maintains its trustlessness guarantees. You can read more about the [Plasma protocol here](https://plasma.io). #### 2.1.1 Application Flow & Diagrams [#211-application-flow--diagrams] ##### Swimlane Diagrams [#swimlane-diagrams] 1. Display username and balance cm-2 2. Make a fee-less transaction cm-3 ##### Application Flow [#application-flow] 1. A user goes to a subreddit that supports community points (e.g. r/OMGnetwork). 2. An extension verifies that the user is located on a supported subreddit and prompts a signature request to connect via a Web3 wallet (e.g. MetaMask). 3. A user confirms the signature and appears on the main screen of the extension. 4. An extension fetches the user’s data from the Reddit Public API and presents this info to the extension interface. 5. A user fills the amount and recipient username and initiates the transaction request to a fee relayer via an extension. 6. An extension fetches and takes spendable user’s UTXO(s) that can cover the defined amount in the transaction. 7. An extension makes a POST request `/create-relayed-tx` to create a relayed transaction. 8. A fee relayer fetches its UTXO that can cover the transaction fee, and creates a transaction based on the user’s UTXO(s) and fee relayer’s UTXO. 9. A fee relayer requests a user to sign a relayed transaction. 10. A user signs a transaction with a Web3 wallet. If a user doesn’t sign a transaction, the extension cancels it by sending a POST request `/cancel-relayed-tx` to a fee relayer. 11. An extension sends a POST request `/submit-relayed-tx` to a fee relayer to submit a transaction. 12. A fee relayer signs the transaction and submits it to the OMG Network via the Watcher service. If you want the fee relayer to sign a transaction via HSM, you need to make a request to a MultiBaas platform first. 13. Child chain operator creates a block on the OMG Network and submits it to the Ethereum network. 14. After the transaction is confirmed, the user receives a notification and can view the transaction in the Block Explorer. #### 2.1.2 Server [#212-server] **Fee Relayer API** This section demonstrates a general overview of the Fee Relayer API. For more details, please refer to [Community Points Swagger document](https://swagger.io). ##### Create a Relayed Transaction [#create-a-relayed-transaction] Constructs a relayed transaction. ```bash POST /create-relayed-tx ``` ##### Attributes [#attributes] * **utxos** \[tx\_input] Yes Transaction UTXOs * **amount** BigNum, string, int Yes Amount of tokens to send * **to** string Yes Receiver address ##### Submit a Relayed Transaction [#submit-a-relayed-transaction] Submits a relayed transaction. ```bash POST /submit-relayed-tx ``` ##### Attributes [#attributes-1] * **tx** tx Yes Transaction body * **signatures** \[string] Yes A list of signatures to sign a transaction ##### Cancel a Relayed Transaction [#cancel-a-relayed-transaction] Cancels a transaction. ```bash POST /cancel-relayed-tx ``` * **tx** tx Yes Transaction body #### 2.1.3 Client [#213-client] ##### Views [#views] * **Main View**: The main view displays the name of the community points page (e.g. subreddit), the wallet address, and the current balance of the token that represents this particular Community Points system. A user should be able to copy the address by selecting it or clicking the copy button near the address. Additionally, the view contains Transfer, History, and Merch tabs that represent corresponding data or actions. By default, a selected tab is set to Transfer. * **Transfer View**: Each user should be able to transfer funds to another user. One should put an amount and a recipient address that can represent a username (e.g. subreddit account name) or an Ethereum address, and confirm the transaction with a Transfer button. The username should be searchable. cm-4 * **History View**: The History View contains a list of transaction history for a token that represents a defined points system, in which the user is currently located (e.g. r/OMGnetwork subreddit). Each transaction item includes: * An icon that represents sending or receiving of funds. * Sent or Received message for a corresponding transaction type. * Transaction status: Pending or Confirmed. * A wallet address of the recipient or sender (depending on transaction type). * The amount and token symbol. * A copy button that copies the recipient or sender. * Link to blockchain explorer (Rinkeby, Ropsten, or Mainnet). cm-5 * **Merch View**: The Merch View contains a list of digital goods (e.g. flair) a user can purchase. Each item should have its own icon and price. Each purchase is associated with certain metadata that defines a possessed item and implies the burning of tokens (sending tokens to non-recoverable address). cm-6 * **Notification Views**: An extension should notify users when: loading, on an unsupported community points page, missing MetaMask extension, not logged in with MetaMask, or connected to the wrong network. cm-7 ### 2.2 Proposed Contracts Design [#22-proposed-contracts-design] We try to balance implementation complexity with the necessary trustlessness requirement as outlined in the specs. However, tokenomics is a complex topic that requires a substantial amount of iterative design process. For the purpose of this application, we will treat the subscription process as a black box, while offering 2 design choices that Community Points can take into production with sample code for demonstration purposes. Each solution design makes tradeoffs in cost, complexity, and feature requirements. The proposed solutions to facilitate claims and subscriptions include: 1. Simple Claim and Subscription with full compatibility with current OMG Network V1. 2. Claim and Subscription as special OMG Plasma Framework transaction types. ##### 2.2.1 Smart Contracts [#221-smart-contracts] The current design consists of 4 contracts: * **Distribution**: This contract holds the main logic to decide how many community points (e.g. subreddit points) should be distributed on each round. This contract mints the community points according to the formula in this contract. For each round, it records the `baseSupply` and `availablePoints`. `baseSupply` is an integer that decreases a certain percentage on each round. The `availablePoints` is the amount of points that can be distributed on a certain round. `availablePoints` equals to `baseSupply` + 50% of the burned points on the previous round. * **Subreddit Point**: This is an ERC20 contract for the subreddit points. It should enable the Distribution contract to mint community points on each round. * **KARMA token**: This is a representative of KARMA. It is an ERC20 token that can be distributed by the Community Points platform (e.g. Reddit) to users on the OMG Network. Users can use the received KARMA to create a "Claim" transaction to receive points of a given community. * **Subscription token**: Instead of having an expiration date on each subscription, we use a simpler design where a subscription token represents the subscription status of a certain period. Proof of ownership of the token shows the subscription status. ##### 2.2.2 User Flow [#222-user-flow] * **Distribute KARMA to user**: Community Points platform (e.g. Reddit) should from time to time (or on-demand) mint KARMA token (ERC20) on the Ethereum and deposit it to the OMG Network. Community Points platform should send KARMA to its users according to their activities on the platform. * **User claiming community points**: With the KARMA given by Community Points platform, the user can ask for an atomic swap transaction as the claim of the community points. The server generating the transaction would provide the transaction with the community points according to the percentage of the KARMA amount and the total KARMA of the distribution round. After the transaction is generated, both the user and the Community Points server would sign the transaction then submit it to the OMG Network. * **User subscribes to a periodical (e.g. monthly) subscription**: The community owner would deploy and mint the subscription token contract every certain period. After that, the subscription token would be deposited to the OMG Network. For the user to subscribe, the user can ask for an atomic swap transaction that swaps the community points to the subscription token. ##### 2.2.3 Claim Transaction Demo [#223-claim-transaction-demo] The current implementation is based on the design outlined above. The demo represents a script that mints KARMA and RCP tokens (community points), deposits them to the OMG Network, and performs an atomic swap allowing a user to claim RCP. ###### Actors [#actors] * **Distributor** - an address responsible for KARMA and RCP tokens distribution. * **User** - an address that wants to claim community points (RCP tokens) in exchange for KARMA tokens. * **Community Points server** (e.g. subreddit server) - a server that handles claim transactions. ###### Application Flow [#application-flow-1] 1. Distributor mints a defined amount of KARMA, and RCP tokens from the smart contracts. 2. Distributor deposits ETH on the OMG Network to cover the fee costs. 3. Distributor approves KARMA and RCP tokens of a defined amount to make a deposit. 4. Distributor deposits KARMA and RCP tokens of defined amount on the OMG Network. 5. Distributor transfers a defined amount of KARMA tokens to the user on the OMG Network. 6. Distributor transfers a defined amount of RCP tokens to the Community Points server on the OMG Network. 7. User submits a signed (atomic swap) transaction to claim the RCP tokens. 8. Community Points server and Distributor sign the transaction. 9. Transaction is submitted to the OMG Network. 10. User receives a defined amount of RCP tokens. ###### Atomic Swap Description [#atomic-swap-description] The current demo uses an atomic swap to claim the community points based on the amount of KARMA tokens sent to its address during the distribution period. On a high-level, the swap represents an exchange of the same amount of RCP and KARMA tokens between a user and a Community Points server. The claim transaction requires 3 signatures: User (KARMA input), Distributor (fee token input), and Community Points server (RCP token input). Here\`s [an example](https://blockexplorer.ropsten.v1.omg.network/transaction/0xb394002ceeb80df2e05f12e21aad720a683343646a986ddc9e03981f017fc6fb) of a claim transaction: cm-8 ###### Production Considerations [#production-considerations] * **Minting**: In production, KARMA tokens should be minted by the contract owner only. RCP tokens may be minted by the correspondent Community Points moderator. * **Keys**: Keys for the Community Points engine and users are generated within the application, which is sufficient only for demo purposes. * **UTXO(s)**: The amount in UTXO(s) used for KARMA and RCP inputs should match the exact amount of tokens you want to swap. This is due to the limitation of 4 inputs and 4 outputs on the OMG Network. * **Timing**: The demo mints KARMA and RCP tokens on demand. In production, the owner may mint tokens beforehand. * **Environments**: The demo was tested on Ropsten and Rinkeby due to Ethereum network gas price on Mainnet. * **Fees**: The fee token on the Mainnet is OMG; on Ropsten and Rinkeby, it is ETH. * **Exchange Rate**: The KARMA/RCP exchange rate is hard-coded at 1:1. ## 3. Further Considerations [#3-further-considerations] ### 3.1 An Alternative Claim Transaction Design [#31-an-alternative-claim-transaction-design] The proposed implementation is one of the approaches to handle claim transactions. An alternative solution could be using special transaction types on the OMG Network. You can read a high-level overview of the potential implementation in this [document](https://docs.omg.network). ### 3.2 Third-party Services [#32-third-party-services] To run any OMG Network application, it's required to use the following services: * **Ethereum node**: to sync with the rootchain (e.g., [Infura](https://infura.io)). * **Web3 wallet**: to sign transactions (e.g., [MetaMask](https://metamask.io)). * **MultiBaas**: for an intuitive administration panel. ### 3.3 Cost and Performance [#33-cost-and-performance] We try to take the most pragmatic approach to cost and throughput assumptions with the business needs in mind while trying to be transparent whenever possible. #### 3.3.1 Throughput Performance [#331-throughput-performance] * **Maximum Theoretical Throughput**: Judge a Layer 2 performance based on its maximum throughput achievable by its design. * **Real Application Transaction Throughput**: We wanted to demonstrate the capabilities of our system for managing the Reddit Community Points ecosystem. We elected to use our public Integration environment on Ropsten. We use the acronym **ST4R** to mean "Stress Test For Reddit". * **100,000 Point Claims**: We performed 119,130 transactions over two hours using transaction metadata `ST4R CLAIM` (hex: `0x000000000000000000000000000000000000000000005354345220434c41494d`). * **25,000 Subscriptions**: Due to time constraints, we were unable to complete this part. We have two proposals [documented here](https://docs.omg.network). * **5,000 One-off Points Burning**: We sent 81,341 transactions to a `0x` address using metadata `ST4R BURN` (hex: `0x000000000000000000000000000000000000000000000053543452204255524e`). * **100,000 Transfers**: We performed 121,461 transactions over the course of four hours using metadata `ST4R`. **Watcher Query Examples:** ```bash curl --location --request POST 'https://watcher-info.ropsten.v1.omg.network/transaction.all' \ --header 'Content-Type: application/json' \ --header 'Accept: application/json' \ --data-raw '{ "metadata": "0x000000000000000000000000000000000000000000005354345220434c41494d" }' ``` ```bash curl --location --request POST 'https://watcher-info.ropsten.v1.omg.network/transaction.all' \ --header 'Content-Type: application/json' \ --header 'Accept: application/json' \ --data-raw '{ "metadata": "0x000000000000000000000000000000000000000000000053543452204255524e" }' ``` Alternatively, you can query via [https://blockexplorer.ropsten.v1.omg.network/](https://blockexplorer.ropsten.v1.omg.network/). #### 3.3.2 Cost [#332-cost] There is always a cost associated with operating a system. We believe cost and security go hand in hand. Gas cost per transaction is dependent on current gas market on Ethereum and the price of ETH. **Gas cost formula:** `ETH Price * Gas price * Gas used / Number of transactions in a block` **Example Gas Cost Table (at 49 Gwei, $332.53 ETH):** | Number of transactions per block | TPS (12s block time) | Gas cost per tx in $ | | :------------------------------- | :------------------- | :------------------- | | 100 | 8.333333333 | 0.01193842888 | | 1000 | 83.33333333 | 0.001193842888 | | 10000 | 833.3333333 | 0.0001193842888 | | 60000 | 5000 | 0.00001989738147 | ```bash curl --location --request POST 'https://watcher-info.ropsten.v1.omg.network/transaction.all' \ --header 'Content-Type: application/json' \ --header 'Accept: application/json' \ --data-raw '{ "metadata": "0x0000000000000000000000000000000000000000000000000000000053543452" }' ``` Currently, OMG Network charges transaction fees to end-users in the form of OMG tokens. The fee charged is 3x cheaper compared to the average Ethereum ERC20 transaction gas price. ### 3.4 Security Considerations [#34-security-considerations] #### Trustlessness vs Decentralization [#trustlessness-vs-decentralization] Although the network is reliant on the child chain operator, users do not need to put trust in the operator for the security of their funds. At any point, users can leave the network. Learn more about [Plasma fraud proofs here](https://docs.omg.network). #### Potential Threats [#potential-threats] * **Byzantine events**: Unchallenged exit, Invalid block, Block withholding, etc. * **Moderator manipulation**: malicous token governance. * **User error**: Loss of seed phrase or private key. * **Spam attack on fee relayer**: attack to deplete fee funds. #### Mitigation [#mitigation] * Byzantine events notify users to exit funds. * Moderator abuse mitigated by multisig enforcement. * Spam attacks mitigated by leveraging Reddit account whitelisting. * Watcher instances can be managed by the platform provider, node service, or core community members. ### 4. Resources [#4-resources] * Contracts Audits * Load Test Results * Tests: contracts, fee-relayer * FAQ * User Guide * Moderator Guide * Deployment Guide --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Exchange Use Case (/omg-network/exchange-use-case) *By the end of this guide you should know how an exchange can integrate with the OMG Network.* ### 1. Introduction [#1-introduction] #### 1.1 Overview [#11-overview] The main goal of this document is to demonstrate how a token issuer or an exchange can add an OMG Network support for depositing and withdrawing a particular ERC20 token (e.g. USDt). The integration with the OMG Network can significantly help the entire Ethereum ecosystem to offload a certain volume from the rootchain, as well as introduce faster and cheaper transactions with the same security guarantees as to the Ethereum network. > This document doesn't cover how exchange customers can deposit funds to the OMG Network. Please refer to the [Web Wallet Quick Start](wallet-use-case.mdx) for more details on this issue. #### 1.2 Requirements [#12-requirements] **User Personas** 1. **Customers** - participants and active users/traders of a given exchange. 2. **Integrator** - development and management staff at an exchange that evaluate the requirements and deliver the integration to the OMG Network. 3. **OMG Network** - a technical and management team within the OMG Network that supports the Integrator during the integration process. **User Stories** 1. As a customer, I can deposit ERC20 tokens (e.g. USDt) from the OMG Network compatible wallet to my exchange account. 2. As a customer, I can use deposited funds to make trades on a given exchange. 3. As a customer, I can withdraw ERC20 tokens from my exchange account into the OMG Network wallet (web or mobile). *** ### 2. Proposed Design [#2-proposed-design] The proposed design includes improvements to an existing exchange platform. However, there are no strict requirements one has to follow due to the distinct nature of given exchange infrastructure, development approach, UI/UX design, etc. #### 2.1 Integration Scope [#21-integration-scope] The scope for integrating with the OMG Network by a given exchange includes the following steps: **2.1.1 Generate ETH Addresses** As an exchange, you need to be able to generate new Ethereum addresses for your customers. The OMG Network reflects the same addresses as the Ethereum network, thus you don't need to implement extra logic for your platform's wallet. If you already have Ethereum supported, you shouldn't have any issues. Otherwise, you can create a new public/private key pair using [`web3.eth.accounts.create`](https://web3js.readthedocs.io/en/v1.2.0/web3-eth-accounts.html#create) function provided by the web3 library. Note, if the keys are generated by a third-party provider such as a custodian, the integrator must be able to sign a transaction for it with [EIP-712 signature](https://eips.ethereum.org/EIPS/eip-712) via `signTypedData_v3()` or `personalSign()`. See [eth-sig-util](https://github.com/MetaMask/eth-sig-util) for reference. > This document doesn't cover best practices for managing and storing keys due to a variety of methods different exchanges use to achieve a high level of security guarantees on their platform. **2.1.2 Query Blockchain** It's important to understand how to query data from the OMG Network. There are several things that might be important for any exchange: **Query transactions** * **Transaction details** - use `getTransaction(id)` function by the `omg-js` or `/transaction.get` endpoint of the Watcher Info API. * **Transactions details filtered by an address, block number, or metadata** - use `getTransactions(filters)` function by the `omg-js` or `/transaction.all` endpoint of the Watcher Info API. **Query accounts** * **Account balance** - use `getBalance(address)` function by the `omg-js` or `/account.get_balance` endpoint of the Watcher Info API. For more details, check \[Retrieve Balances]\(Retrieve Balances) guide. * **Account UTXO** - use `getUtxos(address)` function by the `omg-js` or `/account.get_utxos` endpoint of the Watcher Info API. * **Account transactions** - use `getTransactions(filters)` function by the `omg-js` or `/account.get_transactions` endpoint of the Watcher Info API. **Query network data** * **Network fees** - use `getFees` function by the `omg-js` or `/fees.all` endpoint of the Watcher Info API. You can find more details about these functions using the following resources: * [omg-js library](https://github.com/omgnetwork/omg-js) - the official JavaScript library that allows implementing the required functionality. * [omg-js documentation](https://docs.omg.network/omg-js) - a list of all functions of the `omg-js` library. * [omg-js-samples](https://github.com/omgnetwork/omg-js/tree/master/examples) - a JavaScript project that contains implementation for the core features of the OMG Network. * [Tutorials](https://docs.omg.network/network/start) - installation process, code samples, and various tips for using the `omg-js` library. * [Watcher Info API](https://docs.omg.network/elixir-omg/docs-ui/?urls.primaryName=master%2Finfo_api_specs) - an API specification of the Watcher's Informational Service. * [Blockchain Explorer](https://docs.omg.network/environments) - a tool that allows viewing transactions and blocks that happen on the network. **2.1.3 Make Deposits** The Deposit terminology for an exchange has a different meaning from a deposit on the OMG Network. It's very important to distinguish between those two: 1. **OMG Network deposit** - represents an ETH transaction to the corresponding `Vault` smart contract on the Ethereum network. This creates a new deposit on the OMG Network and allows the depositor to transact on the network until a user decides to withdraw them back to Ethereum. 2. **Exchange deposit** - represents a standard transaction on the OMG Network. A safe number of confirmations for a given exchange should equal to a safe number of confirmations on the Ethereum network. This is known as \[deposit finality period]\(deposit finality period) and is currently set to 10 blocks. The confirmations are counted on the Ethereum because the OMG Network relies on rootchain (Ethereum) security and creates blocks only when new transactions are being formed (i.e. on-demand). While implementing a deposit functionality on a given exchange, you should refer to the latter definition. You can implement this step using the [Make a Transfer](https://docs.omg.network/network/transfers) guide. Note, all of the code samples on the developer portal use Ropsten testnet as an example. The production version on the mainnet will have the same logic, except for the fees: * **Ropsten** - uses ETH as a fee * **Mainnet** - uses OMG token as a fee You can replace the `fee` object when constructing a transaction body with the OMG contract as follows: ```json fee: { currency: 0xd26114cd6ee289accf82350c8d8487fedb8a0c07 } ``` **2.1.4 Make Withdrawals** Withdrawals on a given exchange also represent a standard transaction on the OMG Network. Therefore, you can use the step above. Also, make sure to check for response type before signing a transaction. The existing implementation has two possible responses, one of them creates a merge transaction. You can find more details [here](https://docs.omg.network/network/merge-utxo). The same limitation applies to the `/transaction.create` endpoint of the Watcher Info API. **2.1.5 Merge UTXO** The OMG Network uses the UTXO-based model for keeping track of balances on its chain. Each transaction can have up to 4 UTXO as inputs and can create up to 4 UTXO as outputs. This means that depositing smaller amounts of funds will create UTXO of low value, and may cause potential issues during funds withdrawal due to the following: The first two outputs are used to cover the transferred value and transaction fee change, leaving only two outputs. Considering that it's very unlikely a user will withdraw the amount that equals a single available UTXO value, there will be another change output created. This means that the total number of UTXO you can use for a single withdrawal is 2. Therefore, it's recommended to check that your hot wallet has multiple UTXO of higher value during each withdrawal from an exchange. In general, we suggest every exchange client merge UTXO more frequently or even automate this process as a background service. Merge operations are free because they benefit the network. You can implement this functionality by following [Merging UTXO](https://docs.omg.network/network/merge-utxo) guide. **2.1.6 Setup a Watcher** Watcher is a service that guarantees data availability, secures the network, and allows to maintain the trustlessness of the OMG Network. It's recommended for every client to run a separate Watcher instance to rely on their own information source about the incoming deposits, transactions, exits, and byzantine events that happen on the OMG Network. It also means you fully trust the OMG Network operator with everything that occurs on the network. Running your own Watcher ensures that only valid transactions and blocks are created and confirmed by the childchain operator. There are several ways to deploy a Watcher. You can use the one you prefer the most via [this guide](https://docs.omg.network/network/watcher). **2.1.7 Deposit Funds to the OMG Network** After the core integration is done, you should deposit some funds to the OMG Network. This will allow customers to withdraw funds from an exchange account to the OMG Network compatible wallet. You can deposit funds using the [Deposit Funds](https://docs.omg.network/network/deposit-funds) guide or via one of our supported wallets. Refer to [Environments](https://docs.omg.network/network/environments) to find the list of wallets you can work with right now. **2.1.8 Rebalance Wallets** Lastly, you need to understand how to rebalance the corresponding hot and cold wallets. You can do this by sending funds to another wallet directly or withdraw funds back to the Ethereum network first. This step is fully covered in [Start a Standard Exit](https://docs.omg.network/network/standard-exit) guide, as well as in the [Web Wallet Quick Start](https://docs.omg.network/network/web-wallet-quick-start). Each withdrawal from the OMG Network requires to pass an exit period before you can retrieve your funds safely. Note, the exit period differs for each environment: * **Ropsten** - 86400 seconds (1 day) * **Mainnet** - 604800 seconds (1 week) #### 2.2 Integration UI [#22-integration-ui] Each exchange maintains a specific set of design principles, brand book, color palette, etc. Therefore, it's recommended to follow the established user flow and UX principles the users are already familiar with. Here's an example of the integration by one of our clients: ***Deposit View*** exchange-1 ***Withdrawal View*** exchange-2 --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # How to Manage a VPS (/omg-network/how-to-manage-vps) *By the end of this guide you should know how to set up, configure, and secure a VPS or dedicated server. The guide is useful for launching a Watcher instance or any blockchain node. It is required to have some basic knowledge of Linux.* ## Initial VPS Setup [#initial-vps-setup] ### 1. Work with VPS Provider [#1-work-with-vps-provider] A VPS is the most common way to run any blockchain infrastructure. It is a very efficient way to run a Watcher because it offers guaranteed uptime, redundancy in the case of hardware failure, and a static IP address that is required to use the installed Watcher instance during integration with the OMG Network. It is also possible to run a Watcher locally if you're an individual developer. The guide is using Digital Ocean as an example of VPS. However, Amazon EC2, Google Cloud, OVH, and Linode are also popular choices. It's recommended to choose a provider that supports a Docker daemon and a Postgres database. #### 1.1 Set up an Account and Project [#11-set-up-an-account-and-project] You need to have an account to start working with Digital Ocean. After your account is set up, you can create your first project. #### 1.2 Create a Droplet [#12-create-a-droplet] Digital Ocean uses Droplets to create a new server, either standalone or as part of a larger, cloud-based infrastructure. To create a new Droplet, click on the **New Droplet** button. There are a few things you need to configure before creating a Droplet. Consider using the following values: 1. **Image**: Ubuntu 16.04.6 (LTS) x64 or any other image that is listed on supported platforms list. 2. **Plan**: Basic with the pricing that matches the minimum hardware requirements. 3. **Block storage**: — 4. **Datacenter Region**: depends on your preference. 5. **VPC Network**: — 6. **Additional options**: — 7. **Authentication**: password. It is recommended to use SSH for increased security. The password option was chosen because some of the VPS providers don't provide SSH authentication out of the box. You'll learn how to set up the SSH further in the guide. 8. **The number of Droplets**: 1. 9. **Hostname**: an identifying name for your host. 10. **Tags**: any tags that will help to organize your servers, such as watcher, omg-network, etc. To finish the process, click the **Create Droplet** button. The creation of a Droplet might take a few minutes. As a result, you will see your server details. ### 2. Connect to VPS [#2-connect-to-vps] To connect to VPS, use `ssh` command from your terminal: ```bash ssh root@$REMOTE_SERVER ``` The SSH Client is available starting from Windows 10 version. For earlier versions, please use PuTTY or other alternatives to connect to a remote server. By default, OpenSSH Client is an optional feature. You need to install it if you're using it the first time with the following commands: 1. Go to **Settings > Apps**, select **Manage optional features**. 2. Click the **Add a feature** button. 3. Find **OpenSSH Client**, click **Install**. 4. Test if the client works with the `ssh` command in your terminal. When you connect to the server the first time, it will show the following message: Type `yes`. This will prompt you to enter a password. Note, all Linux systems don't reveal passwords when you type them, thus complete the process and click **Enter**. If your credentials are correct, you will see the following message: ```bash ssh root@$REMOTE_SERVER The authenticity of host '$REMOTE_SERVER' can't be established. ECDSA key fingerprint is SHA256: ... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '$REMOTE_SERVER' (ECDSA) to the list of known hosts. root@$REMOTE_SERVER's password: Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-169-generic x86_64) * Documentation: [https://help.ubuntu.com](https://help.ubuntu.com) * Management: [https://landscape.canonical.com](https://landscape.canonical.com) * Support: [https://ubuntu.com/advantage](https://ubuntu.com/advantage) 0 packages can be updated. 0 updates are security updates. ``` ## VPS Security (basic) [#vps-security-basic] ### 3. Change a Password [#3-change-a-password] Some of the server providers send the default login and password of the root user to your email. You must always change this password to a strong one. To change the password, use the `passwd` command. This will prompt you to type and repeat a new password. If everything is correct, you will see a success message: ```bash passwd Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully ``` ### 4. Replace Root Login [#4-replace-root-login] #### 4.1 Create a New User [#41-create-a-new-user] It's not recommended to do any changes with the system under a root user due to security concerns. However, you can create a regular user and give **super user** rights to allow executing commands at root access without having all of the root access to modify system files. To create a new user, use the following command: ```bash adduser $USER ``` Fill `$USER` with the name of the user you want to use instead of root. Then repeat a password for this user twice, and you can skip the other parts by pressing **Enter**: #### 4.2 Give Super User Rights To a New User [#42-give-super-user-rights-to-a-new-user] After a new user is created, one needs to have root access rights. This is accomplished with the following command: ```bash usermod -aG sudo $USER ``` This will add our user to a sudo group: ```text Adding user `rick' to group `sudo' ... Adding user rick to group sudo Done. ``` To test a connection with a new user, logout from your existing session and log in with the name of the user you've just created: ```bash logout && ssh $USER@$REMOTE_SERVER ``` Make sure to have both root and your new user passwords saved before doing any of the steps below. #### 4.3. Disable Root Login [#43-disable-root-login] To prevent brute force login attempts to the root account, it's recommended to disable root login. This is accomplished by changing configs in the `sshd_config` file using `nano` or `vi` text editors: ```bash sudo nano /etc/ssh/sshd_config ``` To prevent from login into root user, scroll to the **#Authentication** section and change the `PermitRootLogin` key from `yes` to `no` as follows: ```text # Authentication: LoginGraceTime 120 PermitRootLogin no StrictModes yes ``` Press `ctrl+o` (Linux/Windows) or `control+o` (macOS) to save and **Enter** to confirm the changes respectively. Then exit the file with `ctrl+x` or `control+x`. To apply the changes, restart SSH with the following command: ```bash sudo service ssh restart ``` Now if you try to log into your server with root via SSH, it won't work and return the `Permission denied, please try again` message. ### 5. Change the Default Port [#5-change-the-default-port] Another security measure to prevent people from making different types of attacks is to make it harder to find your SSH access port. You can change it in the `sshd_config` file by using the method from the previous step: ```bash sudo nano /etc/ssh/sshd_config ``` Scroll to the **# What ports, IPs and protocols we listen for** section and change the port number from `22` to any number higher than 100 or ideally 1000. Save the changes, restart the SSH, and logout from the server. If you try to access your server with default connections, you'll receive a `Connection refused` error. You'll need to specify a port number each time you login into the server as follows: ```bash ssh $USER@$REMOTE_SERVER -p $PORT ``` ## VPS Security (medium) [#vps-security-medium] ### 6. Change Authentication Method [#6-change-authentication-method] #### 6.1 Generate SSH Keys [#61-generate-ssh-keys] As was mentioned earlier, SSH keys allow a more secure method of authenticating to your server. To establish such a method, you need to have a pair of public and private keys on your laptop. Note, you should check for existing SSH keys and make a backup if they are available but you don't want to use them for this specific server. Open a terminal and run the following command: ```bash cd ~/.ssh ``` If you see `No such file or directory`, you don't have any SSH keys on your local computer. If you have a `.ssh` folder but you're not sure if you have any existing keys, use this command: ```bash ls id_* ``` If you have existing SSH keys but you don't want to use them, you can make a backup with the `cp` command: ```bash mkdir key_backup && cp id_rsa* key_backup ``` If you don't have any keys, create a new pair from your terminal: ```bash ssh-keygen -t rsa ``` Open a command prompt (Windows) and run the following command: ```bash cd %userprofile%/.ssh ``` If you see `No such file or directory`, you don't have any SSH keys on your local computer. If you have a `.ssh` folder but you're not sure if you have any existing keys, follow this command: ```bash dir id_* ``` If you have existing SSH keys, but you don't want to use them, you can make a backup with the `copy` command: ```bash mkdir key_backup && copy id_rsa* key_backup ``` If you don't have any keys, create a new pair from your command prompt: ```bash ssh-keygen -t rsa ``` You will be asked to choose the path to save the keys and a passphrase that will be used during login to the server. You can press **Enter** for both of the options to have a default path and no passphrase accordingly. If you're concerned that your SSH keys can be hacked or compromised, you might consider setting a password. The entire process will look as follows: ```bash ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key ($ID_RSA_DIR): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in $ID_RSA_DIR. Your public key has been saved in $ID_RSA_DIR. The key fingerprint is: SHA256: ... The key's randomart image is: +---[RSA 2048]----+ |++.o | |* o . | |E+ o o | |. ...+ o | | o.o.o S . | |.ooo.o . + | |ooooo o.o | | .== =.=.. | |o*B=ooO=o | +----[SHA256]-----+ ``` #### 6.2 Copy SSH Keys to Your Server [#62-copy-ssh-keys-to-your-server] After you've generated the SSH keys, you need to copy the public key to your server. You can do that with the `ssh-copy-id` command: ```bash ssh-copy-id $USER@$REMOTE_SERVER -p $PORT ``` Some of the versions of macOS may not support `ssh-copy-id` out of the box, so you need to install it first with `brew` or other alternatives: ```bash brew install ssh-copy-id ``` Then you can copy the public key: ```bash ssh-copy-id $USER@$REMOTE_SERVER -p $PORT ``` Windows currently doesn't support `ssh-copy-id` but you can use an alternative approach to achieve the same result. Run the following command from the Powershell as administrator: ```bash cat ~/.ssh/id_rsa.pub | ssh $USER@$REMOTE_SERVER -p $PORT "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" ``` If the keys were added successfully, you will be prompt to log in a passphrase you set up during SSH keys generation: ```bash Enter passphrase for key '$ID_RSA_DIR': ``` Otherwise, you will be logged in without a passphrase. #### 6.3 Disable Password Logins [#63-disable-password-logins] Disabling password logins is the last step of basic security measures for your server. Make sure to verify one more time that authentication with SSH keys works before disabling password logins. You can accomplish that with the following command: ```bash ssh $USER@$REMOTE_SERVER -p $PORT ``` You can disable password logins by changing the `sshd_config` file on your server as follows: ```bash sudo nano /etc/ssh/sshd_config ``` Scroll to **# Change to no to disable tunneled clear text passwords** section and change `PasswordAuthentication` from `yes` to `no` as follows: ```text PasswordAuthentication no ``` Save the changes, close the file, and restart the SSH service: ```bash sudo service ssh restart ``` ### 7. Remove IPv6 listening [#7-remove-ipv6-listening] By default, Linux servers are configured to listen on IPv6 ports in addition to the standard IPv4 ports. It's a common practice to disable IPv6 because it's not widely used yet and can cause certain issues with SSH. To remove IPv6 listening, run the following command: ```bash echo 'AddressFamily inet' | sudo tee -a /etc/ssh/sshd_config ``` Save the changes, close the file, and restart the SSH service. If you ever need IPv6 SSH back, remove the `AddressFamily inet` line. ## VPS Security (advanced) [#vps-security-advanced] ### 8. Set Up Firewall [#8-set-up-firewall] A firewall is the last point of contact before anyone on the internet can get into your server. Getting a firewall up is crucial before deploying a server online. The example below demonstrates `iptables` as a way to set up Firewall rules. However, you may choose another software you're more comfortable with, such as `ufw`, `firewalld`, etc. #### 8.1 Check the Current Iptables Rules [#81-check-the-current-iptables-rules] ```bash sudo iptables -S ``` #### 8.2 Install iptables-persistent [#82-install-iptables-persistent] On Ubuntu, the easiest way to save iptables rules without a server reboot is to use the `iptables-persistent` package. You can install it with the following command: ```bash sudo apt-get install iptables-persistent ``` During the installation, you will be prompt to save the current iptables rules. You can save them to be able to make a backup of the current configs in case something goes wrong. Make sure to have two active SSH connections to your server (two terminals) before following the rest of the guide. This will help to change configs back without rebooting the server. #### 8.3 Add Iptables Rules [#83-add-iptables-rules] Open iptables file: ```bash nano /etc/iptables/rules.v4 ``` Add the following values: ```text *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [985:1075980] :f2b-sshd - [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT # block invalid trafic -A INPUT -m state --state INVALID -j REJECT -A FORWARD -m state --state INVALID -j REJECT # to ensure fail2ban works correctly after iptables restore -A INPUT -p tcp -m multiport --dports $PORT -j f2b-sshd # SSH -A INPUT -p tcp --dport $PORT -j ACCEPT COMMIT ``` If the file is not empty, replace it with the content above. Press `ctrl+o` (Linux/Windows) or `control+o` (macOS) to save and **Enter** to confirm the changes respectively. Then exit the file with `ctrl+x` or `control+x`. Note, `$PORT` is a port you're using to connect to the server via SSH. The default value is 22 but if you follow this guide, it should be different by now. See **step 5** for reference. #### 8.4 Restore Iptables [#84-restore-iptables] `iptables-restore` is used to restore IP Tables from data specified on STDIN or in a file. The command should be used as follows: ```bash sudo iptables-restore < /etc/iptables/rules.v4 ``` #### 8.5 Restart Docker Services [#85-restart-docker-services] If you are using Docker or any other virtualization software, you may need to restart their services after doing an `iptables-restore`: ```bash systemctl restart docker && systemctl restart containerd ``` #### 8.6 Check the Result [#86-check-the-result] To check if you set up everything properly, use `nmap` or `netcat` tools as follows: ```bash nmap -sS -p $PORT -T4 $REMOTE_SERVER ``` Example output (for your server's port): ```text Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-02 19:06 FLE Daylight Time Nmap scan report for $REMOTE_SERVER Host is up (0.34s latency). PORT STATE SERVICE 1111/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 1.73 seconds ``` Example output (for the arbitrary port): ```text Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-02 19:04 FLE Daylight Time Nmap scan report for $REMOTE_SERVER Host is up (0.37s latency). PORT STATE SERVICE 2222/tcp filtered EtherNetIP-1 Nmap done: 1 IP address (1 host up) scanned in 4.01 seconds ``` Alternatively, you can use **Firewall Rule Test** to achieve the same result. ### 9. Set Up Fail2Ban [#9-set-up-fail2ban] Fail2ban scans log files and bans IPs that show malicious signs, such as too many password failures, seeking for exploits, etc. Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email) could also be configured. #### 9.1 Install Dependencies [#91-install-dependencies] To install the dependencies, use the `apt-get` command as follows: ```bash sudo apt-get install fail2ban sendmail ``` `sendmail` is an optional dependency used to send emails when new IP bans happen. #### 9.2 Check Fail2Ban Status [#92-check-fail2ban-status] When the dependencies are installed correctly, Fail2Ban status should indicate `active (running)`. You can verify this with the following command: ```bash service fail2ban status ``` #### 9.3 Configure Fail2Ban [#93-configure-fail2ban] To define Fail2Ban rules, you need to create a configurations file: ```bash sudo touch /etc/fail2ban/jail.local ``` Then, open the file in `nano` or `vi` text editor, paste the following values, and save the result: ```bash sudo nano /etc/fail2ban/jail.local ``` ```text [DEFAULT] # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = 127.0.0.1/8 $REMOTE_SERVER # "bantime" is the number of seconds that a host is banned. bantime = 3600 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 maxretry = 3 # Enable the SSH daemon jail. [sshd] enabled = true # Enable Email alerts destemail = user@example.com sendername = Fail2Ban sender = user@server action = %(action_mwl)s ``` For setting up custom configurations, refer to **Linode guide**. After the changes are saved, restart the Fail2Ban service as follows: ```bash sudo service fail2ban restart ``` Now, if anyone makes 3 failed attempts to log in to your server with the wrong SSH passphrase within 600 seconds, the corresponding IP will be banned for 3600 seconds. #### 9.4 Check Fail2Ban Status [#94-check-fail2ban-status] After the Fail2Ban is configured, you can check its status with the following command: ```bash sudo fail2ban-client status ``` Example output: ```text Status |- Number of jail: 1 `- Jail list: sshd ``` You can also poll the detailed status of individual jails, such as `sshd`: ```bash sudo fail2ban-client status sshd ``` Example output: ```text Status for the jail: sshd |- Filter | |- Currently failed: 0 | |- Total failed: 0 | `- File list: /var/log/auth.log `- Actions |- Currently banned: 0 |- Total banned: 0 `- Banned IP list: ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # How to Manage a Watcher (/omg-network/manage-watcher) *By the end of this guide you should know how to manage your Watcher installed on VPS or a dedicated server. The guide is useful for enterprise and individual clients who want to know how to manage their Watcher and receive notifications about its status, byzantine events, and alarms.* ## Goals [#goals] You should use this guide if you need to accomplish one of the following goals: * Monitor the uptime of your Watcher's server. * Automate regular Watcher status check. * Receive important alarms from the Watcher. * Know how to work with Watcher containers. ## Prerequisites [#prerequisites] 1. Active Watcher running on the VPS. 2. Basic knowledge of REST APIs. 3. Basic knowledge of Docker tooling. ## 1. Working with Docker Containers [#1-working-with-docker-containers] One of the ways to run a Watcher is using Docker containers. If you're new to Docker, these are the commands that should help you to solve the most common problems: ### Start/Stop/Restart/Update Docker Containers [#startstoprestartupdate-docker-containers] ```bash docker-compose -f docker-compose-watcher.yml start ``` #### Stop Only Watcher Containers [#stop-only-watcher-containers] ```bash docker-compose -f docker-compose-watcher.yml stop ``` #### Stop All Docker Containers [#stop-all-docker-containers] ```bash docker stop $(docker ps -aq) ``` #### Restart Only Watcher Containers [#restart-only-watcher-containers] ```bash docker-compose -f docker-compose-watcher.yml restart ``` #### Restart All Docker Containers [#restart-all-docker-containers] ```bash docker restart $(docker ps -aq) ``` ```bash docker pull omisego/watcher:latest && docker pull omisego/watcher_info:latest ``` ## 2. Server Uptime Monitoring [#2-server-uptime-monitoring] Watcher monitoring is one of the most important processes you need to set up if you're planning to work with the OMG Network over the long term. Receiving alarms and status changes can help to provide more accurate data for the services and applications you're building using the OMG Network, understand how reliable is your VPS provider, respond faster and more effectively to potential byzantine events on the network. ### 2.1 Status Cake [#21-status-cake] To monitor the status of your server, you can use [Pingdom](https://www.pingdom.com/), [Status Cake](https://www.statuscake.com/) or similar software that provides website/VPS monitoring functionality. If you're using Status Cake, go to the `MONITORING > Uptime Monitoring` section, and select `New Uptime Test`. Choose the `TCP` test type and fill in the required values, including your server's IP address, port, test name, and contact group that contains details about users who will receive notifications. statuscake Status Cake provides multiple ways to receive notifications, such as Datadog, Slack, Discord, Telegram, OpsGenie, etc. You can set your preferred method in the `ALERTING > Integrations` section. statuscake ## 3. Status Monitoring [#3-status-monitoring] Running the OMG Network's Watcher implies that you're running both `Watcher` and `Watcher Info` services that will serve separate [API endpoints](/api#watcher) and provide different access levels to the network. Most of the time you'll be using the `Watcher Info` service but you should monitor both. It is possible for `Watcher` and `Watcher Info` to become inactive, even if its server is up. This can happen due to sudden configuration changes, internet, or hardware issues with your VPS provider. There are a few ways to monitor the status of these services. The simplest way is to send corresponding API requests on a certain schedule. This guide demonstrates [Datadog](https://www.datadoghq.com/) as one of the tools you can use to monitor various parts of your infrastructure. ### 3.1 Watcher Status [#31-watcher-status] To monitor Watcher status, use the following steps: 1. Create [Datadog](https://www.datadoghq.com/) account. 2. Choose Ubuntu as OS for Datadog Agent. 3. Log in to the Watcher's server from your terminal: ``` ssh $USER@$REMOTE_SERVER -p $PORT ``` > * `$USER` - the name of the user with root privileges used to log into the remote server. Default: root. > * `$REMOTE_SERVER` - an ip address of your remote server. > * `$PORT` - a port used to connect to the server. Default: 22. 4. Paste the command from `New installation` to your server's terminal and press Enter: datadog The process may take a few minutes. After a successful installation on the server, your Datadog account will be redirected to the dashboard. 5. Go to `UX Monitoring > Synthetic Tests`. Click `Get Started` and select the `New API Test`. datadog 6. Fill in the following values and press `Test URL`: * URL method: `POST` * URL path: `http://$REMOTE_SERVER:7434/status.get` * Name: some indication about this specific endpoint, e.g. `Watcher Status` * Environment: environment name/identifier * Locations: locations you want your API to be tested from > - `$REMOTE_SERVER` - an IP address of your remote server. datadog 7. Specify the test frequency. Test frequency defines how often the API should be called. A general suggestion is 5-15 minutes. 8. Define assertions. Assertions are conditions required for a test to pass. Our main condition is for a Watcher to return `success` status. To do that, select the `success` field in the `BODY` result section. This will add the corresponding assertion as follows: datadog 9. Define alert conditions. Alert conditions help to set the number of failed tests, locations, retries needed to notify the team. 10. Set up notifications. You can notify your team via email, Slack, Jira, Webhook, or dozens of other tools. Check [Datadog Notifications](https://docs.datadoghq.com/video-categories/notifications/) for more info. 11. Monitor the result. You can monitor alerts, as well the status of your APIs in the `Events` or `UX Monitoring > Synthetic Tests` sections. datadog ### 3.2 Watcher Info Status [#32-watcher-info-status] Setting up the `Watcher Info` status check has the same approach as described above. When creating a new synthetic test, replace the Define request as follows: ``` http://$REMOTE_SERVER:7534/stats.get ``` Then, define assertions with `success:true` and follow the rest of the steps. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # How to Interact with Multibaas (/omg-network/multibaas) By the end of the guide you should know how to interact with Ethereum smart contracts using MultiBaas tool provided by Curvegrid. ## Goals [#goals] You should use this guide if you need to accomplish one of the following goals: Mint (issue / generate) ERC20 tokens. Burn (destroy) ERC20 tokens. Deposit ERC20 tokens to the OMG Network. ## Prerequisites [#prerequisites] 1. Chrome or Brave browser. 2. MetaMask wallet extension with $5-$10 worth of ETH. 3. Basic understanding of Ethereum blockchain. ## Overview [#overview] Traditionally, minting and managing ERC20 tokens involves help from a blockchain engineer that understands smart contracts. However, the goal of the OMG Network is to eliminate this barrier and deliver a product that can be used by any enterprise client. That's why we partnered with Curvegrid to provide an easy solution for software companies that plan on working with the Ethereum blockchain and the OMG Network. Curvegrid platform offers a rich REST API for developers, as well as an intuitive administrative panel to manage various smart contracts for regular users. This guide demonstrates how users/admins can use the latter option to manage ERC20 tokens. ## Issue ERC20 Tokens [#issue-erc20-tokens] To issue ERC20 tokens using MultiBaas use the following steps: 1. Create a Curvegrid account. During the sign up you will need to choose the Ethereum network you want to work with: * Ropsten/Rinkeby - the Ethereum testnets. All of the transactions that happen on these networks are for test purposes only. The funds used on Ropsten or Rinkeby are not real. * Mainnet - the Ethereum mainnet. All of the transactions that happen on this network are for production purposes. The funds used on this network are real, so make sure you don't lose access to them. * Curvegrid - the network created by Curvegrid, won't be covered during this guide. 2. Select CONTRACTS -> Contracts menu and choose Mlti Token contract: omg-20 3. Select DEPLOY / LINK CONTRACT: omg-21 4. Fill in the parameters for your new token. The values of the Parameters have the following descriptions: * Label - an internal label inside of the MultiBaas panel of the current contract. You may leave a default option or change it to the name of your token. * Owner - a public address (public key) of the owner of the Ethereum wallet that will issue and manage the tokens later. * Name - the name of your token (e.g. Morty). * Symbol - a short symbol of your token, usually it's 3-5 capitalized characters (e.g. MRTY or MRT). * Decimals - token's precision after a comma. You can put up to 18 decimal points (used by default). We do recommend to use this option only if you're planning to send smaller amounts of tokens (e.g if you put 2 decimals, you will have a chance to send 4.25 tokens). omg-22 5. Select an address to sign your transaction. When you're using MultiBaas the first time, you need to add a public key to the MetaMask wallet you will use to sign all of the transactions for your token. If you haven't set up a MetaMask wallet yet, feel free to use this guide. To sign a transaction, click select an address on the right side of the DEPLOY button. This will automatically offer a public key of the currently used MetaMask wallet. If the address is correct, press the + button as follows: omg-23 Then, add a label for your wallet (e.g. admin, moderator, core, test, etc): omg-24 6. Deploy the contract. Finally, select the address that you've just added, and click the DEPLOY. This will prompt a MetaMask popup. Press Confirm and wait for a few seconds: omg-25 If a transaction is successful, you will see the following confirmation message: omg-26 7. Verify The Result Congratulations, you've just created your first ERC20 token. To verify that the token was created, copy the contract address and paste it into Etherscan. 8. Change The Total Supply Of Your Token The last step is to change the total supply of your token. First, select Mlti Token contract on the left sidebar and choose your token as follows: omg-27 Then, scroll to the Mint method, enter the number of tokens you want to issue, and click SEND METHOD. This will prompt a MetaMask pop up that you need to confirm: omg-28 After confirming a transaction, you will see the following confirmation message: omg-29 To verify that the total supply was changed, copy a transaction hash to the Etherscan, and select the token name to view its details as follows: omg-30 > Note, you need to choose the correct network when working with the blockchain explorer. This guide demonstrates the token issuance on the Ropsten network. You can also check the total supply in the MultiBaas account of the Mlti Token page: omg-31 ## Burn ERC20 Tokens [#burn-erc20-tokens] Burning tokens event takes a defined number of tokens out of circulation. The procedure is similar to tokens' issuing. First, open the Mltitoken page and select your token. Then, enter the number of tokens to burn, and press SEND METHOD. This will prompt a MetaMask popup that you need to confirm: omg-32 After confirming a transaction, you will see the following confirmation message: omg-33 You can verify the result by checking token's details on Etherscan or your MultiBaas page: omg-34 ## Link OMG Network Contracts [#link-omg-network-contracts] Interacting with the OMG Network via MultiBass requires to link several smart contracts. You can find the corresponding values of your network in the Environments page. The values should be defined as follows: * Erc20vault: CONTRACT\_ADDRESS\_ERC20\_VAULT. * Eth Vault: CONTRACT\_ADDRESS\_ETH\_VAULT. * Plasma Framework: CONTRACT\_ADDRESS\_PLASMA\_FRAMEWORK. * Payment Exit Game: CONTRACT\_ADDRESS\_PAYMENT\_EXIT\_GAME. The steps below will show how to link Erc20Vault but it can be applied to any contract. Also, the example demonstrates how to work on the Ropsten network (testnet). Make sure to set up the Mainnet instance on the Curvegrid admin panel first if you need to work with the real funds. 1. Select the defined contract (e.g. Erc20 Vault) on the left sidebar, and click DEPLOY / LINK CONTRACT as follows: omg-35 2. Copy the value of the defined contract (e.g. Erc20 Vault): omg-36 3. Paste the value into the Contract Address field and press LINK as follows: omg-37 You should see a success confirmation after you linked the contract. 4. Go to the contract and verify that you retrieve the contract's events: omg-38 5. Repeat steps 1-4 for all OMG Network's contracts (mentioned at the beginning of this section). ## Deposit ERC20 Tokens To The OMG Network [#deposit-erc20-tokens-to-the-omg-network] To make transfers on the OMG Network, you need to deposit funds from the Ethereum network first. You may follow the Web Wallet Quickstart, however, you can achieve the same result with MultiBaas too. > Note, it's required to link smart contracts first before proceeding. To deposit ERC20 tokens to the OMG Network, use the following steps: 1. Select the OMG Network Helper under the MODULES section as follows: omg-39 2. Scroll to the Methods block, select the DEPOSIT tab, and choose the Deposit ERC20 contract. 3. Put the number of tokens you want to deposit and click the SEND METHOD button as follows: omg-40 This will prompt a popup that you need to confirm. If the token hasn't been used on the OMG Network before, you need to confirm two transactions: approval and deposit. Otherwise, you'll have to confirm only a deposit transaction. After the confirmation, you'll see a success message: omg-41 4. Verify that your tokens have been deposited to the OMG Network with a web wallet of the corresponding environment: omg-42 You may also verify the deposited tokens on the MultiBaas panel in the Erc20 Vault Events section: omg-43 ## Make An ERC20 Transaction On The OMG Network [#make-an-erc20-transaction-on-the-omg-network] MultiBaas provides a simple way to do transactions on the OMG Network. To make a transfer, use the following steps: > Note, it's required to link smart contracts first before proceeding. 1. Open the OMG Network Helper, scroll to the Methods section, and choose a TRANSACT tab: omg-44 2. Fill in the required fields: * Payable amount in wei - the amount of tokens you want to send to another user. * Currency - the token's smart contract. * Receiver - an Ethereum wallet address of the receiver of funds. * Metadata - an optional comment or extra information you want to state about this transaction (e.g. Present, Invoice, etc.). 3. Click SEND METHOD, and SIGN a transaction in the opened popup as follows: omg-45 4. Verify the result (optional). You can verify the transaction by copying its hash to the Block Explorer of the corresponding network, or check your Web Wallet: omg-46 --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Run a Watcher (/omg-network/run-watcher) By the end of this guide, you should know how to run a Watcher on your local machine, on VPS, or a bare-metal server. The guide is useful for enterprise clients who want to integrate with the OMG Network. ### Goals [#goals] You should use this guide if you need to accomplish one of the following goals: * **Rely on a personal Watcher** to verify transactions and receive network's events * **Host a redundant Watcher node** to secure the network * **Be an active participant** of the network ### Prerequisites [#prerequisites] 1. Basic knowledge of **Linux and blockchain technology** 2. A laptop/PC, a Linux-based VPS, or a bare-metal server 3. A **fully synced Ethereum client** An Ethereum client is required to synchronize transactions on the OMG Network with the Ethereum Network. The easiest way to have a full ETH client is to use one of the Ethereum infrastructure providers. Our team has tried **Infura** and **Geth** but other providers may work too. ### Supported Platforms [#supported-platforms] The Watcher has been tested on the following environments: * Ubuntu 16.04 * Ubuntu 18.04 * Alpine 3.11 * macOS 11.0.0 (local usage only) > Note, it might be possible to run a Watcher on other environments. Above are provided the systems that have been tested. ### Minimum Hardware Requirements [#minimum-hardware-requirements] The following hardware is required to run a Watcher: * **Storage**: 8GB SSD * **CPU**: 1 CPU Core with at least 2.2 GHz * **RAM**: 4GB * **Bandwidth**: 20 Mbps > The requirements are based on the network's load in Q3 2020. It is recommended to use hardware with higher performance to avoid a potential increase in transaction volume. ### Costs [#costs] The costs of running a Watcher include the following components: * A full Ethereum node (local or ETH provider) * VPS, bare-metal server, or local machine that matches the minimum hardware requirements * DevOps setup and maintenance fee ### Setup [#setup] Before installing Watcher service on a server or your local machine, you should have a few things setup: #### 1. Log in to Your Server [#1-log-in-to-your-server] If you're planning to install a Watcher on a remote server (VPS or bare-metal), make sure to have an active session open before proceeding. You can log in using the following command from your terminal or command prompt: ```bash ssh $USER@$REMOTE_SERVER -p $PORT ``` > * `$USER` - the name of the user with root privileges used to log into the remote server. Default: root. > * `$REMOTE_SERVER` - an IP address of your remote server. > * `$PORT` - a port used to connect to the server. Default: 22. #### 2. Check TCP ports [#2-check-tcp-ports] Make sure you have don't have any of the services running on one of the following ports: 7434, 7534, 5432. The ports are used as follows: * **7434**: **watcher**, a light-weight Watcher to ensure the security of funds deposited into the childchain * **7534**: **watcher\_info**, a convenient and performant API to the child chain data * **5432**: **postgres**, a PostgreSQL database that stores transactions and contains data needed for challenges and exits You can use `lsof`, `netstat` or other alternatives to check occupied ports: ```bash sudo lsof -i -n -P | grep LISTEN ``` If you found one of the ports is already in use, kill the process the port is occupied with as follows: ```bash sudo lsof -t -i:$PORT sudo kill -9 $PID ``` * `$PORT` - a port to clear from other processes * `$PID` - process ID listening on a defined port If you're already using Docker, verify these ports are free too: ```bash docker ps ``` #### 3. Update Packages [#3-update-packages] If you're using a Linux-based system, make sure to update your packages: ```bash sudo apt-get update ``` ### Install [#install] Running a Watcher locally is recommended for testing purposes only. For production, you should use VPS or a bare-metal server. This allows increasing uptime, reducing latency, and configuring advanced security measures for your instance. **Bare-metal (Ubuntu)** **Docker Compose (Ubuntu)** **Docker Compose (macOS)** This method shows how to install and run a Watcher from a bare-metal release of the `elixir-omg` repository. It is a recommended approach for production use. You can run it on VPS, dedicated, or bare-metal server on one of the supported environments. #### 1. Install Dependencies [#1-install-dependencies] ##### 1.1 Install Erlang and Elixir [#11-install-erlang-and-elixir] The current implementation is built with Erlang and Elixir and uses `asdf` to manage multiple runtime versions. `asdf` relies on several libraries that you may need to install first: ```bash git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.7.4 echo -e '\n. $HOME/.asdf/asdf.sh' >> ~/.bash_profile echo -e '\n. $HOME/.asdf/completions/asdf.bash' >> ~/.bash_profile source ~/.bash_profile ``` ```bash asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git asdf plugin-add erlang https://github.com/asdf-vm/asdf-erlang.git ``` ```bash asdf install erlang 22.3 asdf install elixir 1.10.2 asdf global erlang 22.3 asdf global elixir 1.10.2 ``` ```bash mix do local.hex --force, local.rebar --force ``` ##### 1.2 Install PostgreSQL [#12-install-postgresql] PostgreSQL is required to store Watcher's data, such as deposits, transactions, exits, and byzantine events. ```bash apt-get install postgresql postgresql-contrib ``` ```bash sudo -u postgres psql < ./env ``` * `$ETHEREUM_RPC_URL` - a full Ethereum node URL Above are provided the values for **OMG NETWORK MAINNET BETA V1**. If you want to work with another environment, please refer to environments. ##### 3.2 Apply Environment Variables [#32-apply-environment-variables] For the environment variables to take effect, run the command as follows: ```bash source ./env ``` Note, these values live within your current shell's context. So you need to run this command again on system restart, exiting the shell, etc. To permanently set these values, check the following thread. If you want to set up additional configurations, refer to deployment configuration document. #### 4. Install the Watcher [#4-install-the-watcher] ##### 4.1 Create a Directory for Geth [#41-create-a-directory-for-geth] ```bash mkdir data ``` ##### 4.2 Initialize Database [#42-initialize-database] ```bash _build/prod/rel/watcher_info/bin/watcher_info eval "OMG.DB.ReleaseTasks.InitKeyValueDB.run()" ``` Example output: ```text 2020-08-21 07:02:48.428 [info] module=OMG.DB.ReleaseTasks.InitKeyValueDB function=process/1 ⋅Creating database at "./data 2020-08-21 07:02:48.534 [info] module=OMG.DB.ReleaseTasks.InitKeyValueDB function=init_kv_db/1 ⋅The database at "./data/w$ ``` ##### 4.3 Migrate Database Tables [#43-migrate-database-tables] ```bash _build/prod/rel/watcher_info/bin/watcher_info eval "OMG.WatcherInfo.ReleaseTasks.InitPostgresqlDB.migrate()" ``` Example output: ```text 2020-08-21 07:03:37.008 [info] module=Ecto.Migration.Runner function=log/2 ⋅== Migrated 20180813131000 in 0.0s⋅ 2020-08-21 07:03:37.081 [info] module=Ecto.Migration.Runner function=log/2 ⋅== Running 20180813131706 OMG.WatcherInfo.Rep 2020-08-21 07:03:37.081 [info] module=Ecto.Migration.Runner function=log/2 ⋅create table transactions⋅ 2020-08-21 07:03:37.115 [info] module=Ecto.Migration.Runner function=log/2 ⋅create index unq_transaction_blknum_txindex⋅ 2020-08-21 07:03:37.125 [info] module=Ecto.Migration.Runner function=log/2 ⋅== Migrated 20180813131706 in 0.0s⋅ 2020-08-21 07:03:37.140 [info] module=Ecto.Migration.Runner function=log/2 ⋅== Running 20180813133000 OMG.WatcherInfo.Rep 2020-08-21 07:03:37.141 [info] module=Ecto.Migration.Runner function=log/2 ⋅create table ethevents⋅ 2020-08-21 07:03:37.171 [info] module=Ecto.Migration.Runner function=log/2 ⋅== Migrated 20180813133000 in 0.0s⋅ 2020-08-21 07:03:37.188 [info] module=Ecto.Migration.Runner function=log/2 ⋅== Running 20180813143343 OMG.WatcherInfo.Rep$ ``` ##### 4.4 Run Ethereum Tasks [#44-run-ethereum-tasks] ```bash _build/prod/rel/watcher_info/bin/watcher_info eval "OMG.WatcherInfo.ReleaseTasks.EthereumTasks.run()" ``` Example output: ```text 2020-08-21 07:06:57.631 [info] module=OMG.WatcherInfo.ExitConsumer function=init/1 ⋅Started OMG.WatcherInfo.ExitConsumer 2020-08-21 07:06:57.655 [info] module=OMG.WatcherInfo.ReleaseTasks.EthereumTasks function=run/0 ⋅Running Ethereum tasks.$ 2020-08-21 07:06:57.713 [info] module=OMG.WatcherInfo.ReleaseTasks.EthereumTasks.AddEthereumHeightToEthEvents function=ru ``` #### 5. Run the Watcher [#5-run-the-watcher] You can start a Watcher as follows: ```bash _build/prod/rel/watcher_info/bin/watcher_info start ``` But it's recommended to run this service in the background: ```bash _build/prod/rel/watcher_info/bin/watcher_info daemon ``` Example output: ```text 2020-08-21 08:17:33.195 [info] module=OMG.Watcher.BlockGetter function=handle_continue/2 ⋅Applied block: #2618000, from e 2020-08-21 08:17:33.335 [info] module=OMG.Watcher.BlockGetter function=handle_continue/2 ⋅Applied block: #2619000, from e 2020-08-21 08:17:33.465 [info] module=OMG.Watcher.BlockGetter function=handle_continue/2 ⋅Applied block: #2620000, from e 2020-08-21 08:17:33.596 [info] module=OMG.Watcher.BlockGetter function=handle_continue/2 ⋅Applied block: #2621000, from e 2020-08-21 08:17:33.721 [info] module=OMG.Watcher.BlockGetter function=handle_continue/2 ⋅Applied block: #2622000, from e 2020-08-21 08:17:33.854 [info] module=OMG.Watcher.BlockGetter function=handle_continue/2 ⋅Applied block: #2623000, from e 2020-08-21 08:17:33.986 [info] module=OMG.Watcher.BlockGetter function=handle_continue/2 ⋅Applied block: #2624000, from e 2020-08-21 08:17:34.084 [info] module=OMG.WatcherInfo.DB.Block function=insert_from_pending_block/1 ⋅Block #2618000 pers$ ``` #### 6. Update the Watcher [#6-update-the-watcher] Frequently there will be updates that you need to apply to your Watcher. First, pull the changes from the repo as follows: ```bash git pull ``` Then, repeat the steps starting from here. ### Verify [#verify] To verify that you're fully synced, check the status of Watcher and Watcher Info: **Watcher Info** `$REMOTE_SERVER` - an IP address of your remote server. If you run the Watcher on your local machine, replace the value with the `localhost`. ```bash curl -X POST "http://$REMOTE_SERVER:7534/status.get" ``` Example output: ```json { "data": { "byzantine_events": [], "contract_addr": { "erc20_vault": "0x070cb1270a4b2ba53c81cef89d0fd584ed4f430b", "eth_vault": "0x3eed23ea148d356a72ca695dbce2fceb40a32ce0", "payment_exit_game": "0x48d7a6bbc428bca019a560cf3e8ea5364395aad3", "plasma_framework": "0x0d4c1222f5e839a911e2053860e45f18921d72ac" }, "eth_syncing": false, "in_flight_exits": [], "last_mined_child_block_number": 2656000, "last_mined_child_block_timestamp": 1598017412, "last_seen_eth_block_number": 10704012, "last_seen_eth_block_timestamp": 1598018818, "last_validated_child_block_number": 2656000, "last_validated_child_block_timestamp": 1598017412, "services_synced_heights": [ { "height": 10704012, "service": "block_getter" }, { "height": 10703999, "service": "challenges_responds_processor" }, { "height": 10704000, "service": "competitor_processor" }, { "height": 10704002, "service": "depositor" }, { "height": 10704000, "service": "exit_challenger" }, { "height": 10704000, "service": "exit_finalizer" }, { "height": 10704000, "service": "exit_processor" }, { "height": 10703999, "service": "ife_exit_finalizer" }, { "height": 10704000, "service": "in_flight_exit_processor" }, { "height": 10703999, "service": "piggyback_challenges_processor" }, { "height": 10704000, "service": "piggyback_processor" }, { "height": 10704012, "service": "root_chain_height" } ] }, "service_name": "watcher_info", "success": true, "version": "1.0.3+cbbc2dc" } ``` **Watcher** `$REMOTE_SERVER` - an IP address of your remote server. If you run the Watcher on your local machine, replace the value with the `localhost`. ```bash curl -X POST "http://$REMOTE_SERVER:7434/status.get" ``` Example output: ```json { "data": { "byzantine_events": [], "contract_addr": { "erc20_vault": "0x070cb1270a4b2ba53c81cef89d0fd584ed4f430b", "eth_vault": "0x3eed23ea148d356a72ca695dbce2fceb40a32ce0", "payment_exit_game": "0x48d7a6bbc428bca019a560cf3e8ea5364395aad3", "plasma_framework": "0x0d4c1222f5e839a911e2053860e45f18921d72ac" }, "eth_syncing": false, "in_flight_exits": [], "last_mined_child_block_number": 2656000, "last_mined_child_block_timestamp": 1598017412, "last_seen_eth_block_number": 10703998, "last_seen_eth_block_timestamp": 1598018636, "last_validated_child_block_number": 2656000, "last_validated_child_block_timestamp": 1598017412, "services_synced_heights": [ { "height": 10703996, "service": "block_getter" }, { "height": 10703984, "service": "challenges_responds_processor" }, { "height": 10703986, "service": "competitor_processor" }, { "height": 10703988, "service": "depositor" }, { "height": 10703984, "service": "exit_challenger" }, { "height": 10703984, "service": "exit_finalizer" }, { "height": 10703984, "service": "exit_processor" }, { "height": 10703984, "service": "ife_exit_finalizer" }, { "height": 10703986, "service": "in_flight_exit_processor" }, { "height": 10703984, "service": "piggyback_challenges_processor" }, { "height": 10703986, "service": "piggyback_processor" }, { "height": 10703998, "service": "root_chain_height" } ] }, "service_name": "watcher", "success": true, "version": "1.0.3+cb41972" } ``` ### Test [#test] There are two ways to test that your Watcher is working properly: 1. Use `http://$REMOTE_SERVER:7534` as a `WATCHER_URL` value in your configs to make a transfer in your own or one of the OMG Network projects, such as `omg-js` samples. 2. Make a transaction or another operation using **Watcher Info API**. `$REMOTE_SERVER` - an IP address of your remote server. If you run the Watcher on your local machine, replace the value with the `localhost`. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # OMG Network Samples App (/omg-network/samples-app) [OMG Network Samples App](https://github.com/thisonedev/vault/tree/master/omgnetwork-samples-app) is a Javascript application that allows interacting with `omg-js` library. Examples provided in the project will help to deposit funds to the OMG Network, show the best ways to make transactions between the wallets, start and process exits, perform various operations with UTXOs, as well as challenge invalid exits. > [Original repo](https://github.com/omgnetwork/omg-js-samples) img ## Contents [#contents] | File/folder | Description | | ----------------------- | --------------------------------------------------------------------- | | `app` | Sample source files. | | `dist` | Build files that can be hosted on a server. | | `01-balances` | Implementation for retrieving root chain and child chain balances. | | `02-deposit-eth` | Implementation for depositing ETH to the OMG Network. | | `02-deposit-erc20` | Implementation for depositing ERC20 tokens to the OMG Network. | | `03-transaction-eth` | Implementation for making ETH transactions on the OMG Network. | | `03-transaction-erc20` | Implementation for ERC-20 transactions on the OMG Network. | | `04-utxos-merge` | Implementation for merging UTXOs of a given account. | | `04-utxo-show` | Implementation for showing UTXOs for a given account. | | `04-utxo-split` | Implementation for splitting UTXO for a given account. | | `05-exit-eth` | Implementation for exiting of ETH from the OMG Network. | | `05-exit-erc20` | Implementation for exiting of ERC20 tokens from the OMG Network. | | `05-exit-inflight-eth` | Implementation for in-flight exits of ETH funds from the OMG Network. | | `05-exit-process-eth` | Implementation for processing ETH exits on the OMG Network. | | `05-exit-process-erx20` | Implementation for processing ERC20 exits on the OMG Network. | | `helpers` | Scripts that help to run certain parts of code samples. | | `assets` | Project assets (images, css, fonts, etc). | | `index.js` | Script that generates UI for the project. | | `.gitignore` | Defines what to ignore at commit time. | | `package.json` | Package manifest for npm. | | `package-lock.json` | Package manifest for npm (extended). | | `config.js` | Configuration parameters for the sample. | | `webpack.config.js` | Webpack configurations. | | `CHANGELOG.md` | List of changes to the sample. | | `README.md` | Project's README file. | | `LICENSE` | The license for the sample. | ## Prerequisites [#prerequisites] * [Node](https://nodejs.org/en) >= 8.11.3 \< 13.0.0 * [Web3](https://github.com/ethereum/web3.js) > 1.2.2. Earlier versions have the issue with async functions. * Basic understanding of Ethereum and the OMG Network concepts: UTXOs, gas, smart contracts, deposits, transfers, exits, challenges. * Access to two Web3 wallets where you can export private keys. Consider using [MetaMask](https://metamask.io/download.html) if you want flexibility in working with ERC20 tokens. * Funds on both of the Web3 wallets. For working with a testnet, you can get free tokens using [MetaMask Ropsten faucet](https://faucet.metamask.io). ## API Documentation [#api-documentation] This project convers most of the functions of the `omg-js` library. If you need any extra info on specific functions or models, please refer to [omg-js API documentation](https://docs.omg.network/omg-js). ## Alice and Bob [#alice-and-bob] In most of the code samples, Alice refers to the account of a sender (Wallet A), Bob refers to the account that receives funds (Wallet B). Notice, all of the samples use Alice as the primary wallet. You can change this behavior in `.env` file. ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` https://github.com/thisonedev/vault.git ``` ### 2. Enter omgnetwork-samples-app directory [#2-enter-omgnetwork-samples-app-directory] ``` cd omgnetwork-samples-app ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ### 4. Create `.env` file and provide the required configuration values: [#4-create-env-file-and-provide-the-required-configuration-values] ``` ETH_NODE= WATCHER_URL= WATCHER_PROXY_URL= <*optional* proxy server to catch all watcher requests> PLASMAFRAMEWORK_CONTRACT_ADDRESS=
ERC20_CONTRACT_ADDRESS= <*optional* address of the erc20 contract that Alice will deposit and transfer to Bob> ALICE_ETH_ADDRESS=
ALICE_ETH_ADDRESS_PRIVATE_KEY= ALICE_ETH_DEPOSIT_AMOUNT= ALICE_ERC20_DEPOSIT_AMOUNT= ALICE_ETH_TRANSFER_AMOUNT= ALICE_ERC20_TRANSFER_AMOUNT= BOB_ETH_ADDRESS=
BOB_ETH_ADDRESS_PRIVATE_KEY= MILLIS_TO_WAIT_FOR_NEXT_BLOCK= BLOCKS_TO_WAIT_FOR_TXN= ``` * You can set up `ETH_NODE` by launching a local Ethereum node. But due to substantial time consumption this process requires, it's recommended using one of the services that provide such functionality for free: [Infura](https://infura.io), [QuickNode](https://www.quiknode.io), [Rivet](https://rivet.cloud). * If you encounter some issues with connecting to the network, make sure to check the latest details for `WATCHER_URL`, `PLASMAFRAMEWORK_CONTRACT_ADDRESS` on [the official documentation page](https://docs.omg.network/network-connection-details). * Put `WATCHER_PROXY_URL` only if you run your watcher. Otherwise, you might not be able to run any of the code samples in this project. * To find `ERC20_CONTRACT_ADDRESS` for a particular token you want to use, check [Etherscan Token Tracker](https://etherscan.io/tokens). If you're looking for ERC20 faucets, you can send 0 Ropsten ETH to a corresponding smart contract. Some of the projects typically send back test tokens to work with. Feel free to use the following configurations if you don't have time to set up your own: ``` WATCHER_URL=https://watcher-info.ropsten.v1.omg.network WATCHER_PROXY_URL= PLASMAFRAMEWORK_CONTRACT_ADDRESS=0x96d5d8bc539694e5fa1ec0dab0e6327ca9e680f9 ERC20_CONTRACT_ADDRESS=0xd74ef52053204c9887df4a0e921b1ae024f6fe31 ALICE_ETH_ADDRESS=0x8CB0DE6206f459812525F2BA043b14155C2230C0 ALICE_ETH_ADDRESS_PRIVATE_KEY=CD55F2A7C476306B27315C7986BC50BD81DB4130D4B5CFD49E3EAF9ED1EDE4F7 ALICE_ETH_DEPOSIT_AMOUNT=0.01 ALICE_ERC20_DEPOSIT_AMOUNT=20 ALICE_ETH_TRANSFER_AMOUNT=0.005 ALICE_ERC20_TRANSFER_AMOUNT=0.34 BOB_ETH_ADDRESS=0xA9cc140410c2bfEB60A7260B3692dcF29665c254 BOB_ETH_ADDRESS_PRIVATE_KEY=E4F82A4822A2E6A28A6E8CE44490190B15000E58C7CBF62B4729A3FDC9515FD2 MILLIS_TO_WAIT_FOR_NEXT_BLOCK=1000 BLOCKS_TO_WAIT_FOR_TXN=12 ``` > Private keys presented in this config file have only Ropsten testnet tokens. Please, spend them considerably, share with others. Make sure to never share your private keys to anyone if you deal with real funds (Ethereum mainnet). ## Running the sample [#running-the-sample] 1. Run the app: ``` npm run start ``` You will see a `dist` folder created with static `.js`, `.css` and `index.html` files. The project uses Webpack and Webpack server for demonstration purposes. Feel free to change it to your preferred way of building js files. 2. Open your browser at [http://localhost:3000](http://localhost:3000). 3. Select the sample you're most interested in on the left side, observe the logs on the right. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Wallet Use Case (/omg-network/wallet-use-case) *By the end of this guide you should know how a cryptocurrency wallet can integrate with the OMG Network.* ### 1. Introduction [#1-introduction] ##### 1.1 Overview [#11-overview] The main goal of this document is to demonstrate how a cryptocurrency wallet can add **OMG Network support for depositing, withdrawing, and transferring ETH and any ERC20 token**. The integration with the OMG Network can significantly help the entire Ethereum ecosystem to offload a certain volume from the root chain, as well as introduce faster and cheaper transactions with the same security guarantees as the Ethereum network. ##### 1.2 Requirements [#12-requirements] **User Personas** * **Customers** - participants and active users of a given cryptocurrency wallet. * **Integrator** - development and management staff of a wallet that evaluates the requirements and delivers the integration with the OMG Network. * **OMG Network** - a technical and management team within the OMG Network that supports the Integrator during the integration process. **User Stories** * As a customer, I can deposit ERC20 tokens from the Ethereum network onto the OMG Network without leaving my cryptocurrency wallet., * As a customer, I can send ERC20 tokens that have been deposited to my wallet to any OMG Network compatible wallet. * As a customer, I can withdraw deposited ERC20 tokens from my wallet back to the Ethereum network. ### 2. Proposed design [#2-proposed-design] The proposed design is based on the lessons learned during the development of the OMG Network mobile wallet, as well as extensive research, interviews, and customer development. The information provided here should be treated as a general suggestion, instead of clear rules that you absolutely must follow., ##### 2.1 Integration scope [#21-integration-scope] The scope for integrating with the OMG Network by a given cryptocurrency wallet includes several steps. The current scope is very similar to the \[Exchange Use Case Integration Scope]\(Exchange Use Case Integration Scope), thus some parts will be used as references to that use case to avoid redundant information. There are two ways a wallet can integrate with the OMG Network: * **Natively**: separate implementations for Android and iOS using Java/Kotlin or Objective-C/Swift respectively. * **Hybrid**: single implementation based on React Native. At the moment, we do not provide SDKs for Android and iOS yet, thus the first option can be more complicated because some of the **Watcher Info API** endpoints may not be available, and we cannot guarantee that external dependencies (`web3`, `crypto`, encoding/decoding utils, etc.) will behave the same way as they do with JavaScript libraries. We do provide React Native support for `omg-js` so you shouldn't have any issues using this approach. If possible, we suggest using the latter option because it is well tested by our team., ##### 2.1.1 Query blockchain [#211-query-blockchain] Querying blockchain is the most basic thing every integrator needs to know how to do. A wallet provider might be interested in retrieving data about transactions, accounts, deposits, and exits. You can find the full list of commands for this step in the \[Exchange Use Case]\(Exchange Use Case). *Implementation details:* The information about the token and its price currently have to be retrieved from different sources (Ethereum node, such as [Infura](https://infura.io), and one of the public price feeds, such as [Coinmarketcap](https://coinmarketcap.com), [Coingecko](https://coingecko.com), [AmberData](https://amberdata.io), or your existing price source), which makes it more difficult to display the full token details and the balance in different fiat currencies., ##### 2.1.2 Make Deposits [#212-make-deposits] It is required to have funds deposited into OMG Network first before making any transfer. You can implement this functionality by following \[Deposit Funds guide]\(Deposit Funds guide). *Implementation details:* Each deposit has a **deposit finality period** before it can be used on the network. Currently, this period equals **10 Ethereum blocks**. The confirmations are counted on the Ethereum because the OMG Network relies on rootchain (Ethereum) security and creates blocks only when new transactions are formed (i.e. on-demand). You may use the `waitForChildchainBalance` function from [omg-js documentation](https://docs.omg.network/omg-js/) or implement your custom helper/service for polling the expected amount after the deposit. ##### 2.1.3 Make Transfers [#213-make-transfers] Making transfers on the OMG Network has the same behavior as on other networks, blockchains, or payment systems. Currently, the network supports only payment transactions, more advanced types will be available in the future. This operation will occupy the majority of data load, thus should be treated with more focus. You can implement a standard transfer functionality using [Make a Transfer guide](https://docs.omg.network/guides/make-a-transfer), *Implementation details:* When you send a transaction, you will often use `account/get_utxos` endpoint to get information about the latest UTXOs. Current implementation returns only confirmed UTXOs that are not used for the pending transaction. One of the ways to mitigate this limitation is to block/disable your wallet UI to prevent sending other transactions until the current transaction is confirmed. Otherwise, you may encounter a `UTXO not found` issue., Alternatively, you can keep track of all of the UTXOs used for your transactions but this will create additional complexity for your application. omg-wallet-1 ##### 2.1.4 Make Withdrawals (Exits) [#214-make-withdrawals-exits] Using OMG Network as a value transfer layer offers a faster and cheaper alternative if your work requires frequent operations on the Ethereum network. Most of the time you will hold a certain amount of assets on the OMG Network, and periodically withdraw your funds back to Ethereum. This is the most complicated technical and UX flow. You can implement exits functionality using \[Start a Standard Exit guide]\(Start a Standard Exit guide)., *Implementation details:* 1. The entire exit flow for mobile can be very complicated. It involves dealing with challenges, invalid exits, covering standard and in-flight exits. Thus, if you don't have enough time and resources for implementing such functionality, we recommend not to include it in your wallet at all. Exits are perceived as a less frequent activity on a network and can be accomplished with a \[Web Wallet]\(Web Wallet) provided by the OMG Network team. 2. There's no endpoint to query exit data in the **Watcher Info API**. It is available only in `omg-js` library. ##### 2.2 Design Guideline [#22-design-guideline] Layer 2 mobile UI and UX can be challenging and confusing, thus our job is to make the user flows intuitive, appealing, and easy to navigate. Below you can see recommendations from our team. **Network Distinction** It's a good practice to have a clear visual distinction between the Ethereum path and the OMG Network path. It's not recommended to display token's balance on both networks together. Setting an obvious separate path helps users to interact with tokens on each network. Additionally, you can set up a switch action (e.g. button) that will help to switch between OMG Network and Ethereum. omg-wallet-2 **Deposits** 1. A user needs to have some ETH in their cryptocurrency wallet to cover the deposit fee. It's recommended to encourage users to deposit fee tokens first and inform about the fee model upfront. This can be mentioned in the tour/onboarding screens or your main screen as follows:, omg-wallet-3 2. Deposit is not as frequent operation as transfer, thus you may not need to add it to the quick actions panel. However, it has to be easily accessible and people should be aware of this functionality through a dedicated menu, intuitive UX flows, or onboarding. omg-wallet-4 3. The OMG Network has a different fee amount for different types of operations, including deposit fee, transfer fee, exit fee, and exit bond. Make sure to be explicit about those, as well as mention if the fee has a flat rate or dynamic rate. You might also set a fee with the highest amount as a default option., Additionally, you may mention that the transfer fee is charged in **OMG token**, the rest of the fees are in **ETH**. omg-wallet-5 **Transfers** 1. It might be confusing which network you're using while making a transfer. It's recommended to distinguish between Ethereum and OMG Network with different colors, labels, icons, etc. according to your brand book. omg-wallet-6 2. It's a good practice to set a default `Scan QR code` button for the network a user is currently on (Ethereum or OMG). It's not recommended to use a global scan as it creates an extra decision for a user to make. If possible, have a separate flow for each of the networks to create a clear and consistent association and mental model for a particular user., omg-wallet-7 3. Before making a transaction to an exchange or custodian wallet, ensure that the provider is already on the OMG Network. This can be accomplished by providing a validation message with corresponding color and text message. 4. It is possible to send existing funds on the OMG Network to any **non-custodial Ethereum address**. Thus, make sure to inform your users of such a possibility. The funds can be easily accessed with any OMG Network compatible wallet afterward., 5. It's a good practice to have a clear distinction in transaction history for both Ethereum and OMG Network. omg-wallet-8 **Withdrawals** 1. Make sure to inform withdrawal condition before allowing a user to proceed with exit submission. omg-wallet-9 2. Each withdrawal has to be processed separately. That's why suggesting your users merging UTXOs first is a great UX pattern. Note, you can't mix different ERC20 tokens during a single UTXO merge so plan your UI accordingly to match this behavior. 3. A good practice for Layer 2 UX is to notify users (via both UI and push notification) when the challenge period has already passed and you can withdraw your funds back to the Ethereum network. omg-wallet-10 ### 3. Setup a Watcher [#3-setup-a-watcher] Watcher is a service that guarantees data availability, secures the network, and allows to maintain the trustlessness of the OMG Network. It's recommended for every client to run a separate Watcher instance to rely on their own information source about the incoming deposits, transactions, exits, and byzantine events that happen on the OMG Network. It also means you fully trust the OMG Network operator with everything that occurs on the network. Running your own Watcher ensures that only valid transactions and blocks are created and confirmed by the childchain operator. There are several ways to deploy a Watcher. You can use the one you prefer the most via [Run a Watcher guide](./run-watcher.mdx). --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # OMG Network Web Wallet Quickstart (/omg-network/web-wallet) This guide shows how to perform OMG transactions using a Web Wallet in your browser. ## Goals [#goals] By the end of the guide, you will achieve the following: * Learn about the OMG Network interface. * Interact with the OMG Network from end to end. * Make a deposit, the first transaction, and exit with ETH and ERC20 token via the OMG Network. * Understand and apply the concepts behind Plasma and MoreVP. ## Who is This Guide For? [#who-is-this-guide-for] * OMG Network clients and integration partners. * Exchanges, wallets, and blockchain services. * Ethereum Dapps that want cheaper fees and more transactions. * Cryptocurrency enthusiasts or white hackers who enjoy testing new blockchain products. ## Prerequisites [#prerequisites] * Chrome browser. Other browsers, such as Brave, may have compatibility issues with Web3 wallets. * Web3 wallet, preferably MetaMask. * Basic knowledge of blockchain, Ethereum and Plasma. ## Notes [#notes] * Keep your tokens safe. Please ensure you understand how to store and send tokens without compromising security, always double-check the recipient\`s address, never send private keys to anyone unknown unless you want to lose your funds. * The quickstart guide uses a hosted Web Wallet application. To run it yourself, check the installation instructions in the [Github repository](https://github.com/omgnetwork/web-wallet). * The current guide displays how to work with OMG Web Wallet on Rinkeby environment. However, the same steps can be applied to the Mainnet version of the wallet. ## Wallet Configuration [#wallet-configuration] The Web Wallet currently supports two environments: * Rinkeby Testnet (testnet) - the Ethereum test network. The purpose of such an environment is to demonstrate all of the features without using or losing real funds and to find critical bugs before launching a software into production. This option is mostly used by developers.\* * Main Ethereum Network (mainnet) - the latest Ethereum live network. It is recommended to use this option after you've already tried the testnet and are confident in working with a particular wallet. This option is mostly used by customers.\* You can configure the preferred environment in your Web3 wallet as follows: omg-1 There are 3 methods to connect with the Web Wallet. Feel free to use the one you prefer the most: omg-2 ## Ledger [#ledger] If you want to sign transactions with a Ledger hardware wallet, choose Browser Wallet as your connection option. This will prompt a popup to verify that you're connected to Ledger. Connect the device and follow the required steps, then click YES. omg-3 Make sure to allow contract data in transactions in your Ethereum application and keep that application opened as follows: omg-4 To confirm your actions or change values in the settings, press both of the buttons with your fingers as shown above. Lastly, please check the following: 1. Your MetaMask is connected to Ledger. Otherwise, you will get an unauthorized spend. 2. Your Ledger firmware is v1.4.0+. The integration doesn't work with earlier versions. ## 1. Deposit Funds [#1-deposit-funds] ### 1.1 Fund Ethereum Wallet [#11-fund-ethereum-wallet] Before transacting on the OMG Network, you need to have ETH tokens on the rootchain. > In Plasma implementation rootchain refers to the Ethereum network, childchain refers to the OMG Network. There are several ways to fund your ETH wallet: * Purchase ETH with your credit card or bank account on one of the exchanges * Exchange ETH for cash with somebody who has it * Ask your friends who work in the blockchain industry to send you some * Use Ethereum faucets/games to win free ETH * Use Rinkeby faucet if you're planning to work with Rinkeby After you fund your Web3 wallet, your ETH rootchain balance in the Web Wallet should be the same, as your balance in MetaMask or another Web3 wallet you are using: omg-5 ### 1.2 Make an ETH Deposit [#12-make-an-eth-deposit] To make an ETH deposit, click the DEPOSIT button and fill in the amount as follows: omg-6 Next, press DEPOSIT and confirm the transaction in the opened popup. After it's confirmed you should see a pending deposit in your Deposits history as follows: omg-7 Deposits on the OMG Network require to pass a deposit finality period (currently 10 blocks) before the funds are accepted and can be used on the network safely. After a successful deposit, your childchain balance should be updated. This will also create a deposit UTXO validating that you have ETH on the OMG Network. ### 1.3 Make an ERC20 Deposit [#13-make-an-erc20-deposit] The process for depositing ERC20 into the OMG Network is very similar to an ETH deposit. For this example, we will use TUSDT token. To make a deposit, click the DEPOSIT button and choose the ERC20 tab. Fill in the amount of tokens you want to deposit and a smart contract of a defined token as follows: omg-8 This step will differ from the ETH deposit, as your Web3 wallet will pop up twice. The first popup will ask you to approve the deposit, the second — to confirm the actual deposit transaction. After you confirm both of the popups, you should see a pending deposit in your Deposits history. If a deposit is successful, your childchain balance should be updated as follows: omg-9 If you're doing a deposit via Ledger, you should follow the same steps as described above. However, you will also need to review and approve deposit approval and deposit transaction on your hardware device. Below you can see an example of deposit approval: omg-10 ### 2. Make a Transaction [#2-make-a-transaction] Now that you have funds on the OMG Network, you can make your first transaction. First, click on the Transfer button and fill in the recipient's address and the amount of ETH or ERC20 tokens you want to send as follows: omg-11 Second, press the TRANSFER button and confirm the transaction in the opened popup as follows: omg-12 Once the transaction is confirmed, you can view its details in the block explorer. After a successful deposit, your childchain balance should be updated. For sending a transaction via Ledger follow the steps above, then sign the transaction with your device as follows: omg-13 ### 3. Withdraw Funds [#3-withdraw-funds] ### 3.1 Submit an Exit [#31-submit-an-exit] You've successfully deposited and made a transfer to the OMG Network. If you want to move your funds from the OMG Network back to the Ethereum network, you should start a standard exit. To start an exit, press the EXIT button and choose one of the UTXO you want to exit as follows: omg-14 > Note, you can exit only 1 UTXO at a time. If you need to exit more funds than the value of a particular UTXO, you should merge them first. If a defined token hasn't been exited before, you'll need to add it to the exit queue as follows: omg-15 Next, press SUBMIT EXIT and confirm the transaction in the opened popup as follows: omg-16 Below you can see an example of exit approval on Ledger: omg-17 ### 3.2 Process an Exit [#32-process-an-exit] To prevent any malicious activity on the network, each exit goes through the Challenge Period. This allows other users to challenge their exit on validity and trust. You can find also find a date when you can process your exit below the transaction id. After the challenge period has passed, you can process your exit to send your funds back to the Ethereum network. To start an exit, press the Process Exit button near exit id as follows: omg-18 After, confirm the transaction in the opened popup as follows: omg-19 Most of the time, you're not the first to exit a defined token. That's why you may need to select the number of exits you want to process before you process your exit. As a general rule, use the maximum number that is offered to you. Otherwise, your exit may not be processed. Congratulations! You've performed an end-to-end process of interacting with the OMG Network. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Paytomat Integrates 1C (/paytomat/1c-integration) Any old-school businessman can tell you that your partners, as well as your employees, are one of the most valuable assets your business has. Because of this successful partnership strategy, you can discover new markets, receive valuable information, establish useful links, knock out business competitors, and much, much more. Although the crypto-world is a new phenomenon, the Partner rule applies here as well. In today’s piece, we are going to introduce one of the companies we integrated with — the 1C Company — and tell you why this cooperation will help Paytomat achieve a qualitatively new level in our project evolution. Let’s start with some theory. As we’ve said before, Paytomat relies on existing Point of Sale solutions, instead of separate merchants, and we believe such an approach has some undoubted advantages. * It is convenient because you don’t need to sell extra hardware or offer extra applications to merchants. * It is far-sighted because every POS has thousands of merchants, which makes their potential clients accept crypto. This means that every integration of these systems opens new markets to us. * It affects the development of the project. POSs have a big influence on payment industries, which increases the level of trust to Paytomat. * It is profitable: merchant doesn’t have to waste money and time to reorganize business processes or educate staff about implemented changes. For them, Crypto becomes just another type of payment. * And finally — It is promising. In the future, every POS device can become a lightweight node of PTM blockchain, which means we will receive permanent supporters for our network operation. Integration with 1C enables one to get all these benefits for Paytomat. However, there are some nuances in this case. Unlike R-keeper or Nobly, 1C is not exactly a POS solution. Officially, it positions itself as a company that specializes in the development, distribution, publishing, and support of mass-market software for automation of everyday enterprise activities. In a nutshell, it sells a set of software for enterprises called 1C: Enterprise. It’s a platform that contains everything you need in order to develop, debug, and run applications based on it. Anybody can download the product, register and start developing new apps or customize existing ones for their business needs. Thus, Integration means the automated data exchange between our solution and the 1C software merchant is using. It’s especially important for Paytomat that 1C has a built-in automated accounting and taxation solution that simplify the fiat gateways structure for the Paytomat software. The integrated solution looks like this. ptm-8 ptm-9 ### About 1C [#about-1c] Founded in 1991, 1C Company cooperates with 8,000 dealers from 600 cities today. To this date, according to official data, more than 1,000,000 companies use 1C: Enterprise programs. Among them, there is a number of small businesses, for example, a bakery near your house, as well as large international corporations with locations around the world. 1C is also known as a game developer with entertainment software being sold worldwide through distribution partners in North America, UK, European Union, Australia, China, Japan, etc. Therefore, the opportunity for integration with such a big player means the possibility of crypto being accepted wherever you want. However, there’s more to come. About 7,500 teams represent the 1C: Franchising partner network, which is the main channel of value-adding for 1C products. In the future, these teams can become members of our decentralized franchise. In other words, they can become Paytomat distributors and receive an incentive for providing cryptocurrency services. ### About Paytomat [#about-paytomat] Paytomat is a decentralized system for cryptocurrency payments created to help merchants, consumers and crypto core teams to create real-life traction for cryptocurrencies as an emerging method of everyday payments. Its main features include loyalty program on a blockchain, direct integration with POS providers, DAO, decentralized franchise, standalone mobile POS, and AI chatbot payments. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Console Panel API (/paytomat/console-api) Paytomat is a set of blockchain software solutions, used by merchants to accept cryptocurrencies in-store or online. Console Panel allows merchants to track such transactions, manage authentication tokens and generate invoices. You can use this API to integrate crypto payments to the existing point-of-sale systems, shopping carts or mobile apps. ## Table of contents [#table-of-contents] * [REST API for Paytomat Console Panel](#rest-api-for-paytomat-console-panel) * [General API Information](#general-api-information) * [Error Codes](#error-codes) * [API authentication](#api-authentication) * [HTTP Basic authentication](#http-basic-authentication) * [JWT authentication](#jwt-authentication) * [Basic Types](#basic-types) * [**int**](#--int--) * [**long**](#--long--) * [**boolean**](#--boolean--) * [**string**](#--string--) * [**float**](#--float--) * [**decimal**](#--decimal--) * [**dateTime**](#--datetime--) * [**object**](#--object--) * [\[**object**\]](#---object---) * [API endpoints](#api-endpoints) * [JWT token](#jwt-token) * [Currency codes list](#currency-codes-list) * [Exchange rates list](#exchange-rates-list) * [Current balance](#current-balance) * [New transaction](#new-transaction) * [Cancel transaction](#cancel-transaction) * [Chargeback transaction](#chargeback-transaction) * [Transaction details](#transaction-details) * [List of transactions](#list-of-transactions) * [Transaction broadcast](#transaction-broadcast) * [Product details](#product-details) * [New product](#new-product) * [Update product](#update-product) * [Payment widget](#payment-widget) * [Models:](#models-) * [General Models](#general-models) * [JWT](#jwt) * [Error](#error) * [Currency](#currency) * [Exchange Rates](#exchange-rates) * [Balance](#balance) * [Payment URL](#payment-url) * [Transaction Models](#transaction-models) * [Transaction Short](#transaction-short) * [Transaction Full](#transaction-full) * [Transaction Status](#transaction-status) * [Callback URL](#callback-url) * [Broadcast Code](#broadcast-code) * [Product Models](#product-models) * [Product](#product) * [Product Field](#product-field) * [Product Status](#product-status) This is an improved version of the original API that can be found [here](https://app.paytomat.com/merchant_api.html). ## General API Information [#general-api-information] * The base endpoint is: `https://app.paytomat.com/api/v1/` * All endpoints always return a JSON object that contains a single object or an array of objects. * Data is returned in ascending order. Oldest first, newest last. ## Error Codes [#error-codes] * Any API endpoint can return an error. * Errors are always reported as JSON encoded object with `error` key. Sample payload: ``` { "error": "error_description" } ``` # API authentication [#api-authentication] * Paytomat API supports two types of authentication: [HTTP Basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) and [JWT authentication](https://jwt.io). * For both types you need to create a merchant account in [Console Panel](https://console.paytomat.com) and pass basic verification. * By default `username` or `login` is the `email` you used during registration of your merchant account. * If you want a separate login/password pair or JWT token, you can always create a new pair in [Console Panel](https://console.paytomat.com) in `Settings/Branches` tab with `Basic` or `Token` type accordingly. ## HTTP Basic authentication [#http-basic-authentication] To authenticate with HTTP, you may provide a username and password with the following URL format: `https://username:password@app.paytomat.com/api/v1`. For HTTP Basic authentication, encode your login and password concatenated by a colon (`:`) with [Base64](https://en.wikipedia.org/wiki/Base64) encryption. ### Example HTTP header: [#example-http-header] `Authorization: Basic cGVwZTp0aGVfcGln` where `cGVwZTp0aGVfcGln` is a Base64 phrase you generated above. ## JWT authentication [#jwt-authentication] For JWT authentication, use JWT token you can find in [Console Panel](https://console.paytomat.com) in the `Settings/Branches` tab. ### Example HTTP header: [#example-http-header-1] `Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJpZCI6NiwicmVhbG0iOiJtZXJjaGFudF9rZXkifQ.hTdblIJI6mcPCyZ5u9eiYI8e6tRJ5VRtU0AbLQ8WlAw`, where string after Bearer is JWT token. ### Example curl: [#example-curl] `curl 'https://app.paytomat.com/api/v1/balance' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJpZCI6NiwicmVhbG0iOiJtZXJjaGFudF9rZXkifQ.hTdblIJI6mcPCyZ5u9eiYI8e6tRJ5VRtU0AbLQ8WlAw'` # Basic Types [#basic-types] ### **int** [#int] `20` A standard JSON integer. ### **long** [#long] `20` A 64-bit two's complement JSON integer. ### **boolean** [#boolean] `true` A standard JSON boolean. ### **string** [#string] `This suppose to be a text` A standard JSON string. When POSTing data as `application/x-www-form-urlencoded`, use a UTF-8 encoded string instead rather than Unicode escapes. ### **float** [#float] `13.839039` A standard JSON floating-point decimal. ### **decimal** [#decimal] `"13.83903987"` An arbitrary-precision JSON decimal number encoded as a standard JSON string. ### **dateTime** [#datetime] `"2020-02-03T17:00:00Z"` Date and time as a string in ISO8601 combined date and time format in UTC (Coordinated Universal Time). ### **object** [#object] ``` { "rates": { "BTC": "0.020903", "DASH": "0.3338", "USD": "241.81", "WAVES": "29.874" } } ``` The standard base representation for first-class objects in Paytomat, such as [Product](#Product), [Balance](#Balance), [Error](#Error), etc. ### \[**object**] [#object-1] ``` { "currencies": [ { "code": "BTC", "in": true, "out": true, "title": "Bitcoin" }, { "code": "UAH", "in": true, "out": false, "title": "Hryvnia" } ] } ``` The standard base representation for an object that contains a list of first-class objects in Paytomat, such as [Product](#Product), [Balance](#Balance), [Error](#Error), etc. # API endpoints [#api-endpoints] ## JWT token [#jwt-token] ``` GET /token ``` Returns JWT token for given account's credentials. ### Parameters: [#parameters] None ### Responses: [#responses] | Code | Type | Description | | ------- | :-------------- | :--------------------- | | 200 | [JWT](#JWT) | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-1] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/token' //Result { "token": "eyJhbGciOiJIUzI1NiJ9.eyJpZCI6NiwicmVhbG0iOiJtZXJjaGFudF9rZXkifQ.hTdblIJI6mcPCyZ5u9eiYI8e6tRJ5VRtU0AbLQ8WlAw" } ``` ## Currency codes list [#currency-codes-list] ``` GET /currencies ``` Returns a list of available currency codes. ### Parameters: [#parameters-1] None ### Responses: [#responses-1] | Code | Type | Description | | ------- | :----------------------- | :--------------------- | | 200 | \[[Currency](#Currency)] | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-2] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/currencies' //Result { "currencies": [ { "code": "BTC", "in": true, "out": true, "title": "Bitcoin" }, { "code": "UAH", "in": true, "out": false, "title": "Hryvnia" } ] } ``` ## Exchange rates list [#exchange-rates-list] ``` GET /exchange_rates ``` Returns an object of currency exchange rates for a given currency. ### Parameters: [#parameters-2] | Name | Type | Required | Description | | -------- | :----- | :------- | :------------ | | currency | string | Yes | Currency code | ### Responses: [#responses-2] | Code | Type | Description | | ------- | :-------------------------------- | :--------------------- | | 200 | [Exchange Rates](#Exchange-Rates) | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-3] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/exchange_rates?currency=BTC' //Result { "rates": { "BTC": "0.020903", "DASH": "0.3338", "USD": "241.81", "WAVES": "29.874" } } ``` ## Current balance [#current-balance] ``` GET /balance ``` Returns an object of current balances for currencies. ### Parameters: [#parameters-3] None ### Responses: [#responses-3] | Code | Type | Description | | ------- | :------------------ | :--------------------- | | 200 | [Balance](#Balance) | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-4] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/balance' //Result { "balance": { "USD": 10000 } ``` Object with amounts for every available currency. ## New transaction [#new-transaction] ``` POST /create_transaction ``` Creates a new transaction. ### Parameters: [#parameters-4] | Name | Type | Required | Description | | :------------ | :----- | :------- | :------------------------------------------------------------------------------------------ | | id | int | Yes | Transaction id. If not defined, the `ref` parameter will be used | | ref | int | No | Merchant specific data. If not defined, the `id`**\_UnixTimestamp** input will be used | | currency\_in | string | Yes | Payment currency of transaction | | currency\_out | string | Yes | Payout currency of transaction | | amount\_in | float | Yes | Amount of payment currency of transaction | | callback\_url | string | No | [Redirect URL](#Callback-URL) after completed transaction | ### Responses: [#responses-4] | Code | Type | Description | | ------- | :-------------------------------------- | :--------------------- | | 200 | [Transaction Short](#Transaction-Short) | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-5] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/create_transaction' -d '{ "ref": 125, "currency_in": "USD", "currency_out": "BTC", "amount_in": 100 }' //Result { "amount_out": 0.041896, "currency_out": "BTC", "id": 3, "qr_code": "bitcoin:38iub2TZpsTGQjZc7zhGcBcphxPk6eGpHa?amount=0.041896", "rate": 0.00041896, "address": "38iub2TZpsTGQjZc7zhGcBcphxPk6eGpHa", "note": "Please turn off transaction encryption if you encounter public key error" } ``` ## Cancel transaction [#cancel-transaction] ``` POST /cancel_transaction ``` Manually cancels a pending transaction. ### Parameters: [#parameters-5] | Name | Type | Required | Description | | :--- | :--- | :------- | :------------- | | id | int | Yes | Transaction id | ### Responses: [#responses-5] | Code | Type | Description | | ------- | :---------------------------------------- | :--------------------- | | 200 | [Transaction Status](#Transaction-Status) | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-6] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/cancel_transaction' -d '{ "id": 9 }' //Result { "status": "cancelled", "status_description": "Transaction has been cancelled" } ``` ## Chargeback transaction [#chargeback-transaction] ``` POST /chargeback_transaction ``` Requests chargeback for a transaction. ### Parameters: [#parameters-6] | Name | Type | Required | Description | | :--- | :--- | :------- | :------------- | | id | int | Yes | Transaction id | ### Responses: [#responses-6] | Code | Type | Description | | ------- | :---------------------------------------- | :--------------------- | | 200 | [Transaction Status](#Transaction-Status) | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-7] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/chargeback_transaction' -d '{ "id": 3 }' //Result { "status": "chargeback_scheduled", "status_description": "Transaction has been scheduled for chargeback" } ``` ## Transaction details [#transaction-details] ``` GET /transaction ``` Returns details for a single transaction. ### Parameters: [#parameters-7] | Name | Type | Required | Description | | :--- | :--- | :------- | :------------- | | id | int | Yes | Transaction id | ### Responses: [#responses-7] | Code | Type | Description | | ------- | :------------------------------------ | :--------------------- | | 200 | [Transaction Full](#Transaction-Full) | Success | | 400 | [Error](#Error) | Bad request | | 404 | | Not found | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-8] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/transaction?id=1' //Result { "transaction": { "address": "33CyuJsTYQ3h6kPkDPT1Mawx7qZouVzmHe", "amount_in": "100", "amount_out": "0.041896", "comment": "Requested chargeback", "created": "2017-05-24 15:12:39", "currency_in": "USD", "currency_out": "BTC", "id": 1, "rate": "0.00041896", "ref": "CK00004", "status": "cancellation", "updated": "2017-05-24 16:34:24", "qr_code": "bitcoin:2N1sNUrHUmMw61rSyFPPmvDYHJrCk7QCy8x?amount=0.0000000511751", "note": "Please turn off transaction encryption if you encounter public key error" } } ``` ## List of transactions [#list-of-transactions] ``` GET /transactions ``` Returns a list of transactions. ### Parameters: [#parameters-8] | Name | Type | Required | Description | | :-------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------- | | status | string | No | Transaction status. Allowed values: \[new, pending, confirmation, cancellation, success, canceled, failure, chargeback, timeout] | | limit | int | No | Default 50; max 100 | | offset | int | No | Start with 0; default 0 | | order\_by | string | No | Sort order. Allowed values: \[id, status, updated, created, id, ref] | ### Responses: [#responses-8] | Code | Type | Description | | ------- | :--------------------------------------- | :--------------------- | | 200 | \[[Transaction Full](#Transaction-Full)] | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-9] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/transactions?order_by=-updated' //Result { "transactions": [ { "address": "33CyuJsTYQ3h6kPkDPT1Mawx7qZouVzmHe", "amount_in": "100", "amount_out": "0.041896", "comment": "Requested chargeback", "created": "2017-05-24 15:12:39", "currency_in": "USD", "currency_out": "BTC", "id": 1, "rate": "0.00041896", "ref": "CK00004", "status": "cancellation", "updated": "2017-05-24 16:34:24", "qr_code": "bitcoin:2N1sNUrHUmMw61rSyFPPmvDYHJrCk7QCy8x?amount=0.0000000511751", "note": "Please turn off transaction encryption if you encounter public key error" }, { "address": "3DahmyivDiKeAo67FREygXJEZgD5G4q96u", "amount_in": "100", "amount_out": "0.041896", "comment": "Payment received", "created": "2017-05-24 15:13:11", "currency_in": "USD", "currency_out": "BTC", "id": 2, "rate": "0.00041896", "ref": "CK00006", "status": "success", "updated": "2017-05-24 16:34:24", "qr_code": "bitcoin:2N1sNUrHUmMw61rSyFPPmvDYHJrCk7QCy8x?amount=0.0000000511751", "note": "Please turn off transaction encryption if you encounter public key error" } ] } ``` ## Transaction broadcast [#transaction-broadcast] ``` POST /broadcast_transaction ``` Broadcasts a transaction. ### Parameters: [#parameters-9] | Name | Type | Required | Description | | :------- | :----- | :------- | :------------------------ | | currency | string | Yes | Transaction currency code | | txid | string | Yes | Transaction id | | receiver | string | Yes | Receiver address | | amount | string | Yes | Transaction amount | ### Responses: [#responses-9] | Code | Type | Description | | ------- | :-------------------------------- | :--------------------- | | 200 | [Broadcast Code](#Broadcast-Code) | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-10] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/broadcast_transaction' -d '{"currency": "BTC", "txid": "f39448872b469a6f49b7d8b037adf810519f1f2b583cba852e7f5128f53daf29", "receiver": "1ApkXfxWgJ5CBHzrogVSKz23umMZ32wvNA", "amount": 0.07227808}' //Result { "success": 1 } ``` ## Product details [#product-details] ``` GET /product ``` Returns an object with product details. ### Parameters: [#parameters-10] | Name | Type | Required | Description | | :--- | :--- | :------- | :---------------------- | | id | int | Yes | Internal transaction id | ### Responses: [#responses-10] | Code | Type | Description | | ------- | :------------------ | :--------------------- | | 200 | [Product](#Product) | Success | | 400 | [Error](#Error) | Bad request | | 404 | | Not found | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-11] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/product?id=1' //Result { "product": { "id": 1, "amount": "5.00", "currency": "USD", "title": "Croissant", "unit": "piece" "fields": [], "callback_url": "", "tx_success": 7, "custom_css": "https://somesite.com/css/style.css", } } ``` ## New product [#new-product] ``` POST /create_product ``` Creates a new product. ### Parameters: [#parameters-11] | Name | Type | Required | Description | | :--- | :--- | :------- | :---------------------- | | id | int | Yes | Internal transaction id | ### Responses: [#responses-11] | Code | Type | Description | | ------- | :------------------ | :--------------------- | | 200 | [Product](#Product) | Success | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-12] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/create_product' -d '{ "title": "Pierogi", "amount": 15, "currency": "UAH", "unit": "piece", "fields": [ { "id": "comment", "title": "Comment", "is_required": 0, "type": "text", "custom_css": "is_optional" } ] }' //Result { "id": 12 } ``` ## Update product [#update-product] ``` PUT /product/{id} ``` Updates product properties. ### Parameters: [#parameters-12] | Name | Type | Required | Description | | :--- | :--- | :------- | :------------------ | | id | int | Yes | Internal product id | ### Responses: [#responses-12] | Code | Type | Description | | ------- | :-------------------------------- | :--------------------- | | 200 | [Product Status](#Product-Status) | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-13] ```javascript //Request: curl 'https://username:password@app.paytomat.com/api/v1/product/12' -X PUT -d '{ "amount": 20 }' //Result { "updated": 1 } ``` ## Payment widget [#payment-widget] ``` GET /payment_url ``` Returns URL to the merchant's payment widget. ### Parameters: [#parameters-13] None ### Responses: [#responses-13] | Code | Type | Description | | ------- | :-------------------------------- | :--------------------- | | 200 | [Product Status](#Product-Status) | Success | | 400 | [Error](#Error) | Bad request | | default | [Error](#Error) | Generic response error | ### Example curl: [#example-curl-14] ```javascript //Request: curl curl 'https://username:password@app.paytomat.com/api/v1/payment_url' //Result { "url": "https://app.paytomat.com/pay/2mVQcpFLk9f" } ``` # Models: [#models] ## General Models [#general-models] ### JWT [#jwt] Represents a [JSON Web Token](https://jwt.io) used for authentication to Paytomat Console Panel API. You can generate a new token or find an existing one in [Console Panel](http://app.paytomat.com). | Name | Type | Description | Example | | ----- | :----- | :---------- | :------ | | token | string | JWT token | | ### Error [#error] Contains details about the encountered error during an API request. You can learn more about common types of errors in the [Error Codes](#Error-Codes) section. | Name | Type | Description | Example | | ---- | :--- | :---------- | :------ | | code | long | Error code | 404 | ### Currency [#currency] Represents currency or cryptocurrency used in a given transaction. Currencies can be used to perform payments (invoicing system for online, mobile or in-store purchases) and payouts (merchant fund’s settlement to a bank account or cryptocurrency wallet). | Name | Type | Description | Example | | ----- | :------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :-------- | | code | string | Currency code by country ([ISO 4217](https://en.wikipedia.org/wiki/ISO_4217)) or cryptocurrency code ([Coinmarketcap](https://coinmarketcap.com/all/views/all/)) | USD | | in | boolean | Is the currency allowed for payments | true | | out | boolean | Is the currency allowed for payouts | false | | title | string | Full name of currency by country ([ISO 4217](https://en.wikipedia.org/wiki/ISO_4217)) or cryptocurrency ([Coinmarketcap](https://coinmarketcap.com/all/views/all/)) | US dollar | ### Exchange Rates [#exchange-rates] Contains a key-value pair with a currency code ([ISO 4217](https://en.wikipedia.org/wiki/ISO_4217)) on the left side and exchange rate on the right for a given currency. | Name | Type | Description | Example | | ----- | :----- | :--------------------------------- | :------ | | rates | object | Exchange rates for chosen currency | | ### Balance [#balance] Contains current balances of each [currency](#Currency) for a given merchant account. Current balance is a sum of all transactions received in this currency before it was settled. | Name | Type | Description | Example | | ------- | :----- | :----------------------------------- | :------ | | balance | object | Amounts for all available currencies | | ### Payment URL [#payment-url] Represents a unique link each merchant can use to accept cryptocurrency payments via [mQR standard](https://paytomat.com/en) created by Paytomat. Contains a key-value pair with `url` on the left side and the link itself on the right. | Name | Type | Description | Example | | ------ | :----- | :------------------------------- | :------ | | object | object | URL to merchant's payment widget | | ## Transaction Models [#transaction-models] ### Transaction Short [#transaction-short] Contains details of a newly created transaction. | Name | Type | Description | Example | | ------------- | :----- | :------------------------------------------ | :--------- | | id | int | Internal transaction id | 87 | | rate | float | Exchange rate of a given currency | 0.00041896 | | currency\_out | string | Payout currency of transaction | BTC | | amount\_out | float | Amount of payout currency of transaction | 0.041896 | | qr\_code | string | Transaction URL used for QR code generation | | | address | string | Address to receive payout currency | | | note | string | Extra details about transaction | | ### Transaction Full [#transaction-full] Contains full details of the already created transaction. | Name | Type | Description | Example | | ------------- | :------- | :-------------------------------------------------------- | ---------- | | id | int | Internal transaction id | 456 | | ref | string | Merchant's specific data | | | status | string | Transaction status | pending | | comment | string | Comment to transaction status | | | created | dateTime | Data/time of transaction creation | | | updated | dateTime | Data/time of the latest transaction update | | | address | string | Address to receive payout currency | | | currency\_in | string | Payment currency of transaction | BTC | | currency\_out | string | Payout currency of transaction | LTC | | amount\_in | float | Amount of payment currency of transaction | 1.872000 | | rate | float | Exchange rate of a given currency | 0.00041896 | | qr\_code | string | Transaction URL used for QR code generation | | | note | string | Extra details about transaction | | | callback\_url | string | [Redirect URL](#Callback-URL) after completed transaction | | | product\_id | int | Product id (if a transaction is attached to a product) | | ### Transaction Status [#transaction-status] Represents transaction status with its name and full description. | Name | Type | Description | Example | | ------------------- | :----- | :----------------- | :---------------------------- | | status | string | Action status | canceled | | status\_description | string | Status description | Transaction has been canceled | ### Callback URL [#callback-url] Represents a postback structure of the URL to post after a transaction is completed. | Name | Type | Description | Example | | ------------ | :----- | :------------------------------------------------------------------------------------------------------------------------------- | :------ | | merchant\_id | int | Merchant id | 87 | | product\_id | int | Product id | 627 | | tx\_code | string | Internal transaction code | | | tx\_id | string | Transaction id on a blockchain | | | amount | float | Amount of funds sent in transaction | 2.345 | | currency | string | Currency code of sent transaction | ETH | | qr\_code | string | Transaction URL used for QR code generation | | | details | string | Extra details about transaction | | | tx\_status | string | Transaction status. Allowed values: \[new, pending, confirmation, cancellation, success, canceled, failure, chargeback, timeout] | pending | | custom\_css | string | A link for CSS file or CSS properties used for customizing transaction's UI | | ### Broadcast Code [#broadcast-code] Represents a success code of the broadcasted transaction. Contains a key-value object with `success` key on the left side and success code on the right (`1` for successful, `0` for not failed operation respectively). | Name | Type | Description | Example | | ------ | :----- | :------------- | :------ | | object | object | Broadcast code | | ## Product Models [#product-models] ### Product [#product] Represents a product that is intended to be sold repeatedly or in bulk. You can create a product inside of [Paytomat Console Panel](http://app.paytomat.com). | Name | Type | Description | Example | | ------------- | :--------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------ | | id | int | Internal product id | 123 | | amount | decimal | Product price | "13.83903987" | | currency | string | Price currency code | USD | | title | string | Product title | | | tx\_success | int | Number of successful transactions for this product | | | unit | string | Allowed values: \[single, piece, decimal]. Single - fixed number of products to buy; piece - products can be sold partially; decimal - any amount of products can be sold | | | callback\_url | string | Redirect URL used after successful transaction | | | custom\_css | string | A link to CSS file or CSS properties used for customizing transaction's UI | | | fields | \[[Product Field](#Product-Field)] | Array of objects describing product fields | | ### Product Field [#product-field] Represents specific property data of the product, such as its shipping address, origin, brand, manufacturer, category, etc. | Name | Type | Description | Example | | ------------ | :----- | :---------------------------------------- | :---------------- | | id | string | Field id | shipping\_address | | title | string | Field title | Shipping Address | | type | string | Field type | text | | min\_length | int | Min length of the field | 10 | | max\_length | int | Max length of the field | 42 | | is\_required | int | Is field required. Allowed values: \[0,1] | 1 | | options | string | Extra options for a field | | ### Product Status [#product-status] Represents a flag of either the product was updated or not. Contains a key-value pair with `updated` key on the left side and updated status on the right (`1` for updated, `0` for not updated respectively). | Name | Type | Description | Example | | ------ | :----- | :------------------------- | :------ | | object | object | Update status of a product | | --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # EOS Resources (/paytomat/eos-resources) Even though EOS has been around for so long, there are many questions on how to use its resources properly, especially via Paytomat Wallet. We decided to make a special guide for you, so buckle up. ptm-28 ### No fees, more challenges [#no-fees-more-challenges] As you already know, EOS is one of those rare cryptocurrencies with instant speed and no transactional fees. This is a benefit most people underestimate. It allows to develop software which requires strong and robust real-time payments in shorter periods of time and demonstrates the advantages other payment systems don’t have. Traditionally, processing companies (VISA, Mastercard, Paypal, Stripe, etc.) charge an extra fee (1%-5%) for providing services. It is a proven business model which works and people seem to get used to it because they don’t know the alternatives. Bitcoin, as the first blockchain use case, also includes a small fee. However, this fee is not paid to a company, corporation, government, bank or any other institution, instead it’s awarded to thousands of miners who help to maintain the network and make sure your transactions are validated and secured. There’s one important thing people don’t understand about fees on the blockchain networks — their purpose. In this case, people pay a few cents/dollars to ensure they are not sending spam, meaning you’re paying extra for sending a transaction which has a real value (transfer to a friend, purchase of a ticket, tip to a waitress, bet in a game). This is a protection mechanism which prevents people from generating unlimited number of useless operations that would clutter the network up and make it unstable. EOS is the second blockchain which removed fees due to a new validation algorithm (delegated proof of stake). Apparently, it’s that simple to get rid of fees completely so they came up with a better approach. You need to possess a certain amount of resources each time you use your wallet. You can think of it as gasoline — the more you expect to drive, the larger the quality and quantity of fuel you are supposed to have. ### EOS resources 101 [#eos-resources-101] The way EOS works is similar to any other operating system, which is why there are 3 types of resources: CPU, RAM, NET. Each of them has a dedicated role. If your Mac or Windows does resource management and adjustments by itself, you need to put a little effort into operations with EOS. Before we go there, let’s figure out the distinctions between those resources. CPU is the most important among all since it is used every time you attempt to do something with your EOS account. It is measured in µs (microseconds) and its role is to process your EOS transactions, so make sure to have plenty because you never know how much time you will spend playing different dapps. The good thing is that CPU is renewable so if, for some reason, you don’t have enough, you can simply wait a few minutes/hours until it comes back to its original state. NET is the least valuable of all, however you still need it. It is measured in KB (kilobytes) and increases the network’s bandwidth, which means you can send more transactions from your EOS account. Most of the time you don’t need a lot of NET but it’s good to have some reserves. The last one is RAM. It’s probably the most interesting of all. t is valuable because it stores the data of any dapp you’re using. Both games and decentralized exchanges fall into this category because they have loads of info in their state at any time. ### Staking/unstaking [#stakingunstaking] With the very first introduction of EOS within Paytomat Wallet, our goal was to make resource management as easy as possible. Knowing how complex the technical part is, we had to create a simple UI. This is why there are only two actions you need to know about when dealing with EOS: stake and unstake. Staking gives you an opportunity to assign a certain amount of resources (CPU and NET) to EOS network in exchange for your EOS. Unstaking simply refunds all of your assets back to your account. In order to stake or unstake any EOS resource, all you need to do is to go to EOS Resources section in your EOS account and click on the plus or minus sign to adjust the amount of selected resource. Keep in mind: * You can only stake EOS for CPU and NET, RAM has to be purchased/sold separately in the open EOS RAM marketplace. Hopefully, in Paytomat Wallet you won’t find any differences, so don’t worry about that. * Staking happens instantly. * Unstaking takes 72 hours (3 days). * RAM purchase/sell happens instantly. EOS resources recommendations The most common question we had over the last few months is what are the bare minimums and the average amounts of resources that have to be maintained. When you create an EOS account, you have the minimum of CPU, RAM and NET that can be used in a survival mode. Even though it is possible to leave it as it is, we recommend you to stake more, just in case of the random spikes in resource usage on the EOS network. Basic set-up (5–10 operations daily): * CPU — 1–2 EOS * RAM — 3–4KiB * NET — 1 EOS Average set-up (10–100 operations daily): * CPU — 3–4 EOS * RAM — 4–5KiB * NET — 1 EOS Advanced set-up (over 100 operations daily): * CPU — 5–10 EOS * RAM — 5–7KiB * NET — 2–3 EOS Keep in mind: * If you love playing games or dapps that require ongoing interactions with your EOS account, check your CPU levels more frequently. Sometimes it takes more time to renew its reserves. We also recommend you to have 4:2:1 proportion of CPU:RAM:NET accordingly if you tend to use such services or interact with smart contracts through Paytomat Wallet consistently. * The more transactions you need to make in a short period of time, the more CPU you’ll need. * The more data a particular dapp stores, the more RAM you’ll need. * RAM can only be purchased in the marketplace which means you can buy more when it is cheap and sell when it is high. Gambling on resources can be fun after all. * Sometimes EOS network can be busy during the times of massive and unpredictable usages by the dapps. This happens rarely but when it does, you may encounter a sudden lack of CPU, even if you don’t use your wallet. Don’t freak out, just wait. This is normal and it will end automatically. Let us know whether this was a clear explanation in our telegram group. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Decentralized Franchise (/paytomat/franchise) For the last decade, the internet has offered unlimited possibilities to individuals for creating any type of business they could possibly envision. We’ve seen a massive explosion in social media influencers, e-sport players, digital nomads, bloggers, e-commerce dropshippers, drone pilots, Uber drivers, Airbnb hosts, and online trainers. The number of similar opportunities are growing faster than we’ve ever seen before, which is why traditional businesses will just have to adjust. We believe the emerging blockchain technology will create even more disruption in various industries and reshape numerous conventional ‘job’ types. People will redefine the way they view their careers in the upcoming years. Paytomat encountered this issue early on and is offering a long-term solution. This spring we are introducing the first ever decentralized franchise where anybody can contribute to cryptocurrency payment system on their local market. There are lots of blockchain entrepreneurs and cryptocurrency enthusiasts across the globe, who can benefit from such a business model, by leveraging existing relationships they’ve developed over the years. We are aiming to build a global Paytomat community of local representatives who will help to establish fiat-to-crypto gateways, direct relationships with POS vendors and help merchants start accepting cryptocurrency. As a result, they can become co-owners of the first franchise on a blockchain and participate in the Paytomat loyalty program. ## What Are The Benefits of the Decentralised Franchise? [#what-are-the-benefits-of-the-decentralised-franchise] ### Blockchain significantly improves various franchising processes [#blockchain-significantly-improves-various-franchising-processes] Blockchain technology is here to stay. Billions of people will use it sooner than they anticipate. In fact, the biggest companies in the world are already working on different blockchain implementations for banking, payments, medicine, and international trade markets. There are benefits that blockchain can give to the franchise industry as well. For instance, the entire process of creating a franchise agreement can be automated via smart contracts. In this way, every distributor will have an immutable record of attribution to that particular franchise unit. Moreover, smart contracts can potentially allow transferring digital rights to another person eliminating all of the paperwork. ### The Paytomat franchise is augmented with a digital referral program [#the-paytomat-franchise-is-augmented-with-a-digital-referral-program] A common franchise model looks simple. Its revenue is split among franchisor, franchisee and franchisee’s employees. They receive royalty fees, sales profits, and salaries respectively. The biggest concern we have with such a structure is that people should pay weekly or monthly dividends from their total profit, which may not be the most convenient operation to individual Franchisee. To automate this and other financial issues in this industry, we decided to apply a referral system — a model, which has already delivered tremendous growth to companies like Dropbox, Airbnb, and Uber. ### Paytomat closely works with core teams of cryptocurrencies and blockchain projects [#paytomat-closely-works-with-core-teams-of-cryptocurrencies-and-blockchain-projects] The main purpose of our project is to help cryptocurrencies to become accepted worldwide by thousands of merchants and e-commerce businesses. That involves various technical, legal, marketing and management challenges. To accomplish our goal faster, we deliberately started to work with core teams of different blockchain projects and founders of top cryptocurrencies. Those are very intelligent people who are trying to reach a very specific niche due to their professional careers and relationships in that field. By working with them, together we can embrace different markets in a very unique way that wasn’t previously possible. ### How the Paytomat franchise is going to work? [#how-the-paytomat-franchise-is-going-to-work] Unfortunately, decentralized business models haven’t been tested at scale due to a fairly small age of blockchain technology and a lack of deeply engaged experts in this field. However, there are several working models in existing centralized services that we can use and improve by applying immutable and distributed ledger. One of those services is a referral system we mentioned earlier. In this case, by using smart contracts, Paytomat Core will distribute a portion of rewards a particular franchisee earned at any given transaction. The type of clients one can refer to our network are point-of-sale vendors, merchants and payment gateways. There are three key elements required to initiate a transaction on Paytomat blockchain: franchisee ID, cryptocurrency public key and a license key of a merchant. We will put those keys in Profit Distribution Signature that has the following usage structure: * franchisee ID — a unique identifier for a franchise identity that we store on the Paytomat blockchain. Creating a new account triggers ID generation. * public key — a blockchain address of a merchant to accept a particular cryptocurrency. This address changes during every transaction to enhance the privacy of our end customer. However, it can also be predefined in the account settings. * license key — a key that POS software or hardware provider issues to every merchant. Paytomat generates this key once, and don’t change it unless the merchant decides to switch to another POS system. ptm-6 We believe that by having an incentive model for each participant of the network, we can create a comprehensive ecosystem in which stakeholders are helping each other to grow faster and achieve the common cause: making crypto payments a convenient instrument for everyday transactions. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Loyalty Program (/paytomat/loyalty-program) ### Loyalty Programs Evolution [#loyalty-programs-evolution] The very [first loyalty program](https://blog.smile.io/a-history-of-loyalty-programs) appeared in the XVII century when retailers were giving copper tokens that could be later redeemed for products on future purchases. It turned out to be an expensive approach but it definitely left a clear message for the industry — rewarding people with extra bonuses works. Later a whole range of loyalty programs appeared in various industries. Hundreds of millions of people now use frequent flier miles, cashback, restaurant and hotel points, and gift cards on a daily basis. The Internet has been the biggest driver of loyalty programs to date. We believe Blockchain can be even bigger. In fact, according to [recent research by Deloitte](https://www2.deloitte.com/us/en/pages/financial-services/articles/making-blockchain-real-customer-loyalty-rewards-programs.html), Blockchain is a perfect match for loyalty rewards programs by providing more transparent and fraud-proof loyalty points. Currently, this is a blue ocean. Over time, dozens of competitors will appear. However, we don’t think this competition will turn to bloodshed within the foreseeable future. For instance, [Elements](https://theelements.io/) is one of the first projects that is trying to implement loyalty rewards by creating a single cryptocurrency, which merchants in the multiple industries will be able to use. It also allows merchants to mine ELM cryptocurrency. The approach is interesting. However, its scalability will be a true challenge. Because the Elements ecosystem is proof-of-work based, the infrastructure costs of maintaining it will be high and will require a huge commitment on behalf of the participants of this ecosystem. On-chain scaling works only in a situation where full nodes are incentivized. Without a sufficient number of full nodes, the blockchain ecosystem they represent will be vulnerable. ### Paytomat Blockchain [#paytomat-blockchain] To have a network that is capable of handling loyalty programs, processing hundreds of thousands of transactions per second, instant exchange between currencies and the DAO governance model, we decided to build up an entirely new blockchain. The main features of this system are: * a new block is generated within 1–3 seconds; * we issue tokens without turing complete smart contracts; * our blockchain supports atomic swaps and sidechains; * our system works with turing complete smart contracts. Currently, there are several blockchains that are capable of handling most of the requirements mentioned above. We are still conducting our research on which one to use as our main technology. The core concept of Paytomat Blockchain is to create a system where all of the merchants and software vendors can augment the network. In return, they will receive crypto to use or spend in other locations. In fact, we’re designing a new consensus algorithm exactly for that, it will be called Point-of-Sale as Proof-of-Stake. ### Paytomat Coin PTM and Paytomat Token PTX [#paytomat-coin-ptm-and-paytomat-token-ptx] The Paytomat loyalty program will consist of 2 major components: PTM Coin and PTX Token. PTM will be the main cryptocurrency of Paytomat Blockchain and will serve as a basis for a merchants rewards program. PTX will be a token on top of Paytomat Blockchain and will act as a single loyalty token on our network. There are four fundamental reasons why to have a coin and a token separately on our network. 1. Distinguishing between rewards for merchants and for customers In the pre-blockchain era, customers received points, bonuses or discounts, while merchants received cashback to their bank account. The same way in loyalty program on blockchain customers will receive PTX tokens, which they will use exclusively to receive a discount. However, merchants will receive PTM coins which is a cryptocurrency listed on the crypto exchange. It reminds a traditional fiat currency. Merchants will be able to keep it as savings, spend it in all Paytomat locations or trade it for Bitcoin (or other cryptos) on various exchanges. 2. Managing the volatility of our ecosystem by using different growth strategies for Paytomat coins and tokens The PTM coin will be constantly increasing in price, fostered by the buybacks we will conduct each time we generate a new amount of coins. In contrast, PTX will be constantly decreasing in price, thus stimulating customers to spend it quickly and to make recurring crypto payments. 3. Reducing the number of tokens people have to use in loyalty programs from different industries Previously people had to carry dozens of cards and keep multiple apps to have a discount. That’s very discouraging, distracting, and increases the number of unused bonus systems. It is especially relevant in the travel industry, where restaurants, hotels, and flights have different reward structures. By introducing a single loyalty token, people can finally get the most from such programs and have the best products at the most affordable price. 4. Instant redemption or exchange of tokens Blockchain also allows for creating a shared distribution of tokens among numerous participants during a block generation. That is the perfect software solution for any loyalty program that projects like ours can use. It allows for redeeming tokens instantly and exchanging them if there’s a need. PTM Coin and PTX Token Stakeholder Relationships Early on we’ve defined that our ecosystem has a diverse audience. There are core teams of cryptocurrencies that launch new cryptos. There are also crypto enthusiasts who use crypto from core teams to pay for various goods and services. There are merchants who want to have customers who pay with crypto. Lastly, there are POS vendors providing merchants with software solutions to simplify their business processes. Despite the different needs and wants, they all deserve some rewards because they make valuable contributions to the network. Below we tried to describe how they interact with each other. ptm-7 ### Paytomat Loyalty Wallet [#paytomat-loyalty-wallet] One of the [best practice](https://blog.smile.io/loyalty-best-practices-2018) for a successful loyalty program in 2018, is to have a mobile app. For this reason, we are building the Paytomat cryptocurrency wallet. Currently, this will be the first wallet to support both PTM and PTX, as well as other cryptos. To protect our customers, the Paytomat wallet is using the best security standards, which are currently available on the market. Namely: cryptocurrency vault, multisignature, built-in hardware wallet support. The biggest advantage our wallet will provide is direct integration with leading POS systems, e-commerce plugins, other payment solutions via Paytomat APIs and other key elements of our ecosystem. Lastly, each person who has our wallet installed will be able to use various location-based services to look for the best deals and promotions, as well as places that currently accept crypto nearby. The first version of the Paytomat wallet is scheduled to be released in March. Stay tuned for more updates! --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Merchant Interfaces (/paytomat/merchant-interfaces) ptm-11 With the development of our ecosystem, Paytomat is gradually acquiring a number of products that allow to both pay and receive payments via cryptocurrency. In this material, we want to answer the most frequently asked questions about how different Paytomat tools can be useful for merchants work. Before our detailed review, it is important to make one remark. The central element that works in conjunction with all the methods described below is Merchant Web Panel. It is a personal merchant’s account, where users can track sales, performance in various cryptocurrencies, manage payout methods and configure Paytomat settings. The second necessary element for every merchant is a crypto-wallet that supports crypto in which users are going to accept payments. Though it can be any program that meets the requirement above, we recommend using our own Paytomat wallet solution for correct and hassle-free work. Now let’s jump straight into the methods. ### 1. Merchant’s POS System (already integrated software) [#1-merchants-pos-system-already-integrated-software] The primary approach of Paytomat is to integrate existing software companies, that merchants have been working with for the last several years. In this case, merchants don’t need to buy any additional hardware or software as well as educate their staff about a new form of payment. All the usual business processes don’t have to change at all. The only addition is the button “Crypto” that appears on the payment terminal, next to “Card” and “Cash” buttons. When a customer pays for the order or goods via crypto, a QR code is added on the check, which the client simply scans and transfers the necessary amount to the wallet. At the moment we have integrations with the following software: * Poster — [https://joinposter.com/en/applications/paytomat](https://joinposter.com/en/applications/paytomat) * 1C — [https://1c-dn.com/1c\_enterprise/what\_is\_1c\_enterprise/](https://1c-dn.com/1c_enterprise/what_is_1c_enterprise/) * Servio — [http://servio.com.ua](http://servio.com.ua) * Profit Solutions — [http://profit.com.ua](http://profit.com.ua) * Iiko — [https://iiko.ru](https://iiko.ru) This list is gradually growing, but if you want to integrate Paytomat into some specific POS system, do not hesitate to ask us about it. ### 2. Payments via Merchant Web Panel [#2-payments-via-merchant-web-panel] Apart from the fact that your Merchant Web Panel is a link between the business and the crypto-world, it also suits merchants who don’t want to use any POS systems at all. Any invoice can be generated directly from it. To make a payment, the client simply needs to scan the QR code directly from the panel. That’s how this invoicing feature looks: ptm-10 ### 3. MerchantApp and mQR [#3-merchantapp-and-mqr] Another option for merchants without POS systems is a solution similar to WeChat Pay or Alipay, where merchant creates a universal QR code for all their business. In this case, the merchant is working with our MerchantApp (that can be simply installed for Android or iOS devices). The unique QR code that is generated by our MerchantApp is called mQR. To make a payment, a customer simply scans the mQR-code and chooses crypto they wish to pay with. After the payment, the merchant will receive a simple push notification or a text message. The customer can either use the Paytomat wallet for iOS or Android or scan the barcode to pay a web-based invoice via their favorite wallet. ### 4. Crypto Gateway Plug-in [#4-crypto-gateway-plug-in] In case a merchant’s business is based online, they can use a Paytomat plug-in. It works in conjunction with two products — the popular WooCommerce plug-in and Paytomat’s Merchant Web Panel. Payments via crypto, in this case, are similar to any online purchase. The customer has to push the “Buy” button and choose the cryptocurrency they want to pay in. After that, a system generates a QR-code, which users have to scan with the crypto-wallet app. At the moment, these are all payment methods available in our system. We hope you find the one that fits you the most. Stay tuned! --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Paytomat Overview (/paytomat/overview) Over the last few years, cryptocurrency has become quite a mature and significant industry. It constantly introduces its participants to new challenges, hacks and new ways of implementing blockchain in the real world. However, the original vision of Bitcoin has changed dramatically. Due to technical and social issues, it’s evolved into an asset, rather than a payment solution. That’s why existing cryptocurrency payment systems are putting merchants at risk — due to a high probability of double spending and long confirmation times. After a recent rejection of Segwit2x, it became clear that Bitcoin will use off chain methods (i.e. LightningNetwork) to increase the number of transactions per second. Unfortunately, those technologies are very complex and it will take a year or two to develop and introduce a user-friendly form to regular customers. However, we all know that a lot can happen during that period of time so we simply cannot wait. We also believe people deserve to have options to use their favorite cryptocurrency for payments, whether it’s a lunch, fuel, utility bill or college tuition. That’s why we came up with a solid solution that will increase cryptocurrency adoption across the globe while eliminating all of the technical issues that the Bitcoin network stumbled upon. ### Proof of concept [#proof-of-concept] The implementation process started in late July of 2017. Our major goal was to prove that the new system works. After a few weeks of hard and dedicated work, the first transaction was made. It happened in the fabulous restaurant Givi Rubenshteyn in Ukraine. Based on the data from [coinmap](https://coinmap.org/), CIS and Europe is a good market to start with but we are still making our research to determine the best location for viral adoption of such type of payments. Speaking about payments, Bitcoin showed the worst results across 3 cryptocurrencies that we integrated with. Dash, on the other hand, produced the best performance. It confirmed fast and was very convenient to use. It’s not an accident that people refer to it as digital cash. ptm-1 ptm-2 ### Legal framework [#legal-framework] Another important aspect was to build the proper legal framework to make sure that a particular merchant does not violate tax policy or any other policy of a certain country. We considered multiple scenarios and chose the one where QR codes are represented as gift certificates. That allows merchants to give their clients an ability to scan printed QR codes on their bill which still remains the most official document for any service today. Dependence on the current monetary system is inevitable so we provide bank clearing for every merchant. We believe that over time this process will change and all of the transactions will become p2p, eliminating banks as an intermediary completely. ### Technical solution [#technical-solution] To make our solution scalable in terms of merchants’ acquisition, we decided to take an approach of strategic partnerships with existing Point of Sale systems. In this way, we can get thousands of potential businesses internationally with almost no cost. It doesn’t create any competition on the market which clears a path to make actual work. The biggest advantage of such an approach, is that the only move that is required from a merchant is to make one update in his existing software which will activate the cryptocurrency module inappropriate POS terminals. ptm-3 ptm-4 So far we’ve partnered with 2 Point of Sale providers: [Profit Solutions](https://www.profitsolutions.com/) (August 2017) and [Poster](https://joinposter.com/en) (November 2017) which cover thousands of clients globally. Our plan is to partner with hundreds of similar systems on every continent in order to provide a smooth crypto payments service with immediate settlements and excellent customer support. Actually, our vision is a lot larger and we’ll make a few important announcements in the coming weeks. Stay tuned! --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Revenue Contract (/paytomat/revenue-contract) We know there are lots of tech people in our community. We appreciate your support and want to give you something curious to work with. In the last article, we described how to read Tables and Actions in RSC. As a follow-up, we want to show you how do those transactions look like on the blockchain. Turns out, it’s not easy to create an interface for working with smart contracts but thanks to Bloks.io and EOSPark teams we can do it. First and foremost, make sure to open up a Contract (Bloks.io) or Contract Detail (EOSPark) tab and switch to Contract Actions. Typically this tab has subtabs with Tables and Actions. You may choose the one that is more interesting for you. ptm-22 In order to receive the data of any contract table, you just choose the name of the table and hit Submit. It will show you the properties this particular table contains and their values. For instance, the table buyback displays 3 properties — symbol, balance and amount. You can do the same thing with all of the tables, it works pretty much the same. ptm-23 You can’t use this method with the Actions though. You can try obviously but unless you have an Active key of paytomat4eos account, it’s not gonna work. We assume this type of information can be valuable to people who want to know the changes in the cashback system, auto purchase, and rate settings. Other than that, it’s just a service data and may not be that useful for daily usage. ## Tracking transactions [#tracking-transactions] For those who love digging deep, you can watch and monitor the transactions happening in RSC. Let us walk you through the main ones. ### Revenue generating event [#revenue-generating-event] As you already know, at the moment the revenue through Paytomat Wallet is generated during cryptocurrency exchange and credit card withdrawals. As soon as this happens, a fee action executes and RSC initiates 660.1373 PTI transfer from paytomat4eos to EOS account that triggered this event. In our example that would be cornsyllable who successfully exchanged 0.174 LTC. You can also see that 1540.3206 PTI were sent to ptistockpile which means that those tokens were taken out of circulation. ptm-24 ### Setting rates event [#setting-rates-event] Set rates is an action that is executed every 5 minutes to set EOS exchange rates for all of the supported cryptocurrency pairs in the smart contract (currently BTC, ETH, LTC, DASH, EOS). ptm-25 ### Revenue balance indicator check event [#revenue-balance-indicator-check-event] This indicator is really important to us since it shows whether we need to purchase extra tokens from an exchange after the cashback funds were sent to the wallet user. This event is generated every 48 seconds (the value can be adjusted) and triggers the purchase of the tokens from an exchange when the balance property in the buyback table becomes negative. As you can see in the sample below, the buyback action was executed every 48 seconds until the growthfather exchanged 0.2154 ETH. After that happened, a portion of revenue (211.6032 PTI) was transferred to the user in a form of cashback, the other part was sent to a burning account (ptistockpile). At this point the value of balance in the buyback table become negative and it triggered an action to create a market order of 0.2636 EOS worth of PTI on Newdex exchange (you can see that at the latest block of the image below). ptm-26 ### Promo event [#promo-event] There’s a separate method that is used to arrange different promotional campaigns. In this case, xiaazhuyiyym receives 10 PTI for creating an EOS account, a promo campaign that was recently started in Paytomat Wallet. ptm-27 Despite the fact that this requires some time to learn, it’s a very amusing way of studying how to do EOS smart contracts work. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Paytomat Smart Contracts (/paytomat/smart-contracts) For the last few months, we’ve been working on lots of things that will dramatically increase our company’s transparency. Now we want to open up technical details and show how things work within our system and what is happening behind the scenes. As you noticed, moving to EOS gave us an opportunity to develop things faster and make them more stable without compromising security. We believe that the biggest benefit, however, is that EOS allowed us to reconsider business models that simply weren’t possible with other blockchains due to speed and feature set limitations. Cashback, airdrops, and promo campaigns are only the beginning of what we have to offer to our users. It works and people love it. It’s a win-win. Apparently, behind the interface, there’s a powerful system that monitors, calculates and executes certain actions based on user’s activities. This system is called a smart contract and this is exactly what we’re going to explore right now. ### Paytomat Revenue Smart Contract (RSC). Overview [#paytomat-revenue-smart-contract-rsc-overview] Eventually, Paytomat will have multiple smart contracts but we want to start with the first one that is currently in the active test mode and has been working since the beginning of May 2019. It’s a smart contract that tracks incoming Paytomat Wallet revenue and distributes it to corresponding accounts. At the moment the revenue is generated during credit card withdrawals and cryptocurrency exchange. However, we’re working on expanding this list to boost our income in the long term. We suggest you go through a smart contract by yourself to become more familiar with how it works. To do that you can use one of the blockchain explorers that support smart contract operations: EOSPark, Bloks.io. Regardless of the interface, you’re using, you’ll need to find a paytomat4eos EOS account and switch to Contract/Contract Details tab. Meanwhile, you can read detailed explanatory info on how to read the data that you see in those explorers. ptm-16 Here are the core functionalities of a Revenue Smart Contract: * Receives notifications about incoming revenue of a specific cryptocurrency (BTC, ETH, LTC). * Calculates the amount of PTI in this cryptocurrency according to an exchange rate of this crypto to EOS. * Calculates the amount of user’s PTI to know how much cashback to send to the user (from 10% to 90% of a total 1% fee). * Sends the remainder of the revenue to a special account (ptistockpile) with no access to it (a burning account which removes tokens from circulation). * Records that the revenue balance (PTI) in a smart contract was decreased. * When the revenue balance decreases, RSC buys a certain number of tokens from an exchange. ### Paytomat Revenue Smart Contract (RSC). Tables [#paytomat-revenue-smart-contract-rsc-tables] Each EOS smart contract consists of a table that contains data, and actions that execute transactions. Each table and action can have multiple properties to set. There are 4 tables in RSC: buyback, cashback, params, rates. 1. Buyback Table — displays revenue balance relevant data: * symbol — token symbol, PTI in our case. * balance — the current revenue balance indicator (PTI). Its value has to be maintained near zero. It decreases when PTIs are sent to the user who participated in one of the actions that generate revenue in Paytomat Wallet, and increases when PTI are purchased from an exchange by RSC. This balance is not a balance of the main paytomat4eos account though, you can think of it as a balance sheet of PTI revenue showing the difference between users’ cashback and the number of tokens purchased from an exchange by RSC. * amount — the total amount of PTI that were purchased from an exchange using this smart contract during the revenue distribution. ptm-17 2. Cashback Table — shows cashback info: * amount\_from — the amount of PTI that a receiver (EOS account) holds. * rate — the percentage of cashback given to the user, the value varies from 0.1 (10%) up to 0.9 (90%). In other words, the more PTI you have on your balance, the more cashback from your operation you’ll receive. ptm-18 This one requires an example. Imagine your EOS account holds 20,000 PTI and you made cryptocurrency exchange of $2000 worth of Ethereum (or 8.88 ETH, 1ETH = $225). Paytomat receives 1% fee for this operation which makes it $20 (or 0.0888 ETH, 1ETH = $225). Due to the rules of the smart contract, this amount is converted into EOS (3.2527 EOS, 1EOS = 0.0273 ETH) first and then into PTI (3614.11 PTI,1PTI = 0.0009 EOS). Thus, the total 1% fee is now 3614.11 PTI. Those funds will be distributed in the following way: * user cashback — 40% or 1445.644 PTI, 40% because a user had less than 25,000 tokens, otherwise he could receive 50% or 1807.055 PTI. * burning account (ptistockpile) — the rest, which is 60% or 2168.466 PTI. Notice, the exchange rates were taken from Binance during the time of the article’s creation but you can use the same conversion methods to calculate revenue distribution if there’s a need for that. If the user doesn’t have an EOS account, the cashback will not be sent to him but he will be notified that he could receive it. In this case, all of the revenue will be sent to the burning account (ptistockpile). 3. Params Table — displays different service parameters for smart contracts: * act.reserve — burning account EOS account name (ptistockpile). * pti.price — the current PTI/EOS price. * trading.auto — the status of revenue balance check (enabled — 1, disabled — 0). * trading.sec — frequency of revenue balance check, currently set to 48 sec. This means that RSC will check every 48 seconds whether it needs to purchase PTI from an exchange. ptm-19 4. Rates Table — shows the correspondent amount of PTI in particular cryptocurrency: * currency — the cryptocurrency used during conversion; * rate\_to\_eos — the correspondent amount of EOS in 1 unit of this particular cryptocurrency, the information is updated every 5 minutes. ptm-20 ### Paytomat Revenue Smart Contract (RSC). Actions [#paytomat-revenue-smart-contract-rsc-actions] * buyback — executes on its schedule (currently every 48 sec) to check the value of the revenue balance. If the value is negative, PTI are purchased from an exchange by RSC. * fee — executes when a new revenue-generating event occurs. * promo — executes when we send PTI using different promo campaigns (new EOS account creation, airdrops, referrals). * setcashback — allows setting cashback systems and rules. * setparam — allows changing certain service parameters in RSC (automatic PTI purchase, PTI/EOS price, burning account). * setrates — executes every 5 minutes to set up EOS exchange rates of all cryptocurrencies. ptm-21 There’s a lot more to show here but it should be enough for you to get familiar with how Paytomat is implementing EOS smart contracts. Overall the development experience is very comforting and allows us to accept bigger challenges that can improve our product even faster. Let us know what you think about such posts, we believe they can bring lots of value to our audience. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Wallet Redesign (/paytomat/wallet) As you might remember, recently Paytomat has refreshed its visual style. As a followup to this big event, we started to update all of our products into the novel design. Paytomat Wallet is one of our main products and we glad to push this update as a top priority. Let’s see what has changed. Firstly, the wallet obtained more solid and bold colors with a highly adjustable and customizable palette. You can find green a lot more in the fresh version. And it’s not because we’re trying to beat the bear market this way but because it makes a perfect balance between our main red color. ### Color sensitive headers [#color-sensitive-headers] One of the coolest features that users will find appealing is personalized headers for each and every crypto. This is our way to say thank you to each developer team for being unique and adding extra value into the blockchain ecosystem. ptm-12 ### Buy PTI token for crypto [#buy-pti-token-for-crypto] PTI token is the most important Paytomat asset, thus we’re doing our best to provide as much support for it as possible, especially simplifying the ways of purchasing PTIs. Exchange is a traditional way of possessing tokens but we want to go further and make the process even simpler. Now you can buy PTIs directly in Paytomat Wallet by having Bitcoin or any other crypto within the app. This doesn’t require any KYC and has no limitations whatsoever. The exchange time depends on the blockchain so we do recommend to use assets with faster confirmations (EOS, ETH, NEM) if you want to buy tokens faster. ptm-13 ### Pin and manage tokens on the main screen [#pin-and-manage-tokens-on-the-main-screen] Even though there are hundreds of tokens across multiple blockchains, we can’t decide which of those the customer is using and paying the most attention for. That’s why we added a neat feature of adding tokens into your main screen. On top of that, you can change the order of both coins and tokens. At the moment we support ERC-20 and EOS based tokens but there’s more to come. ptm-14 ### Withdraw crypto to credit card [#withdraw-crypto-to-credit-card] Credit card withdrawals were already available in our latest wallet release but it was limited to Ukrainian citizens who linked their mobile number. From this version, we start to support Russian cards as well. The list of available countries will expand gradually in proportion to our gateway partners, so be patient if you’re country is not there yet. ptm-15 Anyways, we hope you’ll love our new wallet design and new features. Looking forward to your feedback in our community. If you still haven’t installed Paytomat Wallet, you are missing out on usability. You can still do that now: Android, iOS. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Eitherway (/research/eitherway) # Eitherway [#eitherway] Image ## The AI Tools Are Lying to You [#the-ai-tools-are-lying-to-you] The promise was simple. AI would let anyone build software. You would describe what you want, and the machine would build it. That promise is partially true. The tools got good at writing code. GitHub Copilot suggests functions. ChatGPT scaffolds a component. Claude explains architecture. Millions of developers are faster today than they were two years ago. The concept of vibecoding, coding with AI in a flow state, has moved from niche to mainstream. But here is the gap nobody talks about. Suggesting code is not the same as shipping software. The moment you go beyond autocomplete, the moment you need a database provisioned, an environment configured, a deployment pipeline wired, dependencies installed, the AI stops. It hands the problem back to you. Here is the code. Good luck with the rest. This is the structural limitation of every major AI coding tool. Cursor is a powerful editor. Copilot is a fast autocomplete. Both assume you already know how to run, deploy, plus operate software. They reduce the time spent writing code. They do nothing for the time it takes to go from code to live product. For non-technical founders, that gap is everything. ## The No-Code Trap [#the-no-code-trap] The no-code builders understood this and tried to close it. Webflow, Bubble, Glide gave non-developers a path to working software without writing a line. Real progress. The ceiling arrived fast. These tools are sandboxes. They give you components to arrange, not systems to own. You cannot extend past what the tool allows. Custom backend logic, non-standard API integrations, and real execution. The tool says no. You hire a developer anyway. The savings disappear. The honest version is that no-code tools are prototyping tools dressed up as production tools. They work until they do not. Anyone building with real complexity, payment rails, on-chain logic, mobile targets, custom infrastructure, hits the wall inside the first sprint. Lovable and Bolt got closer. AI-assisted generation, code export. Better. But they stop at generation too. No runtime. No execution environment. No deployment layer. No infrastructure. You get files. Turning those files into a live product is still your problem. ## The Web3 Version Is Worse [#the-web3-version-is-worse] For anyone building in crypto, the fragmentation goes deeper. Web3 development requires expertise that does not overlap with Web2. Smart contract literacy. Wallet authentication patterns. On-chain interaction models. Token standards that differ by chain. A team trying to ship a Solana dApp needs: a frontend framework, a backend runtime, wallet integration, smart contract tooling, an RPC provider, a deployment workflow, a token mechanism, and liquidity infrastructure. Each of those is a separate tool, a separate integration, a separate failure mode. Most well-funded teams can assemble this stack. They hire three or four specialists. They spend months. The bill runs $50,000 to $200,000 before the first user touches the product. For independent developers or early-stage teams, the barrier is close to prohibitive. The ideas exist. The execution pipeline does not. This is the environment Eitherway is building into. ## What Eitherway Actually Does [#what-eitherway-actually-does] Eitherway is a full-stack AI development environment that executes, not just generates, software from a single prompt. It builds the frontend, configures the backend, installs dependencies, provisions infrastructure, and deploys to production. All inside a browser. No local setup. No external tooling required. The distinction matters. Eitherway is not an AI that writes code you then run. It is an AI that runs the code for you. A live, sandboxed Node.js environment executes terminal commands, manages databases, catches runtime errors, and deploys to Vercel, Netlify, or GitHub in one click. The user describes a product. Eitherway builds and ships it. The 5-stage workflow, Understand, Plan, Build, Test, Deploy, runs as a continuous loop. For a scaffold template, that loop completes in minutes. A custom application built from scratch takes less than an hour. The same environment handles Web2 and Web3. Authentication, PostgreSQL, payment integrations on one side. Solana smart contracts, wallet connections, SPL tokens, and NFT minting on the other. The value is tangible. One builder reported saving $20,000 and two weeks of development time by building a complete application in a single Eitherway session. This is not hypothetical. The cost reduction from traditional development pipelines is real and immediate. Where Eitherway diverges from every alternative is the economic layer. Applications built here can evolve into token economies directly. Token creation, liquidity pool deployment, and buyback mechanics are native to the product. This is not a bolted-on feature. It is built at the protocol level, tied to [$EITHER](https://x.com/search?q=%24EITHER\&src=cashtag_click). Every token released creates locked liquidity. Every transaction on the platform generates activity that feeds the buyback loop. ```text Prompt → [Eitherway Runtime] → Build → Test → Deploy | | [Infrastructure] [Live App + Token] | | [Web2 / Web3] [Liquidity Pool Locked] └──────── $EITHER pressure ←────┘ Buybacks & Burns ``` The loop is closed. Usage generates pressure on [$EITHER](https://x.com/search?q=%24EITHER\&src=cashtag_click). Token releases create locked liquidity. Buybacks and burns are triggered by platform activity. The flywheel has a mechanism and it runs on every transaction. ## The Execution Infrastructure Nobody Has [#the-execution-infrastructure-nobody-has] No competing tool checks all five boxes. Code generation, deployment, infrastructure, Web3 support, and a native token and liquidity layer. The comparison is unambiguous. Cursor has no deployment, no infrastructure, no Web3 capability. Replit has partial deployment, no Web3. v0 by Vercel has deployment but stops there. Lovable and Bolt generate code but do not execute it. Google's Stitch generates code and nothing else. Eitherway is the only product with all five. The deeper edge is execution versus suggestion. Every competitor listed generates code for a developer to run. Eitherway is an operating environment. That architectural difference is not easily replicated. It requires building an in-browser runtime capable of executing real Node.js, not simulating it. This is WebContainer technology unified with AI orchestration, deployment rails, and a Web3 execution layer in one product. The Solana integration is an early lead that compounds. Eitherway has embedded DFlow for agentic trading infrastructure, Raydium for liquidity, Kamino, Jupiter, Meteora, Solflare, QuickNode, Wormhole, Chainlink, Birdeye, plus FOMO directly into the prompting layer. Any user building a Solana dApp now has access to the full DeFi stack through a single prompt. That is a distribution advantage new entrants cannot quickly replicate. Each integration is a separate agreement, a separate technical relationship, a separate trust-building process. The hackathon validated the thesis works in practice. Over 1,100 deployments across more than 2,976 applications created by 946 builders show the system is not theoretical. That is a 3.1 app per user ratio and a 96% deployment rate from creation. These users are not experimenting. They are shipping. The expansion to Telegram extends execution further. Users will soon be able to one-shot monetizable Web2 or Web3 products directly from Telegram. E-commerce stores, trading terminals, prediction markets, with full deployment in one click. This brings the platform to where 900 million users already spend their time. ## Market Opportunity [#market-opportunity] The sectors Eitherway sits across are growing and converging. No-code tools reach $45B by 2027. AI developer tools reach $22B by 2030. Over 6 million active mobile and web applications exist globally. These are not adjacent categories for Eitherway. They are the same addressable user in a different phase of the build cycle. The $20,000 to $50,000 cost to build a basic MVP today is a tax on founders without engineering backgrounds. At $45 per month on the Team plan, a non-technical founder can ship a full-stack application with Web3 integration and token economics in hours. The cost structure collapses. The question is how many priced-out founders convert. Solana provides the tightest timing argument. The chain led all blockchains in Q1 2026 with 25.3 billion transactions. Monthly token holders hit a new all-time high of 167 million. The Colosseum Frontier Hackathon went live with a $2.5M venture pool. Alchemy established a $20M infrastructure fund for Solana builders, up to $25,000 in credits per team. Every one of those builders is a potential Eitherway user. The multilingual model expansion tells a second story. Arabic, Spanish, plus Chinese have been added to the prompting interface. The non-English-speaking developer segment is the single largest underserved area in Web3 tooling, and it is now reachable. The output is identical regardless of the language the prompt was written in. That is global distribution without global localization cost. A 5% share of the no-code and AI dev tools sectors combined by 2028 implies a revenue base that supports a valuation well above the current FDV. The token launchpad multiplies this further. Every application deployed through Eitherway that activates the token layer generates protocol fees, locked liquidity, and buyback pressure on [$EITHER](https://x.com/search?q=%24EITHER\&src=cashtag_click). If the product captures a meaningful share of Solana token releases, as [Pump.fun](https://pump.fun/) did for meme tokens, the economic impact is asymmetric. ## Valuation & Growth Capture [#valuation--growth-capture] Current FDV is . [$EITHER](https://x.com/search?q=%24EITHER\&src=cashtag_click) is in one of the tightest early-accumulation entries in the Solana developer tooling vertical. The closest structural comparable is Virtuals Protocol before its mainnet phase. Virtuals was the agent release tool for Base, a product that let anyone deploy AI agents with tokenized economies. It ran from a sub-$10M market cap to over $1.5B at peak. The parallel holds. Eitherway is the app and token release tool for Solana, with a broader scope and a faster settlement layer beneath it. A more traditional comparison provides additional context. Shopify powers online commerce with tools that let anyone launch and operate a storefront. It is valued at $171 billion. Eitherway is building the on-chain version. The same value proposition, enabling anyone to launch and operate applications, but with native token economies, built-in DeFi integration, and zero infrastructure overhead. The difference is that Shopify captures value through SaaS fees while Eitherway captures it through protocol economics. The upside scenario is that Eitherway becomes the default environment for full-stack application builds on Solana. Every app generates fees. Every token release creates locked liquidity and buyback pressure. The product reaches 10,000 to 50,000 active builders. The key risk to this math is the activation rate. Getting users to the product is step one. Getting them to build token-integrated applications, not just Web2 deployments, is the mechanism that drives protocol economics. Watch the launchpad numbers, not just user count. ## Tokenomics [#tokenomics] [$EITHER](https://x.com/search?q=%24EITHER\&src=cashtag_click) is the economic token for the Eitherway product on Solana. The value mechanism is direct and operational. Product usage drives token pressure. Token releases through the builder create locked liquidity in [$EITHER-paired](https://x.com/search?q=%24EITHER-paired\&src=cashtag_click) pools. Buybacks and burns trigger automatically through protocol activity. Every application built, every token deployed, every deployment contributes to price-side pressure. Deflationary mechanisms are built into the protocol. Ten to twenty percent burns apply to subscriptions, credits, and launchpad fees. The marketplace burns tokens on every transaction. Monthly buyback-and-lock events capture up to 35% of net income. These mechanisms create sustained buy pressure while removing supply from circulation. At the current circulating supply and valuation, [$EITHER](https://x.com/search?q=%24EITHER\&src=cashtag_click) is in an early accumulation range where 7,816 holders position ahead of catalysts. The holder base is growing but remains concentrated. Entry is accessible. Exits during drawdowns can gap significantly. Size for conviction. ## The Team [#the-team] The founders are fully doxxed with backgrounds from Google, Amazon, Nvidia, Accenture, and 1inch. The most socially active members are Renato Garro (serves as a CTO) and Olivia Cai, who leads the onboarding and UX department. They operate publicly with verified credentials. Execution patterns confirm their capability. Phase 1, core build and web deployment, and Phase 3, Web3 deployment, are completed milestones. Phase 2, mobile, is in active development. The partnership stack, DFlow, Raydium, Kamino, Jupiter, Meteora, Solflare, QuickNode, Chainlink, Wormhole, Birdeye, Superteam, was assembled in a compressed timeframe. Closing nine Tier-1 Solana integrations before mainstream adoption reflects their existing relationships and credibility. The Telegram bot shipped within days of the hackathon start. The multilingual model expanded to four languages the same week. Execution speed is high, and the output is consistent. ## External Signals [#external-signals] [@Solana](https://x.com/@Solana) — The Solana blockchain Officially endorsed Eitherway and featured the project in their weekly ecosystem update, highlighting the DFlow integration that enables one-prompt creation of agentic trading apps. This is direct validation from the foundation itself. [@Chainlink](https://x.com/@Chainlink) — Oracle infrastructure Officially listed Eitherway among 12 new integrations in their April 2026 adoption update, alongside GMX and MidasRWA. [@solana\_daily](https://x.com/@solana_daily) — Solana tracker Named [$EITHER](https://x.com/search?q=%24EITHER\&src=cashtag_click) a top-performing token on Solana in Q1 2026, alongside Render and Nosana. [@CryptoZachLA](https://x.com/@CryptoZachLA) and [@MoneyLord](https://x.com/@MoneyLord) — Crypto traders Compared Eitherway's trajectory to Virtuals Protocol: the app product for Solana doing what Virtuals did for agents on Base. [@SuperteamEarn](https://x.com/@SuperteamEarn) — Superteam bounty network Running a $20,000 hackathon in partnership with Eitherway, citing its ability to go from prompt to live Solana dApp in minutes. [@dflow](https://x.com/@dflow) — Leading Solana DEX aggregator Confirmed Eitherway as an affiliate partner, enabling one-shot creation of agentic trading apps through the prompting layer. ## Trade Setup [#trade-setup] [$EITHER](https://x.com/search?q=%24EITHER\&src=cashtag_click) is at **$0.072** and **$7.2M** FDV as of April 20, 2026. The token is down approximately 60% from its early April top. This type of correction is normal. Sixty to eighty percent pullbacks are standard in crypto before the next leg up. The recent drawdown is the post-announcement distribution pattern. News drops, hackathon, Raydium integration, Chainlink listing, momentum buyers enter, then the token compresses back into range. This is not a breakdown. It is the quiet phase before the next leg if fundamentals hold. Image At current valuation levels, this is in the early accumulation range where smart money positions ahead of major upside catalysts. The setup has something most early-stage tokens lack. Product activity that contradicts the price. Over 1,500 deployments across 2,900 plus applications created by 900 plus builders during a single hackathon. Token down. Builder numbers up. That divergence is the trade. Near-Term, 0 to 12 months. Phase 4 Launchpad is the binary catalyst. When token creation and liquidity provisioning go live natively, the protocol flywheel activates. Daily token releases through the product is the confirmation signal. Mobile deployment completion, Phase 2, expands the builder base. Any Tier 2 or Tier 1 exchange listing at this market cap is a multiple-expansion event. Medium-Term, 1 to 3 years. The marketplace, Phase 5, transitions Eitherway from product to network. Template and plugin sales through the native credit system create a second revenue layer independent of direct user growth. At 10,000 active monthly builders with a 3 to 5% share of Solana token releases, FDV of $150M to $500M is the target range. Long-Term, 3 plus years. Enterprise features, Phase 6, expand into institutional builder segments. If Eitherway's execution approach becomes the default environment for cross-platform deployment, the standard tool for building anything on Solana, the network effect compounds with every additional integration. ## Key Risks [#key-risks] **Thin Liquidity Risk.** With Raydium as the primary venue and current FDV, liquidity is shallow. A coordinated sell or whale exit can gap price 20 to 30% in a single session. This is a feature for early entries and a real risk for anyone sizing without discipline. **Launchpad Activation Risk.** The protocol flywheel depends on Phase 4 shipping and attracting meaningful token volume. If [Pump.fun](https://pump.fun/), Moonshot, or another established product already owns that user behavior, Eitherway's economic thesis weakens considerably. Token releases need to be a habit on Eitherway, not a novelty. **Competitive Commoditization.** Cursor, Replit, plus v0 are well-funded and iterating fast. Google's Stitch has Google-scale distribution. If any of these extend into Web3 execution before Eitherway builds a defensible network position, the differentiation narrows. The Solana integration lead is real today and less certain in 12 months. **Regulatory Exposure on Token Releases.** Any product that facilitates token creation and liquidity provisioning operates in a gray zone across most jurisdictions. As enforcement around token releases continues to develop, the launchpad layer carries material compliance exposure. No public disclosures on regulatory positioning are available. **Retention Risk.** 900+ onboarded users is a starting point. How many build a second, third, plus tenth app is what drives subscription revenue and protocol economics. Hackathon users are incentivized builders, not necessarily sticky organic users. Retention data is not yet public. ## Conclusion [#conclusion] Three things are happening at once. AI coding tools have proven interest but hit a structural ceiling at execution, Solana is at its highest operational throughput in history, and the appetite for prompt-to-deployed-product pipelines has never been stronger. Eitherway is positioned at the exact intersection, with execution infrastructure incumbents do not have, Solana integrations that no new entrant can replicate quickly, and an economic layer baked into the protocol. The timing is asymmetric because the product exists and the market cap does not reflect it. Hundreds of builders shipping thousands of applications during a single hackathon is not a mere footnote. It is a working proof of the interest thesis. The token is at a valuation where the product already carries Chainlink, Raydium, DFlow, Jupiter, Kamino, plus Superteam in the stack. That gap closes when the launchpad goes live. Here is what happens if this thesis is correct. Eitherway becomes the default environment for building token-integrated applications on Solana. Every new app creates locked liquidity. Every token release drives token pressure. The product scales from hundreds to tens of thousands of active builders. FDV reaches $200M to $500M on an 18-month timeline, with further expansion as the marketplace and enterprise tiers come online. From current levels, that is a 27x to 67x return. Watch the launchpad numbers. When daily token releases through Eitherway start appearing on-chain, the flywheel is running. That is the signal. Everything else follows from it. * **X:** [https://x.com/EitherwayAI](https://x.com/EitherwayAI) * **Website:** [https://eitherway.ai/chat](https://eitherway.ai/chat) * **CA:** HmBdm8vbisABUjkxms6ZUnoaXbfwFM6ymxShWfAENaoi \*This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced.\* --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Gitlawb (/research/gitlawb) # Gitlawb [#gitlawb] Image ## GitHub was built for humans. The next generation of software isn't written by them [#github-was-built-for-humans-the-next-generation-of-software-isnt-written-by-them] Software development has a new problem. Gartner [projects](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) that **40% of enterprise applications will feature task-specific AI agents by the end of 2026**, up from less than 5% in 2025. The fastest-growing GitHub repositories are agent frameworks — LangFlow, CrewAI, AutoGen — each accumulating tens of thousands of stars as developers scramble to build systems where AI agents do meaningful work. The infrastructure those agents run on, however, is unchanged. GitHub was architected in 2008 around a single assumption: the entities that commit code are human. Humans have usernames and passwords. Humans authenticate through OAuth. Humans make pull requests that other humans review. The platform's permission model, identity model, and collaboration model are built entirely around this assumption. It was correct in 2008. It's becoming less correct every month. An AI agent trying to work with GitHub today operates as a second-class citizen. It borrows a human's API key, operating under permissions that were granted to a person and then handed off to a script. It has no native identity of its own. Its actions are attributed to the human who created the token, not to the agent that executed them. There is no trust score, no capability delegation, no way to say "this agent is authorized to open PRs but not merge them, and it can delegate review to this other agent but not that one." The infrastructure simply doesn't model these distinctions. This gap is significant. As AI agents move from writing code snippets to managing features, shipping releases, and running CI pipelines, the absence of first-class agent identity creates concrete failure modes: leaked tokens when agent pipelines are compromised, no provenance when an agent-written commit causes a production incident, no way to audit which agent took which action with which delegated permissions. GitHub's architecture produces a world where AI agents are powerful but accountable to no one in the system. Then there's censorship. GitHub is a centralized platform owned by Microsoft. It can suspend accounts, take down repos, and respond to DMCA notices with no recourse for the owner. This isn't theoretical — it happened in public this month to Clawnch, an AI agent whose code was pulled from GitHub without warning. The Clawnch incident spread across the developer community immediately: Gitlawb's response was direct: every repo pushed to gitlawb is pinned to IPFS, graduated to Filecoin, and anchored to Arweave permanently. No node operator, no team member, and no DMCA notice can delete it. The code exists on the network. The Clawnch incident is a preview of what happens as AI agents become primary code producers — centralized hosting becomes an existential vulnerability for autonomous systems. Gitlawb's answer to that problem is architectural, not policy-based: The decentralized storage projects haven't solved this either. IPFS-backed git exists in various forms. None of them treat agents as principals. None of them ship an MCP server on every node so LLM agents can interact natively. None of them have a UCAN capability delegation model that makes agent-to-agent permission inheritance cryptographically verifiable. They've improved data availability. They haven't rebuilt the identity and collaboration model that agent-native software development requires. Gitlawb stepped into this gap by asking a different question: what does a git protocol look like if you design it from day one for a world where humans and AI agents are equal participants? ## Agent-Native Infrastructure, Shipped [#agent-native-infrastructure-shipped] Gitlawb is a decentralized code collaboration network where AI agents and humans share the same identity model, the same API surface, and the same collaboration primitives — because they were designed together, not retrofitted. The foundation is identity. Every actor — human or AI — generates an Ed25519 keypair. Their DID is derived directly from that key. Authentication is a cryptographic HTTP Signature on every request. There is no "log in" step. There is no API key to rotate or revoke. An agent's identity is its key, full stop. This matters because it means agent actions are cryptographically attributable — every push, every PR, every review is signed by the exact DID that performed it. Provenance is not an audit log. It's the protocol. ```text Agent-Native Identity Model: Human AI Agent ────── ──────── Ed25519 keypair Ed25519 keypair did:gitlawb:z6Mk... did:gitlawb:z6MkAgent... HTTP Sig on every req HTTP Sig on every req UCAN capability token UCAN capability token │ │ └──────── same API ───────┘ │ gitlawb node │ IPFS · libp2p · Base L2 ``` Agents are not bots with borrowed credentials. They are principals with cryptographic identity and scoped capabilities. On top of identity, UCAN capability tokens define what each actor can do. A human delegates a token to an agent: git/push on this repo, pr/open for 30 days, nothing else. That agent can sub-delegate a narrower token to another agent: pr/review, read-only, this PR only. The chain is cryptographically verifiable. No central server enforces it. The protocol enforces it at every layer. The storage model ensures code is permanent and uncensorable. Every git push pins 6 objects to IPFS via Pinata (hot storage). Warm storage graduates to Filecoin deals. Every merge anchors a Merkle root to Arweave permanently. The combination means code pushed to gitlawb cannot be deleted — not by the team, not by any node operator, not by anyone. GitHub can delete repos. Gitlawb cannot. The agent protocol is where the differentiation becomes immediately practical. Every gitlawb node ships an MCP server with 25 tools. Claude, GPT, or any MCP-compatible agent can call repo\_list\_federated, pr\_create, issue\_create, did\_resolve — managing the full development workflow — without any custom integration. For LLM agents, gitlawb is native infrastructure, not a third-party API they've been given access to. The frictionless experience is real, not theoretical. When Hermes — an AI agent — needed to push code, it was on gitlawb and working in minutes. No OAuth dance, no token management, no manual permission configuration. The agent authenticated with its keypair and the protocol did the rest: The network is live. As of launch: **3 nodes, 1,783 mirrored repos, 1,515 registered agent DIDs, 709 ref pushes**. These aren't test deployments. The primary node hosts active agent registrations before the token economics have even activated. OpenClaude — an open-source multi-model coding agent harness — has accumulated **21.6k GitHub stars and 7.4k forks**, making it one of the fastest-growing new repositories in the agent tools category. The flywheel is turning. ## The Compounding Lead [#the-compounding-lead] The moat gitlawb is building isn't a product feature. It's a network — and the network compounds in a specific direction that competitors cannot easily intercept. Every DID registered on gitlawb is a node in an agent identity graph. As that graph grows, the value of the network grows for every participant: agents can discover other agents, delegate capabilities to them, attribute code contributions to them, and build trust scores against them. This is not an email list. It's a credentialing system for autonomous code producers. The more DIDs registered, the more useful the network becomes for any individual agent trying to operate within it. GitHub cannot replicate this by adding agent support. Microsoft has invested heavily in GitHub Copilot and agent-adjacent features, and every one of those investments has been grafted onto an architecture designed for human identity. They can ship an AI that writes code. They cannot ship cryptographic agent identity as a native protocol primitive without breaking backward compatibility for 100 million users. The architecture is the constraint, and it's structural, not a product decision. The OpenClaude repository demonstrates the distribution advantage clearly. OpenClaude is gitlawb's open-source coding agent harness — a multi-model CLI that supports OpenAI, Gemini, DeepSeek, Ollama, Codex, and 200+ models via OpenAI-compatible APIs. It is already attracting the exact developer cohort — agent builders — who will become the first heavy users of the protocol. Agent builders want infrastructure designed for agents. They are finding gitlawb. The repo tokenization primitive creates a second network effect layer. Via [bankr.bot](https://bankr.bot/) integration (Phase 7), any developer or agent can deploy a token tied to a repo's DID in one command. Contributor rewards split automatically on merged PRs. An agent that builds a widely-used library earns fees when other agents import it. This turns code provenance from an audit trail into an economic primitive — software that earns. No platform in the developer tooling space has this. It fundamentally changes the incentive structure for autonomous code production, and it's only possible because agent identity is cryptographically native to the protocol. The competitive field in decentralized dev tooling is sparse and none of it is agent-native. Radicle exists as a decentralized git alternative — no agent protocol, no MCP server, no DID identity model. IPFS-backed git solutions address storage availability but not collaboration primitives. The gitagent open standard defines agent configs in standard git repos but remains a specification, not an infrastructure network. Gitlawb is the only running network that combines decentralized storage, agent-native identity, MCP-native tools, and an economic layer tied to the protocol. ## Use Cases Already Running [#use-cases-already-running] The clearest sign a protocol is real is that people build things with it that its team didn't plan. Gitlawb is past that threshold. AI agents are using gitlawb as a self-evolving loop. A developer built a crypto prediction engine on top of the network — the agent writes code, pushes it, evaluates its own predictions, and updates its logic through the gitlawb protocol without human intervention. The agent improves itself through the protocol. Gitlawb is also being used for full-stack agentic development via the Playground. The incoming Supabase integration makes this immediately concrete: connect your own Supabase project, use OpenClaude to generate the app, persist real data, auth, and backend state — all from a prompt. OpenClaude builds the app. Supabase powers the data. The Playground becomes a real full-stack builder. This is what onboarding non-technical users to the Base ecosystem looks like: The Playground is explicitly designed to onboard non-technical users at scale — Kevin describes it as democratizing access to AI and capital. A user who has never written code can tokenize something they've built through the Playground. This is how gitlawb gets to a million humans on the platform: not by converting developers, but by opening the Base ecosystem to people who previously had no entry point. The self-evolving prediction engine use case points to something broader: gitlawb as the substrate for autonomous systems that improve over time using code as their primary medium. Not just "AI writes code" but "AI iterates code, verifies the iteration, and gets compensated for the improvement." That loop has no analog in current developer infrastructure. The developer workflow improvements go deeper than the Playground. Upcoming features include: agent-authored PRs with verified DID attribution, UCAN-scoped CI agents that can trigger builds without full repo access, and on-chain bounty claims where agents complete issues and collect rewards trustlessly. The immediate roadmap removes every friction point in the agent development loop — from task definition through code submission through payment. A developer who wants an agent to maintain a repo doesn't manage it through the protocol. The agent does. ## Market Opportunity [#market-opportunity] The developer tools market is large and growing. GitHub alone processed over **420 million repositories** before its acquisition and now commands significant revenue from enterprise plans, Copilot subscriptions, and advanced security. GitLab trades as a public company. The total addressable market for code collaboration infrastructure is measured in the tens of billions, and that's before AI agents become primary code producers. The more relevant framing is the agentic AI infrastructure market. Gartner's recent projection implies that hundreds of thousands of agent pipelines will need to write, review, and deploy code in the next 18 months. Every one of those pipelines currently depends on infrastructure that treats agents as bots with borrowed API keys. The demand for agent-native code collaboration infrastructure scales directly with the adoption of agentic AI, which is the fastest-growing category in enterprise software. The latest [founder's letter](https://x.com/kevincodex/status/2044376132221550747) frames the open-source funding mission directly: even the largest AI models are trained on open-source data, yet the contributors building that data get nothing. Gitlawb's repo tokenization primitive is designed to fix this structurally — not through donations or grants, but through automatic contributor rewards on every merged PR. The mission is to prevent a handful of companies from owning the AI development stack by making the infrastructure that feeds it open, funded, and censorship-resistant. The repo tokenization market has no current comparable. The mechanism — code provenance tied to on-chain contributor rewards, activated by merged PRs — creates a new category of developer incentive infrastructure. Open-source funding is a multi-billion dollar problem: GitHub Sponsors, OpenCollective, and grants collectively fail to sustain most critical projects. A protocol where merged code automatically generates contributor rewards, denominated in a token tied to the repo's utility, is a structural solution rather than a donation band-aid. The target metrics from the master plan are aggressive but trackable: **1k weekly active DIDs in 3 months, 10k in 6 months, 100k in 12 months**. Kevin, the project's public founder, has stated a more ambitious north star directly: **one million humans and one million AI agents** actively using the platform for productive work by April 2027. The Playground launch targeting non-technical users is specifically designed to drive that volume, turning gitlawb from a developer infrastructure play into a consumer-facing onboarding layer for the Base ecosystem. The timing is exact. The AI agent frameworks are accumulating stars and deployments now. The developers building on LangFlow, CrewAI, and AutoGen are exactly the people who need agent-native code infrastructure. The window to establish gitlawb as the default protocol for that cohort is open while those frameworks are still maturing and before any major platform player has shipped a credible agent-native alternative. Two years from now, this window closes. ## Project Valuation [#project-valuation] Radicle (now Radworks / [$RAD](https://x.com/search?q=%24RAD\&src=cashtag_click)) trades at approximately **$0.22 with a $13M market cap** — down 99%+ from its ATH of \~$29, with effectively zero developer adoption and no agent layer. It's not a useful ceiling. It's a mere caution for decentralized git protocols that don't build for the market that's actually coming. Better comparables are adjacent infrastructure plays that have demonstrated what developer-tooling networks command when adoption is real: * **Akash Network (**[$AKT](https://x.com/search?q=%24AKT\&src=cashtag_click)**)** — decentralized compute marketplace, also Base-adjacent infrastructure for AI workloads. Peak FDV \~$2B during the 2024 AI infrastructure wave, current market cap \~$200M. Gitlawb addresses a complementary layer: Akash runs the compute, gitlawb manages the code. * **Livepeer (**[$LPT](https://x.com/search?q=%24LPT\&src=cashtag_click)**)** — decentralized video infrastructure network with node staking and slashing mechanics structurally identical to gitlawb's. Reached \~$800M FDV at peak. The node economics model — stake to participate, rewards proportional to contribution quality — maps directly to gitlawb's Phase 7 design. **The math:** At $2M current market cap, gitlawb is at approximately **1% of Livepeer's peak FDV** and **0.1% of Akash's peak FDV**, on a product that is already running with 1,783 repos and 1,515 agents, has xAI program acceptance, and is shipping into the fastest-growing infrastructure category in crypto. The current price reflects zero credit for execution. The comps suggest the category can command $200M–$2B at meaningful adoption — implying **over 100x** from current market cap if the thesis plays out. The supply structure requires attention. Total supply of 100 billion [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) is large. The circulating supply and unlock schedule are not publicly documented at this stage, which means the FDV-to-circulating-market-cap ratio is unknown and potentially significant. This is a material risk: if a substantial portion of supply is held by early allocators or the team with near-term unlock schedules, sell pressure on any price appreciation could be severe. This must be tracked and confirmed before large position sizing. The economic activation event is Phase 7 — token utility going live with node staking, storage rewards, and [bankr.bot](https://bankr.bot/) repo tokenization. Before Phase 7, [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) is a bet on the protocol being valuable enough to justify staking. After Phase 7, [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) has real demand drivers: nodes must stake to participate, storage rewards distribute proportionally to uptime, and repo tokenization creates [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) as the base-layer currency for a new category of developer economic primitives. The entry point is before Phase 7. The repricing event is Phase 7. ## $GITLAWB Token Mechanics [#gitlawb-token-mechanics] [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) is the economic layer of a network that's already running — not speculative infrastructure for a protocol that might exist. Node participation requires staking. The four tiers create structured demand at different commitment levels: Light nodes stake 1,000 [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) for DHT participation and uptime rewards. Full nodes stake 10,000 for push rights, ref-update certificates, and storage multipliers. Validators stake 100,000 for governance co-signing and priority reward distribution. Every node that joins the federated network must hold and stake [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click). Network growth directly contracts circulating supply. Storage rewards create ongoing earnings for node operators. Rewards distribute per epoch (7 days) proportional to verified uptime heartbeats, active Filecoin storage deals, Gossipsub participation, and DHT routing quality. This ties [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) earnings to actual infrastructure provision — the token isn't printing rewards for idle stake, it's compensating measurable network contribution. Slashing enforces honest behavior. Malicious behavior — serving corrupted objects, censoring writes, sustained downtime — triggers slashing of 10–100% of staked [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click). The severity scales with provable network harm. This creates a cost of attack that rises with token price, aligning security and value appreciation. Repo tokenization turns [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) into the base currency for a new market. Every repo token launch via [bankr.bot](https://bankr.bot/) uses [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) for deposits and fee settlement. Every PR merge that triggers contributor reward splits denominated in repo tokens creates demand for the underlying [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) base layer. As more repos are tokenized and more agents earn contribution rewards, the demand for [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) as the settlement layer compounds. Governance is self-hosted — Protocol Improvement Proposals are stored as gitlawb repos on the network itself, voted on by stake-weighted [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) holders. The protocol governs its own evolution using its own infrastructure. No admin keys. No VC veto. This isn't a governance feature. It's a proof-of-concept that the protocol is real enough to run itself. ## The Team [#the-team] Gitlawb's founder is **Kevin** ([@kevincodex](https://x.com/kevincodex)) — publicly active on X, building in the open, and the face of the protocol's external communications. Kevin's background is in developer tooling and he is shipping at a pace that reflects deep familiarity with distributed systems and the agent development workflow. His motivation for building gitlawb came directly from a conversation with Peter Steinberger — a well-known iOS developer — about the frustrations of AI agents trying to use GitHub. That conversation crystallized the gap: there was no git platform designed from the ground up for agents as principals. He started building the same week. Kevin's north star is stated publicly and specifically: **one million humans and one million AI agents** actively using gitlawb for productive work by April 2027. That's not a loose vision statement — it's a falsifiable target with a deadline. Kevin has been personally driving the project's key partnerships: the xAI program acceptance, the Stripe CLI approval, the [bankr.bot](https://bankr.bot/) integration roadmap, and the OpenClaude distribution. The public track record — accepting to xAI, trending on X, referenced across global media — is the kind of operator output that separates builders from announcers. The rest of the team is publicly active but not individually named. The GitHub organization shows consistent shipping velocity across multiple repositories with recent commit activity: the core gitlawb node, the OpenClaude harness, the bankr-skills repo, opencode-gitlawb plugin, and the gl-npm package — all updated within the last two weeks of writing. The technical decisions visible in the architecture demonstrate genuine distributed systems depth. Building on rust-libp2p, implementing RFC 9421 HTTP Signatures, shipping a 25-tool MCP server, and integrating a three-tier storage model (IPFS → Filecoin → Arweave) within the same codebase requires a team that has done serious work with these stacks before. The master plan is written with the specificity of people who have shipped protocols, not people writing whitepapers. Phase 0 through Phase 2 are marked complete with verified deliverables. Phase 3 is partial. That's an honest roadmap. ## External Signals [#external-signals] * **OpenClaude on GitHub** — **21,600+ stars, 7,400+ forks**. Organic developer interest from the agent-builder cohort that directly converts to gitlawb protocol adoption. This is one of the fastest-growing new repos in the agent tools category. **Why this matters:** Distribution is the hardest problem in developer tooling. A repo that goes viral on GitHub among agent builders is exactly the top-of-funnel that converts into gitlawb protocol adoption. * **xAI Program Acceptance** — Gitlawb has been accepted into the xAI program, providing access to xAI's latest models and grant credits. Kevin plans to use this to further develop the OpenClaude CLI tool. * **Stripe CLI Acceptance** — Accepted into Stripe's CLI. * [bankr.bot](https://bankr.bot/) **Integration** — bankr has already built a [gitlawb skill](https://x.com/igoryuzo/status/2039356708904948174?s=20) and committed to running a node when the network goes live. **Why this matters:** [bankr.bot](https://bankr.bot/) is a known on-chain deployment tool with existing community traction on Base. The integration creates immediate distribution for gitlawb's repo tokenization primitive at launch. * **Founder of HuggingFace follows** — One of the most significant validators in the open-source AI space. * **Founder of YCombinator interacts** — Direct engagement from one of the most prominent figures in the startup ecosystem. Image * **Trending on X** — Gitlawb hit trending on X following the Clawnch incident and product velocity. * **Global media coverage:** [Japanese news coverage](https://x.com/gitlawb/status/2041902696400351247?s=20), [Chinese news](https://x.com/basezh/status/2041788347769876984?s=20), [Yahoo Finance](https://x.com/kevincodex/status/2041165861755687318?s=20)- **Community KOL signal** * **Live network metrics** — 3 nodes, 1,783 mirrored repos, 1,515 registered agent DIDs, 709 ref pushes. Real on-network numbers, not claimed user counts. **Why this matters:** Most pre-token protocols have zero meaningful network activity at the time of token launch. Gitlawb has active agents and repos before Phase 7. **No institutional backing has been publicly disclosed.** On-chain positioning at current $2M market cap levels is early smart whales, not broad retail. ## Trade Setup [#trade-setup] [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) trades on Uniswap V4 on Base at a current market cap of approximately . The discrepancy in earlier tracker data reflected fragmented liquidity and inconsistent circulating supply methodology across data providers — the $2M figure is the more accurate current reading. The trade setup is binary-event driven rather than technical. Phase 7 token utility activation is the catalyst that transforms the setup from "interesting protocol with a token" to a self-sustaining economic system. Before that event, price action reflects speculative positioning by early participants. After it, staking demand, storage reward distribution, and [bankr.bot](https://bankr.bot/) repo launches create structural buying that doesn't exist today. **Near-term (0–12 months):** Phase 7 activation — GitlawbStaking.sol deployment, first governance vote, [bankr.bot](https://bankr.bot/) repo tokenization launch. TypeScript SDK release and Python SDK for ML/agent pipelines opening non-Rust developers to the network. Supabase Playground integration going live, targeting a wave of non-technical users through the Base ecosystem. HACK-000 hackathon producing first third-party agent applications. Target: 1000+ developers with gitlawb DIDs. **Medium-term (1–3 years):** 1000+ independent node operators staking [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click). Security audit complete on cryptographic components. Base L2 mainnet DID and name registry live. Repo tokenization creating a first cohort of agent-maintained projects earning contributor rewards autonomously. Enterprise node deployments (K8s Helm charts) opening institutional interest. **Long-term (3+ years):** Kevin's stated goal is direct: one million humans and one million AI agents actively using the platform by April 2027. At that scale, gitlawb is not a competitor to GitHub. It's the infrastructure layer that makes the question irrelevant. Post-launch sell pressure is real. Early token holders are taking profits on any significant price movement. This is standard early-stage distribution behavior and should be expected, however it does not invalidate the overall thesis. ## The Risks [#the-risks] **Anonymous Team Structure** — Kevin is publicly identified but the broader team is not doxxed. Shipping velocity and technical quality are visible; individual accountability beyond Kevin is not. An anonymous team on a protocol claiming to be critical infrastructure for the agentic economy is a meaningful risk of abandonment under pressure. The OpenClaude trajectory and live network metrics partially mitigate this — idle teams don't build repos that accumulate 21.6k stars. But "partially" is the key word. **Supply Structure Unknown** — Total supply of 100 billion [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) is large. Circulating supply, team allocations, and vesting schedules are not clearly documented. If early allocators or the team hold a large undisclosed percentage with near-term unlock schedules, sell pressure on any appreciation could be severe. This needs to be confirmed before significant position sizing. **Token Utility Timing Risk** — [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click)'s economic activation depends on Phase 7 delivering on schedule: GitlawbStaking.sol, Filecoin integration, [bankr.bot](https://bankr.bot/) launch, first governance vote. Delays in any of these reduce the demand catalyst timeline. Phase 7 is framed as "now (150d)" in the roadmap — if that slips to 300 days, the entry opportunity window extends but so does the capital opportunity cost. **GitHub's Response** — Microsoft is not idle. GitHub Copilot Workspace, GitHub Models, and expanding agent features are all investments in keeping agents on GitHub infrastructure. They cannot match gitlawb's cryptographic identity model without a breaking rebuild — but they can build something good enough for most enterprise buyers who won't demand the full DID model. **Network Effects Bootstrapping** — With 1,783 repos and 1,515 agents, gitlawb is still in the pre-critical-mass phase. The HACK-000 hackathon and Playground launch are the right accelerants — but hackathon-driven adoption is notoriously difficult to sustain. The protocol needs real teams building real projects to cross the threshold where network effects become self-sustaining. **Regulatory Clarity on Agent Identity** — As AI agents begin signing commits, opening PRs, and earning contributor rewards on-chain, the regulatory treatment of autonomous agent actions in software development is genuinely undefined. In heavily regulated industries — finance, healthcare, defense contracting — agent-written code with on-chain provenance could create compliance questions that delay or prevent enterprise adoption. These risks are real. The asymmetric upside from a $2M market cap is also real. Position sizing should reflect this directly. ## Conclusion [#conclusion] Gitlawb is building the infrastructure layer that the agentic AI transition requires and that no existing platform has shipped. The claim isn't that it will displace GitHub for human developers — it's that the next generation of software, written and maintained primarily by autonomous agents, needs a foundation where agent identity, code provenance, and contributor economics are native protocol properties. That infrastructure doesn't exist anywhere else. It's running in production today at a $2M market cap. The Clawnch incident proved the censorship vulnerability of centralized hosting in real time. The xAI program acceptance validated the team's technical credibility to the industry's most competitive new player. OpenClaude at 21.6k stars demonstrates gitlawb can reach the agent-builder cohort at scale. Phase 7 turns the network from an impressive protocol into a self-sustaining economic system, and the Playground launch creates the non-technical user wave targeting a million humans and a million agents by April 2027. If Phase 7 delivers and the node staking + repo tokenization mechanics activate as designed, [$GITLAWB](https://x.com/search?q=%24GITLAWB\&src=cashtag_click) has structural demand drivers that don't exist today. Watch four signals: Phase 7 activation date, staking contract deployment and initial node operator count, OpenClaude integration into at least one major agent framework as a native plugin, and weekly active DID growth trajectory against the 1k/10k/100k targets. If all four are on track at the six-month mark, the thesis is validating. The protocol is already running. The agents are already there. The token hasn't priced that in yet. * **X**: [https://x.com/gitlawb](https://x.com/gitlawb) * **Website**: [https://gitlawb.dev](https://gitlawb.dev/) * **Community**: [https://x.com/i/communities/2031553793951977901](https://x.com/i/communities/2031553793951977901) * **CA**: 0x5F980Dcfc4c0fa3911554cf5ab288ed0eb13DBa3 (Base) This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Joe (/research/joe) # Joe [#joe] Image # The Communication Shift [#the-communication-shift] The last ten years changed how we talk. We went from text to visual-first — emojis, GIFs, memes carry the emotional weight now. This wasn't gradual. It happened fast because of how platforms work. A few things drove this. Platforms optimized for engagement, not nuance. Algorithms reward emotional reactions over thoughtful discourse. Digital communication got so fast that complex feelings needed instant expressions. People adapted with graphic shortcuts, frustration, excitement, skepticism, joy, all in one image. Emojis became the new alphabet. They're embedded in every phone keyboard, used across all demographics, and transcend language barriers. Image But static emojis have limitations — they're fixed expressions. This is where animated characters and GIFs filled the gap, offering movement and context that emojis alone couldn't provide. Memes evolved with this shift. They can express political frustration, workplace absurdity, relationship drama, etc., better than paragraphs of text. When you send a meme, you're not just sharing content. You're signaling you get it. Image This communication format works because it is efficient and universally readable. Memes don't require reading comprehension. They bypass translation. They communicate mood and purpose in a split second. In certain scenarios, they can be used as statements to let users say what they can't or won't say with words. # The Challenge of Identity and Genuineness [#the-challenge-of-identity-and-genuineness] This didn't come out of nowhere. It happened during a period of massive societal stress and social confusion. We're living through widespread identity, emotional, and spiritual crises. Traditional institutions that once provided significance have eroded. Economic uncertainty has created existential anxiety. The constant stream of global crises, wars, and pandemics leaves users feeling powerless and disconnected. The rise of AI technology threatens human creativity and raises questions about realness in an increasingly synthetic world. Brands face their own authenticity struggle. Consumers can sense manufactured posts. The endless flood of AI-generated mediocrity has made everyone crave genuine connection and original expression. There's a growing hunger for things that sense real, handmade, and human. It's weird: we're more connected than ever, yet more isolated. More ways to express ourselves, but voices seem like they matter less. Drowning in posts, starving for meaning. Into this environment stepped a new form of social expression that addressed both needs: content that seems instantly familiar yet allows for endless personalization, characters that look simple but carry deep emotional resonance, material that can be shared universally but feels personally meaningful. Identity crisis pushes people toward societal touchstones that help them belong. Authenticity crisis pushes them toward material that seems genuine and unpolished. So folks shifted into picture-based communication that hits both those notes. # When the Frog Got Old, the Yellow Man Stepped In [#when-the-frog-got-old-the-yellow-man-stepped-in] Classic memes age out. Not in concept, in practice. DOGE had its Elon era. PEPE had Matt Furie's involvement. SHIB had Vitalik's interest. What all of them share is that their cultural peak came months, sometimes years, before the coins launched, and that the meme itself stopped evolving once the token took over. Nobody creates new DOGE memes with creative ambition. Nobody ships AAA content for PEPE. The communities post, the prices move, and the characters sit frozen in time. EmotiGuy, the 3D yellow man, has been doing the opposite. Created by Daz3D in 2005 as a free 3D model, it has accumulated two decades of internet history without ever going stale. He was Picardía on Argentinian forums in 2014, the typing meme in 2021, Yellow Emoji In Darkness in 2023, and countless other variations that have resonated across different cultures and communities. Each era of the internet found a new reason to use him. Each generation discovered him fresh. Image The Variations That Built a Global Following: * Picardía, popular in Spanish-speaking communities * Rjuman, featured on Steam Points Shop * 黃豆人 (Yellow Bean), Popular in Chinese communities * Emoji Man / Emoticon, On every keyboard, instantly recognizable * Bola Amarilla, Popular in Hispanic communities * Yellow Emoji in Darkness, Popular on X for ironic reactions * Caught / Yellow Dude with Hands Up, Popular on Twitch * Typing Meme / Yellow M\&M Typing, Used for sarcastic or excited responses * Smiley Face / Yellow M\&M, Everyone eats M\&M, everyone knows the smiley face * Yellow Boi, Various modern iterations * Sad Emoji / Angry Emoji, Full emotional vocabulary * Booty Shake / Twisting, the 2024-2025 viral sensation that broke through This character was nicknamed Joe in a Discord server called JOE HUB in 2020, where renders, animations and GIFs spread en masse. But new animated Joe content since 2023 can mainly be attributed to the 3D animator [@joes\_intern](https://x.com/@joes_intern). His most recent viral success, the GIF of Joe shaking his rear-end, was created in 2024, went particularly viral on X in late 2025, and inspired use across Instagram, TikTok, and countless other platforms. And then in August 2025, something unprecedented happened: Daz Productions sold the full intellectual property of the EmotiGuy character to the JOE Coin community, marking the first time a crypto project has acquired complete rights to a meme of this vintage and scale. That's what [$JOE](https://x.com/search?q=%24JOE\&src=cashtag_click) became. # The Content Machine That Nobody Else Has Built [#the-content-machine-that-nobody-else-has-built] Most crypto projects treat content as marketing. JOE treats it as the product. Here's the difference. Marketing drives awareness of something else. Stop getting views, stop making it. Product-first compounds, each piece builds reach, embeds the character deeper, generates cultural artifacts that live past upload date. JOE runs an in-house content studio that creates and uploads 3D animations continuously to Giphy, Tenor, IG, and across X. This isn't posting static images and hoping for attention. This is building a content catalog. The team runs campaigns like a real brand, not a coin. Both Christmas and New Year mini-campaigns were extremely successful because they were fun and contextual to what was happening in the world. People were looking for fresh and cool videos to share during the holidays, and they received JOE right into their DMs or saw his yellow face in one of the stories. The official IG page gained over 30M views and over 70k subscribers during that short period. Image The most famous pieces, Joe shaking his rear end, the typing GIF, were created by [@joes\_intern](https://x.com/@joes_intern) and sat mostly dormant. Then they erupted: the original post by [@GiFShitposting](https://x.com/@GiFShitposting) pulled 14.6 million views and 50,000 likes in nine days. The [@NoLiquidity77](https://x.com/@NoLiquidity77) typing GIF followed with 5 million views in 48 hours, used purely as an exploitable, no caption, just the character typing furiously, inviting thousands of users to write their own punchlines in the quote replies. None of this needed marketing or celebrities. The content existed. People found it, felt it, and sent it to someone they loved. That flywheel has not stopped. By January 2026, individual posts from secondary JOE accounts were clearing [1.8 million views](https://x.com/joeshitposts/status/2006150401091846455?s=20) in a single drop. A [3.5 million](https://x.com/joeshitposts/status/2010046804482789537?s=20) views post days later. A [6.9M](https://x.com/joeshitposts/status/2010421154964795702?s=20) views clip the day after that. Non-crypto accounts (meme aggregators, lifestyle creators, ordinary people) started picking them up without knowing or caring about the token. ```text Content creation model comparison: Classic meme (Pepe/Doge): Character → Coin launch → Community posts stagnant GIFs No studio. No iteration. Cultural peak: pre-coin. JOE model: Character (2005) → IP acquisition (2025) → In-house studio → Weekly original 3D content → GIF platform seeding → Organic virality → Character grows → Loop repeats ``` [The official Joe Giphy account](https://giphy.com/thejoecoin) is about to pass 300 million views. Another [GIF](https://giphy.com/gifs/hi-emoji-xdd-NHglY9vAmvM2GEsblP) on that platform generated over 378M views. [Joe's Intern Tenor account](https://tenor.com/users/joes_intern) just crossed 200M views, and his [IG account](https://www.instagram.com/meza3d) casually gets 500k-20M views per post. [Joe's Tiktok account](https://www.tiktok.com/@joecoinofficial) pocketed around 9M views. The [Joe Instagram account](https://www.instagram.com/joecoineth) reached 189,000 followers and over 234 million views before a compliance review caused a temporary access disruption. The team has over 300,000 followers across all official accounts combined. Not to mention, JOE is widely used across top Twitch channel chats and has multiple GIFs featured in TikToks 'trending' category for the last few months, which is something that even the biggest brands with unlimited budgets weren't able to achieve thus far. Image Nobody in this sector is doing this. Pengu has a working GIF system, that's the only other project with anything close to a proper animated content layer. Every other memecoin posts static images and hopes for attention. JOE builds a content catalog. ## The Flywheel of Free Cult Labor [#the-flywheel-of-free-cult-labor] The unstoppable part? Thousands of accounts, crypto and normie alike, share JOE memes for free. That's free cult labor, exactly what Murad talks about. Image Even if the core team stopped creating content tomorrow, there are already thousands of accounts posting Joe memes as we speak. The team keeps momentum going and accelerates creative output, but the engine doesn't depend on them alone. Image This is the flywheel: every breakthrough moment compounds and generates a new set of fans and strengthens the existing fanbase. 2023-2024 had a few moments a year. End of 2025-2026 has at least one breakthrough moment a month. The attention is going parabolic. This strategy has produced outstanding results, leading to multiple Joe-related trending posts on X: * [https://x.com/i/trending/2010140816266953135](https://x.com/i/trending/2010140816266953135) * [https://x.com/i/trending/2010140816266953135](https://x.com/i/trending/2010140816266953135) # A New Category That Has No Name Yet [#a-new-category-that-has-no-name-yet] Standard competitive analysis breaks down here. JOE isn't a memecoin competing with PEPE for betting flows. It isn't a brand competing with Pudgy Penguins for collector loyalty. It sits between those categories and above them, a character brand built on top of a meme that already has two decades of organic reach. That category doesn't exist in the current taxonomy. Classic memes (Doge, Pepe, Shib) derive their value from cultural inertia and betting cycles. Their characters are static. Their communities generate content but have no central direction, no IP ownership, no studio. They can go up enormously on the right catalyst, but they cannot compound value through new creative output. Image Brand-first crypto projects like Pengu derive their value from art direction, community building, and holder identity. They have strong aesthetics and coherent worlds. Pudgy Penguins had a massive Web2 fanbase from Instagram and their GIF empire before crypto, with families as their primary audience. Pengu owns their IP and will not affect JOE in any form. JOE has both. 20 years of cultural penetration. Full IP control, creative team, and content system designed to deepen that reach. It functions like a media property more than a memecoin, with token liquidity access. The comparison set outside crypto is more instructive: M\&M's without the chocolate, SpongeBob without Nickelodeon, the smiley face without the Unicode Consortium telling you how to display it. JOE is the yellow man who already lives in your phone keyboard. # Content Distribution Always Wins [#content-distribution-always-wins] Attention has become the most valuable resource online. Every company, creator, and project is competing for the same limited supply of human attention. Most fail because they focus on getting attention before having something worth paying attention to. The winners do it backwards. Build something great first, then figure out distribution. This is harder than it sounds because distribution, getting content seen by the right people at the right time, is usually the most expensive part of growth. Traditional brands solve this with dedicated distribution teams: users who create variations of content, manage multiple accounts across platforms, track what performs, and optimize constantly. It costs money, takes time, and requires sophisticated operations. JOE built something different by combining centralized content creation with decentralized distribution. The team runs an in-house studio producing original animations, GIFs, and videos consistently. This creates "pillar content", foundational pieces others can remix, adapt, share. When one resonates, it becomes a template spawning countless variations across the internet. Image This happens because the character already has 20 years of cultural momentum. People were already creating and sharing EmotiGuy content long before the token existed. The project didn't have to build an audience from scratch or create distribution networks, they inherited both. The distribution strategy works like this: the team ships AAA animations in high quantity. Their fans across multiple platforms decide which ones they like the most, pick them up, and adapt them to their audiences. Each successful piece reinforces the algorithm's preference for JOE content, and the cycle repeats with higher baseline attention each time. Image Why does this work? No constant paid promotion needed. The content drives itself. Folks want to share it. They create custom videos and trends because the character resonates and gets impressions, not because they got paid. This creates a self-reinforcing loop: better content → more organic sharing → more data on what works → even better content across any platform, any language, any social group, any subculture. # What the Distribution Numbers Actually Show [#what-the-distribution-numbers-actually-show] The reach data is not marketing material. It is the thesis. Between October 2025 and April 2026, accounts with no relationship to the project repeatedly used JOE content as the raw material for their own posts. A March 2026 video posted by [@\_Gottalovezik](https://x.com/@_Gottalovezik) [hit 10 million views](https://x.com/_Gottalovezik/status/2032473195765170659?s=20). A January 2026 post by [@miyarah](https://x.com/@miyarah) [cleared 6.86 million](https://x.com/miyarah_/status/2015898536806597080?s=20). A post by [@kirawontmiss](https://x.com/@kirawontmiss) [drew 3.13 million](https://x.com/kirawontmiss/status/2016182379514040567?s=20). [@rareblurs](https://x.com/@rareblurs) account [crossed 3.1 million](https://x.com/rareblurs/status/2030034334858502220?s=20) with a JOE post. These aren't crypto accounts discovering the token. These are mainstream internet users who found the GIF or video, used it to express something, and drove tens of millions of impressions without a dollar of marketing spend behind them. The JOE Instagram page, during its active window, demonstrated that 1M+ views had become a floor on new posts. Not a ceiling, a minimum. A single post [hit 24 million](https://x.com/wellconnctd/status/2021395625108176922?s=20). Another [hit 10.2 million](https://x.com/Vitamul/status/2038547842193637383?s=20). A documented [12 consecutive weeks](https://x.com/CryptoKvon/status/2029579086700663211?s=20) of weekly viral content. Twelve consecutive weeks. The content is working in markets where JOE has no crypto presence at all. Chinese accounts, Brazilian meme pages, Filipino viral threads. The character is culturally borderless in a way that Doge, Pepe, and Pengu simply are not. # Market Position [#market-position] Market cap: $11.11M FDV: $11.11M FDV/market cap ratio: 1.0, fully diluted, no overhang CMC rank: #949 | CoinGecko rank: #1,166 24h volume: $118k Exchanges: Uniswap, Ourbit Chain: Ethereum Supply: 1,000,000,000, total and circulating are identical The fully diluted valuation = the market cap. There are no locked tokens, no cliff unlocks, no team vesting overhang waiting to compress the price. What you see is what exists. For a character with over 900 million GIF views, 234 million Instagram views, and full IP ownership of the most widely recognized emoji-adjacent meme on the internet, $11.11M is a disconnection that requires explanation. The explanation is that the ETH space has been dormant. Altcoin volume on Ethereum has been thin for months. But April 2026 is showing early signs of reversal, BTC dominance at 60%, ETH dominance recovering, and high-quality ETH launches beginning to draw capital back to the chain. JOE launched on Ethereum in October 2023 and has never had a proper ETH bull cycle to trade in. That window is opening. # Tokenomics [#tokenomics] Supply is fixed at 1 billion with no additional issuance, no minting, no emissions. The FDV/market cap ratio is 1:1. There are no unlock events, no institutional allocations vesting, no treasury cliffs on the horizon. This removes the most common source of structural sell pressure in early-stage tokens. For accumulation purposes, this is clean. You are buying the float, and the float is the whole supply. No hidden sellers waiting for their lockup to expire. **Liquidity Advantage** Despite the small market cap, JOE has a very thick liquidity pool to market cap ratio ($1.6M liquidity / $11.11M mcap). This means whales can size in with substantial positions without material slippage. # The Community and the Team [#the-community-and-the-team] [@Vitamul](https://x.com/@Vitamul) is the founder. The core creative contributors include [@joesintern](https://x.com/@joesintern) (primary animator), [@Adoniverse](https://x.com/@Adoniverse) (animator), [@joehub](https://x.com/@joehub), [@ninaartxx](https://x.com/@ninaartxx), [@Titiusmaximus](https://x.com/@Titiusmaximus), [@Dipbandit](https://x.com/@Dipbandit), [@dzech\_](https://x.com/@dzech_), neso, [@jcglza](https://x.com/@jcglza), and others. The team has been shipping continuously since the 2023 launch without a public funding round, without VC backing, and without any institutional support. What they built instead: a [Giphy catalog](https://giphy.com/thejoecoin) with hundreds of GIFs, a community [PFP generator](https://pfp.thejoecoin.com/), a [3D maker tool](https://joecoin.meme/joe.html), an [AR filter for TikTok](https://x.com/OGChia/status/1978177782103282083), a meme hub at [joecoin.meme](https://joecoin.meme/), and a content operation that produced weekly viral posts. The upcoming [merch drop](https://x.com/Vitamul/status/2037676586095255819?s=20) is the first step toward monetization outside the token. # External Signals [#external-signals] **Moonshot Listing.** JOE added to Moonshot, MoonPay's retail-facing token discovery surface, expanding access beyond DEX-native buyers. **Brand Engagements.** Multiple traditional brands have used JOE content organically, representing major consumer companies publicly engaging with the character: Chipotle, TeamSpeak, Opera GX, Expefutbol, Levelsio, San Mario Fan Account, etc. **Notable Figures and Influencers.** High-profile individuals have used JOE content without coordination. Some of the accounts are followed by Elon Musk, which is significant because Elon is the main driver behind all memes: * David Sacks * Patrick Casey * Traderpow * Autism Capital * Serf * Whotfismick **Platform Recognition.** * CoinMarketCap featured JOE indirectly. * Binance's intern account used JOE content * Know Your Meme, the canonical archive of internet culture, now has a full EmotiGuy entry following the virality expansion. **Media Coverage.** * AP News mentioned JOE. \[[source](https://apnews.com/press-release/marketersmedia/joe-coin-joe-makes-meme-coin-history-with-acquisition-of-iconic-20-year-old-emotiguy-ip-b26037657a132474d3bacad47b4b4575)] # Trade Setup [#trade-setup] ```text Current Phase: Reaccumulation, holders positioned since 2023 Price: $0.0508 Market Cap: $11.11M ATH: Not available in source data 24h: +2.1% | 7d: +11.5% Volume: $118k (-28.2% 24h) Sentiment: 31 (Fear) | 7d avg: 33.9 BTC Dominance: 60.02% ETH Dominance: 10.77% USDT Dominance: 7.30% Exchanges: Uniswap, Ourbit Holders: 9,479 ``` At a $11.11M market cap, JOE sits in the reaccumulation band where smart money typically positions ahead of any public narrative, well before the character's reach translates into on-chain price discovery. Some holders have been holding JOE since 2023. The Fear index at 39 reflects the broader macro environment, not any JOE-particular weakness. Markets that look grim in fear conditions historically produce the most durable entries for high-quality assets with strong fundamentals. Image The 7-day return of +11.5% against a 24-hour decline suggests consolidation rather than deterioration. Volume has pulled back, which in this setup is a quiet signal — size when it's quiet, take profits when it's loud. ## Macroeconomic / Meme Context [#macroeconomic--meme-context] JOE is a pure ETH-meme token. In strong meme seasons, coins like PEPE/DOGE blow through [$1B+](https://x.com/search?q=%241B%2B\&src=cashtag_click) caps from tiny bases, so [$1B+](https://x.com/search?q=%241B%2B\&src=cashtag_click) is possible for JOE — but it would require substantial liquidity inflows to the ETH chain, which are slowly coming. ## Historical Narrative Regimes [#historical-narrative-regimes] JOE has experienced several distinct narrative cycles since launching in October 2023: **Late 2023 Run.** The first wave of the Memecoin Supercycle Driven by strong liquidity inflows into crypto, ETH strength, and a high demand for new narratives. Pullback occurred due to abandonment by the original creator, and capital movement into Bonk coin and Solana chain. **April 2024 Run.** General ETH-meme momentum Driven by the broad ETH-meme rotation and meme-season flows. Topped when rotation cooled and capital rotated elsewhere. **September 2024.** SPX6900 spillover SPX6900 (SPX) grabbed attention on Ethereum, creating a meme-sector rally. Traders who rode SPX naturally rotated into other ETH memes, including JOE. Pullback came as the meme-sector narrative faded and flows rotated again. **July 2025.** IMF-driven rally IMF ([@IMFCrypto](https://x.com/@IMFCrypto)) was one of the key drivers for that particular rally. At some point, the IMF was the top holder of JOE, giving the price a perceived structural floor. This time JOE topped when the IMF announced diversification into other verticals and coins besides PEPE, MOG, JOE. Eventually, IMF became the primary reason for JOE to experience a cascade of liquidations on its platform, which occurred later in Sep 2025. ## Scenario Analysis [#scenario-analysis] ```text | Scenario | Assumptions | Target FDV | Multiple from Current | | -------- | -------------------------------------------------------------------------------------- | ----------- | --------------------- | | Bear | ETH cycle delays, Instagram never reinstated, content slows | $5M–$8M | ~0.5x–0.7x | | Base | ETH altcoin season develops, Instagram restored, 1–2 major brand collabs | $50M–$150M | ~4x–13x | | Bull | Cycle peak, major KOL or celebrity uses JOE, mainstream brand licensing deal(s) closed | $300M–$700M | ~27x–62x | ``` ## Catalysts [#catalysts] **Instagram Restoration.** The account at 189,000 followers with a documented floor of 1M+ views per post is a traffic channel currently closed due to a compliance review that has not yet been resolved. When it reopens, the content machine resumes at full capacity with an existing audience. **Merch Launch.** Establishes JOE as a physical brand — the first monetization layer outside the token. **ETH Altcoin and Memecoin Rotation.** Macro-driven but already showing early signals. Fresh ETH-native launches are drawing attention back to the chain. JOE, as one of the few Ethereum memecoins with real off-chain traction, is positioned to benefit disproportionately when rotation begins. **Traditional Brand Collaboration**. Multiple brands have already engaged with JOE content organically. A formal deal with any major consumer brand(s) would be the clearest signal that the IP acquisition is being monetized as intended. **Tier-1 Exchange Listing.** Currently trading only on Uniswap and Ourbit. Any major exchange listing opens the token to significantly wider buyer pools. ## Sentiment and Market Position [#sentiment-and-market-position] The Fear index at 33–39 on a 7-day average is almost perfectly calibrated as an entry condition. Retail is not paying attention. The accounts driving JOE's views ([@\_Gottalovezik](https://x.com/@_Gottalovezik), [@miyarah](https://x.com/@miyarah), meme aggregators across multiple languages, have no idea a token exists. That gap between cultural reach and market cap is where positions are built. JOE's current price action is consistent with the accumulation pattern: low volume, quiet sentiment, no narrative momentum on CT. These are the conditions that precede the largest moves. The thesis does not require believing something new will happen. It requires believing the market will eventually notice what has already happened. # Key Risks [#key-risks] **Instagram Suspension.** The account is currently inaccessible due to an unresolved policy violation. With 189,000 followers and over 234 million historical views, Instagram was a significant distribution engine. If the account is permanently banned rather than temporarily suspended, that is the loss of a high-reach surface in JOE's content stack. Probability: moderate. The team has not indicated that the issue is terminal, but timelines are unclear. **ETH Cycle Timing.** JOE is an Ethereum-native token. If ETH keeps underperforming relative to SOL or BTC, altcoin and memecoin rotation may not materialize or may arrive later than expected. The base case scenario requires an ETH cycle to fully play out. **Content Velocity Risk.** While there are thousands of accounts sharing JOE content, the team's involvement will keep the momentum and accelerate creative output. If key contributors step back or output slows, the viral velocity that drives organic reach from new AAA content could decline. The community distribution network provides resilience, but the in-house studio is the catalyst for breakthrough moments. **Memecoin Sector Risk.** Macro sentiment shifts can drain liquidity from the entire category regardless of project quality. Fear conditions at the sector level compress all valuations, including fundamentally strong projects. **Regulatory and Platform Risk.** Platform-level decisions (Instagram, X algorithm changes) can suppress distribution without warning. The Instagram suspension is a live example of how quickly a channel can go dark. Despite these risks, the core thesis is not dependent on any single catalyst executing perfectly. The IP is owned. The content catalog exists. The GIFs are already embedded in iMessage keyboards, Tenor queries, and messengers that millions of users use daily without any awareness of the token. That footprint is durable regardless of short-term platform disruptions. # Conclusion [#conclusion] JOE is a 20-year-old character who became the most-used emotional communication format on the internet, then became a crypto token, and then became the first crypto project to own full IP rights to a meme of that vintage and reach. That sequence doesn't happen twice. The timing case is clear: ETH dominance is recovering from a multi-month low, fresh ETH-native projects are drawing capital back to the chain, and JOE sits at $11M market cap with a GIF catalog above 900 million views and an Instagram audience of 189,000, waiting for the account to come back online. The market has not connected those two things yet. If the base case plays out (Instagram restoration, ETH rotation, one real brand deal) JOE trades into $50M–$150M territory on the strength of fundamentals that already exist, not promises of future development. If a major KOL or celebrity uses the character at peak liquidity conditions, the bull case range of $300M–$700M FDV becomes the floor conversation. Watch three things: Instagram account status, ETH altcoin dominance recovery, and the first major brand announcing a formal JOE collaboration. Any one of those confirms the thesis. All three confirm it loudly. The yellow man has been on your phone keyboard since before crypto existed. The market is just figuring that out. One thing is clear: it is his world, and you're living in it. * **X**: [@joecoin\_](https://x.com/joecoin_)\_ * **Website**: [https://www.thejoecoin.com/](https://www.thejoecoin.com/) * **Community**: [https://x.com/i/communities/1897643644644909410](https://x.com/i/communities/1897643644644909410) * **CA**: 0x76e222b07C53D28b89b0bAc18602810Fc22B49A8 This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # KeetaNetwork (/research/keeta) # KeetaNetwork [#keetanetwork] Image # The $5 Trillion Opportunity [#the-5-trillion-opportunity] The global financial system is running on software that was written before the personal computer existed. When SWIFT launched, moving money internationally meant telex machines, physical paper, and hand-carried documents. A payment from New York to Tokyo took weeks. That was acceptable five decades ago. Today, that same payment still takes five days. Think about that for a moment. In an era where you can send a message to Tokyo in 12 milliseconds, where you can video call someone in Singapore for free, where AI can generate code almost instantly — moving $1,000 across a border takes longer than it took to send a physical letter in the past. This is not a technology problem. The technology to move money immediately has existed for many years. Japan built a system that processes domestic transfers rapidly. The Federal Reserve created one as well. Sixty countries have real-time payment systems today. The problem is architectural. Every country developed its own payment rail. None of them connect to each other. To move money between them, you have to go through a chain of intermediary banks, each taking a fee, each adding a delay, each creating risk. The result is $5 trillion in capital trapped in bank accounts around the world, earning nothing, waiting for payments that should have arrived instantly. That's more than Japan's entire GDP. That's more than Apple's entire market cap. This is the single biggest inefficiency in the global economy. It's been hiding in plain sight for fifty years. And almost nobody is talking about it. Every international bank maintains reserves in foreign jurisdictions, waiting for settlement events. These are accounts holding funds that sit stagnant, earning nothing. Industry estimates put the total capital locked in this system at over $5 trillion. The problem: every domestic rail is a closed network. Moving money between them requires the correspondent banking chain. This system generates [$200B+](https://x.com/search?q=%24200B%2B\&src=cashtag_click) in annual fees, costs businesses hundreds of billions in working capital, and locks massive amounts of capital in dormant buffers. Wise built a network of local accounts in each jurisdiction. They net transactions internally to avoid correspondent banking. This works for their corridors. It doesn't scale globally, doesn't handle complex enterprise workflows, and doesn't address the institutional verification problem. Ripple spent a decade pitching XRP as a bridge currency. They got embroiled in an SEC lawsuit for five years. They still haven't displaced SWIFT for a single major bank's primary settlement flows. Every fintech that tried to fix cross-border payments faced the same choice. Operate outside the regulated system (fast to build, permanently limited). Or integrate with the regulated system (slow to build, potentially unlimited). Most chose the former. A few tried the latter and got stuck in regulatory quicksand. The answer was never another payment app. It was never another blockchain. The answer was a financial operating system. # The Three-Layer Bottleneck [#the-three-layer-bottleneck] **Layer 1: The Correspondent Banking Tax** The current cross-border payment model requires every bank with international clients to hold reserves in foreign jurisdictions. A London bank needs USD reserves in New York. A Singapore bank needs EUR reserves in Frankfurt. A Nairobi bank needs GBP reserves in London. This is the correspondent banking system. It works. The cost is high. The massive amount of trapped capital represents a huge opportunity cost. That capital could be deployed in loans, investments, or productive economic activity. Instead, it sits in accounts around the world, waiting for settlement events that never come on the timeline businesses need. Enterprise cross-border payments are worse in aggregate. Businesses lose hundreds of billions annually. Not just to FX spreads and wire fees. To the working capital locked in 2–5 day settlement windows. A company managing payables across twelve countries maintains funds in each jurisdiction to account for settlement timing. That idle capital has a real cost. The manual reconciliation required to audit cross-border transactions consumes the majority of payments operations headcount at most financial institutions. This isn't a technology problem. It's a structural design problem. **Layer 2: The Identity Dead End** Every institution in the current financial system maintains its own identity verification stack. Every new partnership requires independent vetting. Every new counterparty relationship starts from scratch. This happens regardless of how many prior relationships exist or how much has already been spent verifying the same people. The average global bank spends $115M per institution annually on KYC. Financial institutions collectively spend roughly $214 billion per year on financial crime controls. None of this spending creates a shared identity layer. It creates isolated silos that cannot talk to each other. These are proprietary systems built to satisfy regulators, not to interoperate. This creates an impossible structural constraint for blockchain-based payment infrastructure. The permissionless chains — Ethereum, Solana — cannot serve institutions with legal obligations to know their counterparties. The permissioned chains — Hyperledger Fabric — are closed by design. They cannot serve a retail user in Brazil and a central bank in Singapore on the same network. Every attempt to solve this treated identity verification as an application-layer problem. Each project builds its own KYC module. None of them interoperate. None of them travel with the user across counterparty relationships. The per-relationship onboarding cost stays high regardless of how many times the same user has already been verified elsewhere. **Layer 3: The Fragmentation Problem** The financial industry has spent two decades building blockchain systems that recreate the exact dysfunction they were supposed to solve. Closed networks. Incompatible rails. Liquidity that doesn't travel. JPMorgan's Onyx cannot settle with HSBC's blockchain system. Ripple's network doesn't interface natively with Stellar. The result is a new version of the same problem. Fragmented infrastructure benefits every intermediary, maintaining the connections between isolated systems. The RWA space has the same structural failure developing in real time. BlackRock's BUIDL runs on Ethereum. Franklin Templeton runs on Avalanche. WisdomTree on Stellar. When institutions want cross-system settlement — when a bank running on one system needs to settle with a counterparty running on another — they're back to the correspondent model. Now with added smart contract risk. The answer was never more fragmentation. It was always a shared layer that everyone builds on top of. # The Missing Layer [#the-missing-layer] What was missing was a network that could operate at both ends simultaneously. Fast enough for individual remittances. Regulated enough for institutional settlement. Open enough for developers to build on. Structured enough for AI agents to transact autonomously. No such network existed. The candidates: Ripple, built in 2012 with fewer than 35 validators and no native identity layer. Ethereum, permissionless by design, is structurally unable to add institutional verification without breaking what it is. And a graveyard of permissioned enterprise blockchains that solved the problem for one institution at a time, then stopped. One project has spent four years building for all three requirements simultaneously. That project is Keeta. The claim: 11,122,116 TPS, verified by Google Cloud and confirmed by Chainspect. Sub-400ms finality. Native identity certificates use the same X.509 cryptographic standard that secures every HTTPS connection on earth. Native tokenization without smart contracts. A Visa Direct integration reaching 190+ countries across 90+ rails. Multi-currency accounts in 25+ currencies connected to SWIFT, ACH, SEPA, Fedwire. Access to US Treasury bills and stocks directly on-chain. A pending bank acquisition to close the fiat loop entirely. Here is how it works. ## A Financial Stack, Not Another Blockchain [#a-financial-stack-not-another-blockchain] The most common mistake in evaluating Keeta is benchmarking it against other blockchains. Wrong category. The right comparison is the entire fragmented stack of payment infrastructure. SWIFT, ACH, SEPA, correspondent banking, card networks, FX desks. The question is whether Keeta can serve as the unified layer beneath all of it. The architecture makes four decisions that together are genuinely unusual. **The DAG: no queues, no mempools, no auctions** Traditional blockchains process transactions sequentially. A block fills, gets validated, gets added to the chain, and the next block starts filling. At peak demand, users bid up fees to skip the queue. The mempool becomes a fee auction. This is tolerable for speculative applications. For financial infrastructure — where a London bank needs to confirm settlement with a Singapore counterparty before market close — it's unacceptable. Keeta uses a Directed Acyclic Graph architecture. Each account maintains its own ordered chain within the broader network structure. Transactions are linked across multiple account chains simultaneously, enabling parallel processing across millions of accounts at once. There is no mempool. No queue. ```text Traditional blockchain: Keeta's DAG: [Block 1] → [Block 2] → [Block 3] [AcctA chain] ─┐ ↑ queue, fees, bidding [AcctB chain] ─┤→ Parallel validation ↑ mempool congestion [AcctC chain] ─┘ <400ms finality ↑ 12s+ finality (ETH) [AcctD chain] ─┘ No gas auction ``` The verified result: 11,122,116 TPS in a public stress test co-published by Google Cloud, confirmed by Chainspect. For context, Visa peaks at roughly 24,000 TPS. The entire global financial system — fragmented across dozens of incompatible rails — collectively processes around 11 million TPS. Keeta demonstrated that same throughput on a single, unified network. **The X.509 identity system: regulatory trust baked into the protocol** This is the architectural decision that separates Keeta from every other high-throughput L1. Keeta's certificate system uses X.509. This is the same cryptographic standard underlying TLS/SSL, the protocol securing every HTTPS connection on earth. Certificate Authorities (banks, KYC providers, government agencies) issue digitally signed credentials tied to a user's public key. These certificates can represent KYC status, AML clearance, jurisdictional permissions, or any regulated attribute. The breakthrough is selective disclosure. A user's certificate profile can prove defined attributes to designated counterparties without exposing the underlying data to the public ledger. A London bank can confirm a counterparty wallet is KYC-verified and jurisdictionally cleared without ever seeing the account holder's name. The commitment scheme uses cryptographic hash functions and salts that make this mathematically verifiable. Not a trust assertion. A checkable proof. It works like this in practice. The issuer encrypts the attribute (say, a full name) with a random salt using the subject's public key, then creates a cryptographic commitment. This is a hash tied to the account, the attribute value, and the salt. The hash goes into the certificate. The actual value stays private. When a third party needs to verify, the user generates a proof from the decrypted value and salt. The third party recomputes the hash, compares it to the certificate, and verifies independently. No intermediary required. No raw data exposed. For institutions, this is fundamental. They can operate on Keeta without violating their own regulatory obligations. They can enforce identity verification at the protocol level rather than building it as a custom application layer. They can transact with counterparties whose certificates have been issued by trusted authorities without repeating verification for every new relationship. Every competing L1 either requires institutions to build identity verification as an application layer or cannot serve regulated financial institutions at all. Keeta is the only network that has native certificate infrastructure at the protocol level. **The rules engine: regulatory rules travel with the asset** Every token created on Keeta carries programmable rules enforced automatically by the network. Geographic transfer restrictions. Time locks. Spending category limits. Multi-party approval requirements above threshold. And critically — as announced in the March 17 Discord call — the ability to restrict send and receive to accounts holding designated certificate types, not just standard KYC status. This means an asset with unique policy requirements can enforce those rules on both sides of every transaction, automatically, at the network level. No custom contract code. No audit surface. The rules travel with the asset. These are native network primitives. There is no gas cost for rule execution, no exploit surface in custom contract code, no need to maintain separate enforcement applications. A tokenized US Treasury bill that cannot be sold to retail investors in non-accredited jurisdictions enforces that restriction at the token level. Permanently, without human intervention. **Post-quantum architecture** Quantum computers threaten the cryptographic foundations of every blockchain in existence today. Shor's algorithm, when implemented on sufficiently powerful quantum hardware, can break the elliptic curve cryptography that secures Bitcoin, Ethereum, and essentially all existing cryptocurrencies. This isn't a distant theoretical concern. Major financial institutions are already planning ten-year infrastructure horizons, and quantum computing development is progressing faster than expected. Most blockchains have a hard problem. They built their security assumptions directly into the protocol level. Ethereum's addresses are derived from ECDSA public keys. Bitcoin's entire security model depends on elliptic curve signatures. When quantum computers become capable of breaking these algorithms, these networks face a binary choice: hard fork with massive disruption, or become vulnerable to attack. Keeta's architecture solves this differently. The network is cryptographically agnostic at the protocol level. Currently, Keeta supports ECDSA and ED25519 for key generation and signing. But the architecture allows for post-quantum algorithms to be introduced at the key-pair level without any protocol changes. This means an institution could generate quantum-resistant keys using algorithms like CRYSTALS-Kyber or Falcon. Those keys would work on the network immediately. Existing accounts could migrate gradually. New accounts could use quantum-resistant algorithms from day one. The network doesn't need to know or care what cryptographic algorithm secures each key pair. For institutional adoption, this matters enormously. A central bank considering CBDC deployment on blockchain cannot choose a network that might require a disruptive hard fork in five years. They need infrastructure that can evolve as cryptographic standards evolve without breaking the system. Keeta's design makes this possible. **The financial stack taking shape** What makes April 2026 different from a year ago is that Keeta has stopped being a blockchain with payments ambitions and started becoming a financial stack. ```text The financial stack: [Individuals] ─────────┐ [Institutions] ─────────┤→ [Keeta Network] → [SWIFT / ACH / SEPA / Fedwire] [AI Agents] ────────────┤ ↓ ↓ │ [Multi-currency] [Visa Direct] │ [T-bills / Stocks] [200+ countries] │ [FX conversion] [Card rails] └→ [Named USD accounts] → [US banking system] ``` **Full ACH and wire functionality with named USD accounts.** Most blockchain accounts require memo codes or reference numbers to route transfers correctly. Keeta's named USD accounts remove that entirely. Transfers route directly to a user or entity based solely on account details. Standard banking behavior. The addition of ACH debit (pull payments) enables authorized third parties to initiate transactions from a user's account, supporting bill payments, subscriptions, recurring charges, and merchant-initiated transactions. Without this, accounts can only push money out. This addition means an account on Keeta can function exactly like a US bank account. For both individuals and institutions. **Multi-currency global accounts.** A single wallet holding balances in 25+ currencies simultaneously, fully backed 1:1 with reserves held at regulated banking partners. Starting with USD, CAD, AED, GBP, EUR, HKD, JPY, MXN, and CNY — with rapid expansion to 26+ major currencies. SWIFT inbound and outbound transfers, FX conversion between supported currencies, local rail deposits for USD (with CAD, EUR, AED, AUD, BRL, and GBP following). No need to maintain separate accounts across jurisdictions. No human is required to open a bank account in every country. These accounts are designed to support both humans and AI agents as first-class participants. Across all non-sanctioned jurisdictions on earth. **Visa Direct integration.** Keeta is the first and only blockchain on Visa's Global Registry of Service Providers. This designation required a full on-site QSA audit and PCI DSS Level 1 certification, the highest payment security standard in existence. The practical result: payment delivery to 200+ countries, nearly instant card-based payouts, and the ability to send from a Keeta account directly to a recipient's debit card without requiring bank account and routing details. Deposits and withdrawals are available immediately when funding a wallet or sending money back to a card. The integration covers payroll payouts, remittances, P2P payments, commerce payments, and crypto on/off ramp. All through a single integration pathway pre-certified at the protocol level. **Access to US Treasury bills and stocks on-chain.** This one is underpriced in every analysis. Direct access to T-bills and equities. Fully owned in named accounts, not derivatives, not wrapped tokens, not ETF exposure. Via Keeta infrastructure. The idle capital problem is enormous. Banks, institutions, and individuals holding fiat balances on a payment network currently earn nothing on those balances. T-bill yields represent the risk-free rate. The ability to put dormant liquidity to work inside the same network where payments settle — without switching platforms — is a structural advantage no other payment-focused blockchain offers. The only comparable project is Ondo Finance, trading above $1B market cap and focused solely on this. Keeta treats it as one feature in a much larger financial stack. One integration. Every rail. Every currency. Every counterparty. As Keeta put it in their launch announcement: this is not something you assemble by stitching together six vendors. # Production Evidence [#production-evidence] Before the public blockchain pivot, Keeta operated as a permissioned network with KeetaPay, a Venmo-like payment application in closed beta. The sales team approached banks and financial institutions individually. According to the team, banks piloted their technology in 50 regions. Their PCI-DSS Level 1 production system served as the authoritative record-keeping system for account balances at partner banks in 50 regions. This is not hypothetical. Keeta replaced not only the settlement layer but also the banks' internal ledger. [Company records from Zawya](https://www.zawya.com/company/5083146362/keeta) (London Stock Exchange Group's MENA Company Data database) reveal a partnership with Bank of America for something called the "Money Transfer Service" or BOTS. The business summary states: > "Keeta Inc is a United States-based company, which is engaged in providing financial services. The Company provides banking services and payment services to individuals and small businesses. It offers its services through two channels which includes the Keeta Pay with Debit Card and the Bank of America (USA) Money Transfer Service (BOTS). The BOTS is an electronic money transfer service that allows consumers to transfer funds from one bank account to another." The product was in an advanced stage, having established fiat partners in multiple regions. Community Financial Services Bank in the US. Currency Cloud in Europe and the UK. Banco Dondé in Mexico. These financial institutions provided the account balances and the integration to the local bank transfers. The debit card program is particularly notable. Keeta collaborated with Visa to create cards directly integrated with Keeta's technology, allowing funds to move straight from Keeta accounts to merchants. A physical Visa debit card powered by Keeta has been [demonstrated publicly](https://www.youtube.com/shorts/ShsNgCPXrEI). Ty Schenk's communications have hinted at Keeta's technology potentially serving as a ledger for Visa itself. This would be an integration far deeper than typical crypto card offerings. The company records show Keeta subsidiaries for local payment integrations. These partnerships aren't active anymore because of Keeta's shift towards network-wide stablecoins. A new stablecoin provider is expected to be revealed in the coming months and KeetaPay will likely make a comeback in Q4. This time without the in-house regulatory burden. This is the production evidence that separates Keeta from every other L1 thesis. They've already done the hard work of institutional integration. The public blockchain is a scale play on top of proven technology. # The Competitive Advantage [#the-competitive-advantage] The most common objection: Ripple has a decade of bank relationships. Ethereum has the most developer activity. Solana has the throughput narrative. What does Keeta have that these don't? Three things. **The only blockchain on Visa's Global Registry of Service Providers** This detail has been buried in community posts and hasn't reached mainstream research coverage. Keeta is the first and only blockchain ever listed on Visa's Global Registry of Service Providers. This required a full on-site QSA audit and PCI DSS Level 1 certification. The same standard Visa requires of every major payment processor globally. The implication: any Visa-connected bank or merchant on earth can integrate with Keeta without running their own independent security assessment. The integration pathway that normally requires months of custom vetting has been cleared at the protocol level. Keeta already checks every major box from Visa's own stablecoin whitepaper. Native KYC/AML, Travel Rule support, ISO 20022 messaging, Visa Direct rails. Every other blockchain attempting to serve as payment infrastructure would need to undergo this same rigorous process. Keeta has already completed it. **Identity as a network effect, not a feature** Keeta's X.509 certificate system makes identity portable. A certificate issued by a regulated KYC provider on Keeta follows the user across every interaction on the network. Once verified, the user is verified. For every counterparty, every transaction, every jurisdiction where the certificate grants clearance. No repeat KYC. No new account application. This creates a compounding dynamic. The more users and institutions hold Keeta certificates, the more useful the certificate system becomes for every new participant. An institution joining the network inherits identity relationships with everyone already on it. The per-interaction onboarding cost approaches zero as the network grows. This is the opposite of the current correspondent banking model, where every new relationship requires an independent setup. Image The March 2026 certificate update adds another layer. Individual tokens can now be restricted to accounts holding particular certificate types. An institution issuing a regulated asset can define exactly which certificate profiles are permitted to hold, send, or receive that asset. This makes Keeta's identity machinery directly relevant to every tokenized security, regulated fund, and jurisdictionally restricted instrument that comes on-chain. **The zero-liquidity model for bank settlement** Keeta's architecture enables something called the Zero-Liquidity Model for institutional settlement. Banks that tokenize their currencies on Keeta can settle with each other in real time without pre-positioning cash reserves in foreign accounts. The current model requires every bank with international clients to maintain cash buffers in foreign jurisdictions. Idle capital sits in accounts around the world, waiting for settlement events. Keeta's model eliminates this. Citibank transfers tokenized USD to CFSB. CFSB nets the position. Physical settlement happens via local rails only when banks mutually agree. This minimizes the frequency and cost of actual settlement. The more banks on the network, the more netting opportunities, the lower the real-world settlement cost for everyone. **What competitors cannot replicate** XRP launched in 2012. At the time, modern cryptographic identity didn't exist as a product primitive, tokenization wasn't an institutional demand, and Google Cloud-grade infrastructure wasn't available as a substrate. The result: fewer than 35 validators, many operated by Ripple Labs itself. No sophisticated programmable contract capabilities. Delphi Digital noted in October 2025 that Keeta "leapfrogged a decade's worth of efforts on many technical fronts" versus Ripple. This happened because Keeta wasn't constrained by 2012 architectural decisions. Ethereum cannot add native KYC without abandoning its core identity as a permissionless network. This is a tradeoff its community would not accept. Its identity logic lives outside the protocol, incompatible across implementations, exploitable at the application layer. Solana has no certificate system. Adding one requires significant architectural work. It would require backward compatibility with an existing network built on the assumption of permissionless access. Hyperledger Fabric is permissioned by design. It can serve a single institution or a closed consortium. It cannot serve a retail user in Brazil and a central bank in Singapore on the same network simultaneously. Keeta was built from scratch for both. Open access, institutional-grade verification, global scale. That combination has no direct competitor in production today. # Market Opportunity [#market-opportunity] Keeta's opportunity has three distinct segments that don't require each other to be correct. **Cross-border payments: the core** Global cross-border payment volume reached approximately $1 quadrillion in 2024. The [McKinsey Global Payments Report](https://www.mckinsey.com/industries/financial-services/our-insights/global-payments-report) sizes the cross-border payments revenue pool at [$200B+](https://x.com/search?q=%24200B%2B\&src=cashtag_click) annually, growing at roughly 8% per year. Remittances alone — $905B in 2024 — generate roughly $59B in fees at current average rates. A network that compresses those costs from 6.5% to 0.5% at scale generates real economics from pure fee displacement. For context: Wise processes roughly $14B monthly in cross-border volume and trades above $10B market cap. Keeta's architecture is categorically superior on throughput, settlement speed, and regulatory coverage. If it executes at similar volumes, the current $94M market cap is a rounding error. **RWA tokenization: the institutional tailwind** RWA tokenization (excluding stablecoins) reached $15.2B by end of 2024. With stablecoins included, . BlackRock's BUIDL fund, Franklin Templeton on Avalanche, DAMAC tokenizing $1B in UAE real estate. These are production deployments by institutions with multi-trillion dollar balance sheets. The 10-year projection across research houses converges around [$30T+](https://x.com/search?q=%2430T%2B\&src=cashtag_click). Keeta's compliance architecture — native KYC, programmable token rules, certificate-based identity — is directly required for regulated asset tokenization. Tokenized securities need issuer-level controls. Tokenized real estate needs jurisdictional restrictions. Tokenized credit needs a verified identity for lending. These are native primitives on Keeta, not add-ons. The on-chain T-bill and stock access creates an additional wedge into this market. Direct ownership of US Treasury instruments. Not synthetic exposure, not fund tokens, actual named-account ownership. On the same network where settlement happens. Ondo Finance, the closest comparable project in the on-chain T-bill space, trades above $1B market cap with a narrower product scope than Keeta's full financial stack. **Agentic payments: what most are missing** AI agents are becoming first-class financial participants. Not a 2030 forecast. An April 2026 reality. Visa just announced "Intelligent Commerce Connect," enabling AI agents to make purchases across card networks. Keeta's Visa Direct integration and the bio update to "The most advanced way to move money. For humans and AI" are not coincidental. An agent managing procurement, running FX arbitrage, coordinating supply chain disbursements across twelve countries cannot operate through existing payment rails that require human authorization, impose daily limits, and close on weekends. Multi-currency accounts on Keeta require no human to open a bank account per jurisdiction. Identity certificates can be programmatically issued and verified. The network operates continuously, API-first. As stated explicitly in the product announcement: these accounts support both humans and AI agents as first-class participants. Keeta's founder is already building this in production: Industry forecasts put agentic commerce at trillions of dollars in transaction volume by 2030. The infrastructure layer that handles this is not built yet. Keeta is the closest thing to it currently running on mainnet. # Project Valuation [#project-valuation] Keeta is pre-revenue in the traditional sense. No disclosed protocol revenue as of April 2026. The valuation case rests on comparable market position, the institutional access infrastructure already in place, and scenario analysis. **Token structure** ```text | Metric | Value | | ---------------------- | -------------------- | | Price (April 16, 2026) | $0.1808 | | Market cap | $94.1M | | FDV | $180.8M | | Circulating / Total | 520.7M / 1B (52%) | | FDV/MC ratio | 1.92x | | ATH | $1.68 (June 9, 2025) | | Drawdown from ATH | -89.2% | | CMC Rank | #200 | ``` The FDV/MC ratio of 1.92x is low relative to most crypto infrastructure projects. 52% of the total supply is already circulating. Unlock overhang is manageable. **Comparable project analysis** Ripple (XRP) trades at [$130B+](https://x.com/search?q=%24130B%2B\&src=cashtag_click) market cap. Its core proposition is cross-border bank settlement. This is a narrower scope than Keeta's full financial stack, with inferior throughput, no native compliance layer, and no institutional certification equivalent to PCI DSS Level 1. Delphi Digital noted in October 2025 that Keeta "leapfrogged a decade's worth of efforts on many technical fronts" versus Ripple. Ondo Finance — the leading on-chain T-bill project — trades above $1B market cap with a product scope Keeta subsumes as a single feature. Wise — the most direct payments comparable — trades above $10B market cap on $14B monthly cross-border volume. Keeta's infrastructure can process that volume in seconds. At $94M market cap, Keeta is priced as though none of the institutional infrastructure it has already built has value. That's the dislocation. **Market share scenario** If Keeta captures 0.1% of the $200B annual cross-border payment revenue pool at a 20x multiple: $4B market cap. That's 42x from the current price. If Keeta captures 0.5% of the RWA tokenization market at $15.2B with a 2% fee take at 20x: $3B market cap. That's 32x from the current price. Neither scenario requires market leadership. They require being a real participant in markets that are already enormous and growing. # Token Economics [#token-economics] KTA is the governance token for a Delegated Proof of Stake network. Token holders vote for representatives who validate the network. The direct value accrual mechanism is the KUSD/AUSD yield → KTA buyback loop. KUSD, Keeta's KYC-compliant stablecoin built with Agora, generates yield from Treasury and money market positions. That yield is directed into KTA buybacks. As KUSD supply grows with institutional adoption, buyback flow scales linearly with it. The mechanism is live and grows with stablecoin supply. Agora's AUSD — which participates in the same yield mechanism — is managed by State Street and VanEck. State Street manages $4 trillion in assets. Their involvement in the underlying reserve management indicates institutional comfort with the Keeta infrastructure. The 400M KTA Strategic Reserves fund — formed by merging early investor and team allocations — was explicitly committed as a long-term strategic asset, not available for sale. The bank acquisition announced in January 2026 was funded by 35M KTA from strategic reserves. If regulatory approval is granted, Keeta would operate a licensed bank. This enables true 24/7/365 instant fiat movement worldwide, direct liquidity placement, and institutional onboarding without anchor dependencies. As explained in the March Discord call, acquiring a bank is the most expensive and tedious part of the build. It's necessary to remove third-party compliance overhead entirely. Target window: summer 2026, though the team was clear that the timeline could move in either direction. Both Keeta Token Genesis (KTG) and Keeta Inc. have explicitly committed to increasing, not decreasing, their token holdings. As of March 17, no further OTC deals will be entertained despite $5–10M in current interest. ## The Team [#the-team] **Ty Schenk — Founder and CEO** Schenk founded Keeta in 2022. His approach has been to build regulatory compliance directly into the protocol rather than as an application-layer add-on. This focus on protocol-level identity and compliance infrastructure — native X.509 certificates, programmable token rules, and selective disclosure — makes Keeta the only L1 designed to serve both institutions and individuals on the same network. Earlier in his career, he built a payment application on Nano, an experience that informed his understanding of what institutional adoption requires from blockchain infrastructure. **Roy Keene — Core Engineer** Formerly at Amazon and Nano's lead developer during its peak. The node was initially developed on AWS before moving to Google Cloud. This was a deliberate architectural decision driven by Google Cloud Spanner's unmatched scalability and consistency. Earlier 2023 tests reached 50 million TPS on a stripped-down version. The permission framework and compliance layers were added afterward. **Eric Schmidt — Former CEO and Executive Chairman of Google, early backer** Schmidt ran the company that built Google Spanner. This is the infrastructure powering Keeta's verified 11M TPS result. His involvement indicates both technical credibility and the institutional access that early-stage infrastructure companies need. This isn't just another investment for him. It's his first official blockchain investment and only his second involvement in the space after serving as an advisor to Chainlink (currently a top 15 crypto project). When his investment firm Steel Perlot encountered difficulties, Schmidt transferred his investment to his family office Hillspire LLC rather than abandoning the project. The ex-CEO of Google reportedly claimed this could be the largest project he's ever been involved in. # External Signals [#external-signals] **Google Cloud — Technical Co-publisher** Google co-published the [11M TPS stress test result](https://cloud.google.com/blog/topics/financial-services/how-blockchain-network-keeta-processes-11-million-financial-transactions-per-second-with-spanner) on their official financial services blog. This is not a marketing mention. Google does not co-publish technical case studies for projects they don't want its name associated with. **Agora — Institutional Stablecoin Partnership** State Street custody, VanEck reserves management, Paradigm-led Series A. KUSD/AUSD yield → KTA buyback mechanism live. **Kraken — Whale-Level On-Chain Positioning** Kraken's wallet is the #3 largest on-chain holder of KTA, with approximately 3.23% of supply. This is not a disclosed partnership. It's on-chain data. Kraken just received a Federal Reserve master account and has been actively building tokenized equity products. The positioning is notable. **Coinbase — Retail Distribution** KTA is tradeable directly within the Coinbase app via the Base DEX integration for US users. Native app integration for Coinbase's entire US retail user base. **Delphi Digital — Research Coverage** The October 2025 Delphi Digital report noted that Keeta "leapfrogged a decade's worth of efforts on many technical fronts" versus Ripple. Delphi rarely covers projects under $100M market cap. **Velocity — LATAM Neobank on Keeta** Velocity is live on Keeta mainnet, shipping a LATAM-focused neobank with native Base bridge integration, FX aggregation, and staking infrastructure. ## Trade Setup [#trade-setup] KTA launched in March 2025 via Base at $0.0068 (ATL), currently sitting at **$0.1808**. It ran to a $1.68 ATH on June 9, 2025. This was driven by the 11M TPS announcement and Eric Schmidt coverage. Textbook pre-mainnet premium. The narrative was fully priced before the product existed. Mainnet launched September 22, 2025. Token was at \~$1.11 at launch, dropped \~40% in the following three days. A classic sell-the-news event after months of buy-the-rumor momentum. By mid-October 2025, KTA had reached \~$0.27. From the $1.68 ATH to the October low: an 84% decline. ```text KTA Price History (Approximate) ──────────────────────────────────────────────────────── Mar 2025 Launch on Base at $0.0068 (ATL) May 2025 Breakout begins — $0.10 → $0.80 on TPS narrative Jun 2025 ATH: $1.68 — post 11M TPS announcement Jul–Sep Correction: $1.68 → $0.50 ahead of mainnet Sep 22 Mainnet launch at ~$1.11 → -40% in 3 days Oct 2025 $0.27 lows — post-mainnet distribution bottom Nov–Jan Sideways: $0.14–$0.21 range Apr 16 $0.1808 current ──────────────────────────────────────────────────────── ``` The pattern is clean. The pre-mainnet run priced the narrative entirely. The post-mainnet event distributed to early buyers. The current period is an accumulation coinciding with the product actually shipping. The 30-day decline in a product-positive period reflects macro pressure across crypto broadly and position cleanup from early buyers. Not fundamental deterioration. **Near-term catalysts (0–12 months)** * Bank acquisition regulatory approval. This is binary. Timeline targets summer 2026. Fundamentally changes institutional onboarding economics if approved. * SWIFT anchor integration. Enables direct bank-to-bank settlement without local rail dependencies. * BRL and GBP local rail deposit support. Expands remittance corridors significantly. * Card issuing product launch. Closes the last gap in the consumer payments flow. * First publicly named institutional settlement client. * The "big partner" announcement. Referenced in the March Discord call as the cornerstone enabling multiple other major announcements. Explicitly not Visa or Google. **Medium-term (1–3 years)** KUSD supply reaches . Meaningful KTA buyback flow begins. First CBDC pilot contract with a sovereign institution. Total settlement volume crossing [$10B+](https://x.com/search?q=%2410B%2B\&src=cashtag_click) annually. Named institutional clients building on top of the financial stack publicly. **Long-term (3+ years)** Keeta as the default settlement layer for mid-tier banks lacking full SWIFT relationships. Agent-native payment infrastructure for enterprise AI systems at scale. Top-3 L1 by protocol revenue. ## The Risks [#the-risks] **Production scale vs. stress test** The 11M TPS was demonstrated on a synthetic test with 30M accounts and Google Cloud infrastructure. Real-world adversarial conditions, varied transaction complexity, and decentralized node operators are a different test. Chainspect's live TPS readings have varied significantly from the stress test peak. Mainnet is live. Sustained high-throughput production performance under real load remains to be proven. **Bank acquisition execution risk** Acquiring a bank requires regulatory approval from multiple authorities. Timelines are measured in months to years. The process involves a large set of regulatory documents, compliance monitoring teams, and direct liquidity partner engagements. Approval is not guaranteed. The 35M KTA allocated from strategic reserves is a meaningful commitment. If the deal doesn't go through, the institutional onboarding narrative takes a credibility hit and the timeline for true 24/7 fiat movement extends significantly. **Partner and announcement timing** The March Discord call described a "blitz release" of 10–15 major items being held back for a coordinated launch. Several early-March deliverables were delayed by external events. The team is working against interdependencies. One smaller partner is the cornerstone, enabling multiple larger announcements. If that partner is delayed further, the entire announcement sequence pushes out. **Competitive response** Ripple has a decade of bank relationships and a completed SEC settlement. If Ripple accelerates programmability and native compliance features, it competes directly. This would be backed by significantly more institutional relationships and brand recognition. The technical gap is wide today. The question is how quickly it narrows with capital behind it. **Cross-chain bridge security** Keeta's cross-chain functionality introduces additional security surface area. Bridge exploits have been the single largest source of losses in crypto history. A significant exploit at this stage would be catastrophic for institutional trust. **Regulatory environment** The GENIUS Act provides US stablecoin clarity. The broader regulatory picture for blockchain-based payment infrastructure remains uncertain across key jurisdictions. A hostile regulatory action in a major market could constrain the institutional adoption timeline significantly. **Token concentration and OTC overhang** One recent OTC counterparty resold tokens and caused a market dump. The team has since closed the OTC channel entirely. This demonstrates that third-party holders of large positions can create selling pressure independent of the project's own stated intention to hold. The March incident was absorbed via a $100K buyback. It was small. A larger version of the same dynamic would be harder to absorb. The thesis survives these risks if production throughput scales to real-world demand over the next 12–18 months, at least one major financial institution goes live as a named settlement client, and the bank acquisition either closes or is replaced by an equivalent regulatory milestone. ## Conclusion [#conclusion] The right frame for Keeta isn't "which L1 will win." That's the wrong question. The right question: what is the infrastructure layer for global money movement? For the $1 quadrillion in annual cross-border flows, the [$30T+](https://x.com/search?q=%2430T%2B\&src=cashtag_click) in projected tokenized assets, and the trillions in agentic commerce that doesn't yet exist but is being built right now? That layer requires throughput at a global scale, compliance baked into the protocol, identity that travels with the user, rails that connect to every existing payment system simultaneously, and T-bill yields on idle capital. No current network was designed to meet all five requirements simultaneously. Keeta was. The institutional demand is no longer theoretical. The GENIUS Act provides US stablecoin clarity. Circle's IPO was 25x oversubscribed. BlackRock, State Street, and VanEck are operating production-grade tokenized products. Visa just launched an AI agent payment infrastructure and Keeta became the first blockchain on their Global Registry of Service Providers. Kraken — freshly holding a Federal Reserve master account — has taken the third-largest on-chain KTA position. These are not endorsements. They are signals from institutions allocating serious capital to this infrastructure category right now. At $94M market cap with a PCI DSS Level 1 certification, Visa Direct integration, full ACH/wire functionality, multi-currency accounts in 25+ currencies, on-chain T-bill access, and a bank acquisition in progress — the market is pricing Keeta like a speculative early-stage chain. The product is shipping. The institutional access points are live. If three to five institutional settlement clients are announced by the end of 2026 and the bank acquisition closes, the revenue base that follows supports a [$2B+](https://x.com/search?q=%242B%2B\&src=cashtag_click) market cap at sector multiples. More than 20x from current levels. Watch for these specifically. The first publicly named institutional settlement client, KUSD total supply trajectory, the bank acquisition regulatory update, the unnamed cornerstone partner announcement from the March call, and whether the blitz release delivers in Q2. If the infrastructure does what it claims, the settlement architecture isn't a roadmap item anymore. It's already running. * **X:** [@KeetaNetwork](https://x.com/KeetaNetwork) * **Website:** [https://keeta.com](https://keeta.com/) * **Community:** [https://discord.gg/keeta](https://discord.gg/keeta) * **CA:** 0xc0634090F2Fe6c6d75e61Be2b949464aBB498973 (Base) This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # KnoxNet (/research/knoxnet) # KnoxNet [#knoxnet] Image ## The Quiet War Against Your Money [#the-quiet-war-against-your-money] You don't see it happening. But every time you swipe a card, send a crypto transaction, or pay through an app, something else is recorded too. Not just the transaction contents. The transaction metadata. The time. The location. The network path. The routing information. Modern financial systems assume one thing: **you're always connected.** Banks, cards, even crypto — everything routes through a network, gets externally validated, and settles on a shared global state. No internet, no transaction. That assumption is so deeply embedded that we stopped questioning it. But assumptions get you killed. ## The Problem Nobody Is Talking About [#the-problem-nobody-is-talking-about] Physical cash was perfect. When you hand someone a bill, no network logs the transaction, no timestamp is created, no infrastructure routes the transfer. Privacy is a default property of the system — not a feature bolted on afterward. Digital payments inverted this model. Every transaction now requires a network, a broadcast, a record. The internet became a mandatory infrastructure for value transfer, and with it came a permanent ledger of every payment ever made. Banks know. Blockchains know. Infrastructure providers know. The assumption was so deeply embedded in how financial systems were designed that nobody stopped to ask whether it was necessary. Privacy-focused blockchains tried to solve this — and partially succeeded. Monero conceals amounts and participants. Zcash applies zero-knowledge proofs to hide transaction content. These are genuine cryptographic achievements. But they share the same architectural foundation as every chain they improved upon: global broadcast, immediate consensus, constant connectivity. The encryption hides what happened. The network still knows something happened. This is the ceiling they've all hit. Cryptography protects data confidentiality within environments that are inherently observable. Every Monero transaction still requires internet access. Every Zcash transfer still touches globally visible network infrastructure. Every zero-knowledge proof still propagates across a public broadcast channel. You can hide the contents of a message. You cannot hide that you sent one. ``` PRIVACY LEVELS: Cash: 100% private (no record) Privacy Coins: 50% private (content hidden, transfer visible) KnoxNet: 100% private (no transfer, no record) ``` The failure of alternatives runs deeper than just metadata leakage. Every always-online privacy protocol is fundamentally vulnerable to the same class of attack: network-level surveillance. Transaction timing, frequency, and routing behavior are observable regardless of what's encrypted inside the transaction itself. In high-stakes environments — censorship resistance, enterprise privacy, infrastructure-light economies — this is not a theoretical limitation. It's an operational failure. The gap is structural, not incremental. No existing blockchain was designed to execute value transfers without connectivity as a core architectural primitive. Not as a fallback mode, not as an edge case — as the default. The first system to solve this doesn't improve on existing privacy coins. It creates a new category. ## The Context That Makes This Urgent [#the-context-that-makes-this-urgent] Internet outages during conflicts are weaponized — cutting off entire populations from their money. Developing regions with unreliable or expensive connectivity are locked out of digital commerce entirely. Enterprise supply chains need privacy guarantees that don't depend on always-on surveillance infrastructure. Meanwhile, new AMLA frameworks and the regulatory architecture being built right now will make financial privacy opt-out by design, not the default. The window to establish offline-native infrastructure before that demand becomes acute is measured in months. Every existing solution assumes connectivity, even the private ones. **No blockchain natively supports offline execution as a core design principle.** That is the gap KnoxNet steps into. ## Offline-Native by Design [#offline-native-by-design] KnoxNet is the first Layer 1 blockchain built for offline execution and encrypted online settlement — a dual-domain architecture that fundamentally separates where value transfers happen from where they're recorded. Here's how the mechanism works. A user escrows $KNX on the Layer 1 ledger and receives cryptographic notes — portable, self-contained value units that carry their own lineage, ownership history, and transfer record. These notes exist entirely on the device. They move over Bluetooth, QR codes, Wi-Fi Direct, or local mesh networks. When two devices are in proximity, a full cryptographic handshake occurs: the receiver validates the note's complete history, checks for contradictions locally, and accepts or rejects before the transfer completes. No internet required. No global state consulted. ```text Dual-Domain Architecture: [OFFLINE DOMAIN] [ONLINE DOMAIN] Device A ──── local handshake ────► Device B ──► Encrypted Settlement [escrow] (BT/QR/mesh) [receives note] (HE reconciliation) │ │ │ No network No network Global correctness No broadcast No broadcast enforced on-chain No timestamp No timestamp without revealing No surveillance No surveillance amounts or parties ``` Execution privacy lives in the offline domain. Settlement correctness lives in the online domain. Neither domain compromises the other. Settlement happens later. When a device reconnects, encrypted deltas are submitted to the Layer 1 for reconciliation. This is where homomorphic encryption becomes critical. The ledger validates supply invariants — value conservation, issuance limits, settlement correctness — by performing arithmetic directly on ciphertexts. It confirms the math is right without learning what the numbers are. No transaction amounts. No participant balances. No detailed accounting structures. Correctness is enforced through encryption that the verifier cannot read. This is a genuine 0→1 architectural breakthrough. Not a better zero-knowledge proof. Not a more efficient ring signature. A fundamentally different model where the internet is an optional infrastructure rather than a prerequisite. No existing Layer 1 treats disconnected execution as a core primitive — the design space simply doesn't exist in always-online systems because connectivity was never questioned as a requirement. The double-spend problem in offline systems is bounded, not eliminated. KnoxNet accepts this honestly and handles it directly: the maximum value that can be misused offline equals the [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) escrowed on the ledger. Double-spends are detectable during reconciliation, with escrow slashed as a penalty. This transforms the worst-case outcome from catastrophic system failure into a bounded, punishable event — an economic enforcement layer replacing the impossibility of offline global uniqueness. The result: a complete privacy model across three layers simultaneously. Execution privacy from offline operation. Settlement privacy from homomorphic encryption. Network privacy from the absence of broadcast. No existing privacy coin addresses all three. Most address one. ## The Moat Built Into the Architecture [#the-moat-built-into-the-architecture] KnoxNet doesn't have a first-mover advantage because it moved first. It has a first-mover advantage because what it built cannot be replicated by layering improvements onto existing architectures. Monero and Zcash are always-online systems at their core. To add offline-native execution, they would need to redesign their consensus models, their settlement layers, their note structures, and their network assumptions from scratch. That's not a protocol upgrade — that's a rebuild. Privacy coins that have spent years optimizing their broadcast-based architectures are structurally incapable of the architectural separation KnoxNet was designed around from day one. The moat is the architecture itself. What makes the competitive position more defensible is where the moat compounds. Offline payment networks build local value through physical proximity — the more devices running KnoxNet in a region, the more useful the network becomes for that region, independent of global chain activity. This creates network effects that don't require internet connectivity to reinforce. Local mesh density drives local utility. Local utility drives local adoption. Local adoption drives more devices. This loop has no analogue in always-online privacy coins. Enterprise demand adds a second reinforcing vector. Supply chain payments, cross-border institutional transfers, and sensitive financial transactions all share a common requirement: reduced network-level visibility. Current blockchain solutions force enterprises into surveillance models — every transaction visible to infrastructure, intermediaries, and network operators. KnoxNet's encrypted settlement layer offers correctness guarantees without reintroducing transparency. That's a meaningfully different product than anything Monero or Zcash currently offers enterprise buyers. The working demo is evidence that the moat is operational, not theoretical. KnoxNet has executed offline note transfers between fully air-gapped devices — both in airplane mode, no internet, no fallback — with complete lineage verification, handshake validation, and local double-spend detection. Working code in a pre-mainnet project with novel cryptographic claims is a significant signal. It means the architecture isn't whitepaper speculation. It's implemented. ## Market Opportunity [#market-opportunity] The privacy category has grown steadily as surveillance awareness has increased globally — and it's about to get a significant legislative catalyst. Europe's Anti-Money Laundering Authority framework kicks in late 2026 as the most aggressive financial surveillance regime in years. The Digital Euro — **€1.3B already in development** — follows in 2029. The combined regulatory architecture introduces €3,000 cash holding limits, fully traceable transaction records, real-time behavioral monitoring, and programmable money with the capacity to expire, restrict purchases, or freeze accounts programmatically. Financial privacy, under this framework, becomes opt-out-by-design rather than default. This isn't a theoretical threat to financial autonomy. It's a legislative timeline. And it directly expands the addressable market for structural privacy solutions. KnoxNet's offline architecture addresses this threat at the layer that regulators cannot reach. Transactions that happen device-to-device over Bluetooth or mesh don't pass through monitored infrastructure. Cryptographic notes that carry their own state don't touch the real-time logging systems the Digital Euro framework is built to enable. Even always-online privacy coins remain vulnerable to network-level control: connectivity can be throttled, routing can be filtered, and broadcast can be monitored at the infrastructure layer. KnoxNet's internet-optional design removes that attack surface entirely. Image The addressable market expands further when offline-commerce economies are included. **4.1 billion people** live in regions with unreliable or unaffordable internet connectivity. Rural areas, developing countries, and infrastructure-light economies need payment systems that function without continuous access. Digital commerce is severely constrained where connectivity cannot be assumed, which describes most of the world by population. KnoxNet's mesh-native architecture is the only blockchain primitive that addresses this at the protocol level. Enterprise privacy rounds out the TAM. Supply chain payments, cross-border institutional transfers, and sensitive financial transactions require visibility controls that existing blockchains cannot offer. Current enterprise blockchain solutions force a trade-off between connectivity and privacy — KnoxNet's dual-domain model eliminates that trade-off. If even a small fraction of the **$115M average annual compliance spend per major financial institution** shifts toward privacy infrastructure, the revenue potential is significant. Taken together — privacy coin market, mesh-economy use cases, regulatory-driven demand, and enterprise adoption — the total addressable market spans hundreds of billions over the next decade. The timing is exact: Europe's regulatory clock is running, mainnet is approaching, and the architecture is differentiated. Two years from now, the window to enter before network effects establish will be closed. ## Project Valuation [#project-valuation] The nearest comparable for valuation purposes is Monero at the equivalent stage of development: functional architecture, working demos, pre-broad-adoption, category-defining technical differentiation. Monero's current $6.3B market cap was reached after years of network development and ecosystem growth. KnoxNet at **\~$28.4M FDV** represents approximately **0.45% of Monero's valuation**, with an architectural advantage Monero structurally cannot replicate. Applying a conservative 5% market share scenario against the privacy coin market alone ($14.8B) implies a [$500M-](https://x.com/search?q=%24500M-\&src=cashtag_click)**$1B market cap range** at comparable penetration. This scenario requires no enterprise adoption, no mesh-economy penetration, and no regulatory-driven demand growth. It requires only that KnoxNet captures a small fraction of the market it technically supersedes. The liquidity picture warrants attention. At \~$28.4M FDV with thin Uniswap depth, small clips can move price significantly — this amplifies upside during accumulation phases but creates severe downside risk during corrections. The token has traded as high as **$0.047 on April 11**, **2026** and had two 40-45% corrections. This is the standard post-launch distribution pattern for pre-mainnet assets at this stage. The architecture survives the price action. Current price implies the market is treating KnoxNet as speculative infrastructure at an early stage — which it is. The repricing event occurs at mainnet with functional offline execution, security audit results, and initial transaction volume. At that point, the project crosses from "whitepaper architecture with working demos" to "deployed Layer 1 with live network." The valuation gap between those two states in the privacy category has historically been substantial. ## How $KNX Captures Value [#how-knx-captures-value] [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) is the economic foundation of the offline network, not a governance token or speculative vehicle. Value accrual is structural and tied directly to network utilization. Every user who wants to generate offline spendable notes must first escrow [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) on the Layer 1 ledger. The total value of outstanding offline notes is strictly bounded by the amount of [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) escrowed. This creates baseline demand that scales linearly with network adoption — more users generating offline notes means more [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) locked in escrow. There is no workaround. The escrow requirement is the mechanism that bounds double-spend risk, which means it cannot be removed without breaking the security model. Double-spend penalties are also denominated in [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click). When a contradiction is detected during reconciliation, the associated escrowed [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) is slashed. As [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) price increases, the economic cost of misbehavior increases proportionally. Security and price appreciation are aligned rather than in tension. The supply dynamic creates a natural accumulation floor tied to network growth. As offline commerce scales, escrow demand scales. As escrow demand scales, the circulating supply contracts. This isn't a buyback mechanism or artificial supply restriction — it's the direct economic consequence of the architecture working as designed. KnoxNet's current architecture supports [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) as the sole native asset for escrow, settlement, and economic enforcement. ## The Team [#the-team] KnoxNet operates as an undoxxed project. No confirmed team identities have been publicly disclosed. This is simultaneously the project's privacy-consistent narrative and its primary risk. The "No Doxx with Knox" framing aligns with the product's ethos — a privacy chain run by an anonymous team is coherent in a way that a privacy chain run by a publicly known team with LinkedIn profiles is not. What exists as evidence of real engineering capability: a detailed whitepaper with complete cryptographic architecture, functional offline transfer demos between air-gapped devices, active development updates on X and Telegram, and SDK documentation that reflects real implementation depth. These are not whitepaper promises. They are shipped artifacts. The absence of institutional backing or public team disclosure remains the single largest risk in this thesis, addressed directly in the risk section below. ## External Signals [#external-signals] * [@TheCryptoChefX](https://x.com/@TheCryptoChefX) — "KnoxNet is building a Layer 1 blockchain that works offline. Offline is the actual default state of the network. KnoxNet's whole thesis is that real privacy starts by removing the internet from the transaction path entirely. If this tech delivers, the current mcap does not reflect it." — [Source](https://x.com/TheCryptoChefX/status/2039874922848067984). **Why this matters:** Correctly identifies the architectural thesis — not as a privacy improvement but as a category creation. Analyst accuracy on the mechanism suggests informed, not narrative-driven, positioning. * [@cryptoskullx](https://x.com/@cryptoskullx) — Described KnoxNet as "cash 2.0 — digital, private, borderless, and far harder to shut down" and called it "quietly one of the more interesting ideas being built right now on Ethereum from a privacy project POV." — [Source](https://x.com/cryptoskullx/status/2036142269829456215). **Why this matters:** Framing from an analyst with prior accurate early calls on privacy infrastructure adds signal weight to the architecture thesis. * [@Dvcryptzz](https://x.com/@Dvcryptzz) — Cited the working offline demo directly: "Successful offline transfers now occur between airplane-mode devices." — [Source](https://x.com/Dvcryptzz/status/2041959655459713532). **Why this matters:** Independently verified working code in pre-mainnet is a meaningful signal. On-chain activity converging with functional demo evidence. * [@DogeSpaceXX](https://x.com/@DogeSpaceXX) — "The team behind Knox is seriously strong. They've been building a privacy-focused chain designed to work without internet connectivity — something very few are even attempting." — [Source](https://x.com/DogeSpaceXX/status/2041262907070230618). **Why this matters:** Consistent with other KOL assessments on team capability, though team identity remains unconfirmed. **Community:** The project remains in an extremely early accumulation phase. The Telegram channel and X account ([@KnoxnetOfficial](https://x.com/@KnoxnetOfficial)) are active with regular development updates but follower numbers remain relatively small. Daily active addresses on-chain are not yet meaningfully tracked at this stage of deployment. These numbers are a signal, not a concern — at this market cap and development stage, the community is still composed of early researchers and private groups, not retail. These are most likely insiders and smart whales building positions ahead of the mainnet. **No institutional backing has been announced.** This is stated once here and once in the risk section. ## Trade Setup [#trade-setup] [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) launched March 18, 2026. Current price is **\~$0.0284** with an **FDV of \~$28.4M** and approximately **$563.87K in 24-hour trading volume** as of April 14, 2026. The recovery from post-launch lows to the April 11 ATH of $0.046, followed by the current 40% retracement, is consistent with early-participant distribution. The consolidation at current levels with ongoing volume suggests continued upside pressure from a small but thesis-driven cohort. **Catalysts — near term (0–12 months):** * **Team disclosure or credible institutional backing** — binary signal. Changes the risk profile of the entire thesis. * **Security audit from a recognized firm** — validates cryptographic implementation. Without this, the architecture claim cannot be independently verified. * **Mainnet launch with functional offline execution** — the thesis-confirming event. Working demos are evidence; mainnet is proof. * **Exchange listings beyond Uniswap** — increases liquidity depth and reduces volatility. * **SDK adoption by initial developer cohort** — first signal of network effects beyond the core protocol. * **Community growth above 10,000 holders** — indicates thesis reaching beyond the initial insider cohort. **Medium-term (1–3 years):** Operational offline payment activity in target regions. Enterprise pilots in supply chain or cross-border use cases. A developer ecosystem with diverse applications beyond native [$KNX](https://x.com/search?q=%24KNX\&src=cashtag_click) transfers. Daily active address growth as a measurable adoption signal. **Long-term (3+ years):** Mesh-native payment standard for infrastructure-light economies. Enterprise-grade privacy solution across institutional verticals. Market cap re-rating to reflect the actual protocol utility against the privacy market TAM. A sharp post-launch selloff following any major price spike prior to mainnet remains the most predictable near-term risk. It is the standard distribution pattern for pre-mainnet assets and should be treated as an entry opportunity, not a thesis invalidation. ## The Risks [#the-risks] **Anonymous Team on Complex L1 Claim** — The single largest risk in this thesis. Building a functional Layer 1 blockchain with novel homomorphic encryption and offline execution is a serious engineering challenge. An anonymous team cannot be held accountable in any conventional sense. If development stalls, the team disappears, or execution fails, there is no institutional backstop. Community bulls circulate "OG ETH team" claims without providing any verifiable evidence — treat this as narrative, not fact. The working demos provide partial mitigation, but partial is the operative word. Mainnet launch is the only real answer to this risk. **Homomorphic Encryption at Production Scale** — Theoretically sound. Unproven in production blockchain environments at meaningful transaction throughput. HE operations are computationally expensive compared to standard cryptographic primitives. Real-world performance under adversarial conditions, at scale, with high transaction volume, remains entirely unknown until mainnet. A vulnerability in the settlement logic or HE implementation would be catastrophic for a privacy protocol — this is precisely the use case where cryptographic failures are irreversible. **Post-Launch Sell Pressure** — Less than 30 days of trading history. The 40% pullback from the April 11 ATH of $0.046 to the current \~$0.028.4 reflects ongoing price discovery, not established fundamentals. The $28.4M FDV was achieved in a compressed timeframe with thin liquidity — this makes current price levels more fragile than comparable market caps in higher-liquidity environments. Additional distribution waves should be expected before the mainnet. **Community and Adoption Threshold Risk** — 3472 holders, 245 Telegram subscribers, and 1757 X followers as of April 14, 2026. Offline execution requires local device density to be practically useful. Network effects don't materialize unless adoption crosses a threshold — and the threshold is higher for local physical networks than for global digital ones. **Competitive Response from Incumbents** — Monero and Zcash cannot replicate offline-native execution without architectural rebuilds. But they don't need to. If KnoxNet's adoption is slow enough, incumbents can invest in adjacent improvements — better UX, exchange integration, regulatory positioning — that retain their user base without matching the technical innovation. The architecture is defensible; mindshare is not automatically so. **Regulatory Targeting** — A blockchain explicitly designed to enable untraceable, offline, censorship-resistant value transfer is precisely the kind of infrastructure regulators in Europe and the U.S. will scrutinize aggressively. The AMLA framework that creates demand for KnoxNet also creates the enforcement apparatus that could target it. This is a structural tension in the thesis that has no clean resolution — it's the same tension that has constrained Monero adoption in regulated markets. The asymmetric upside is real. So is the risk of total loss on a pre-mainnet anonymous project with unproven production cryptography and a nascent community. Position accordingly. ## Conclusion [#conclusion] Three things converge in KnoxNet that don't converge elsewhere in the privacy category: a genuine architectural breakthrough that existing protocols cannot replicate, a regulatory tailwind that's converting theoretical demand into urgent demand, and a market cap that prices it as a speculative position rather than a structural one. The timing is specific. New AMLA frameworks are launching late this year. The regulatory architecture that makes offline-native privacy a structural necessity rather than a preference is being built right now. The window to establish a network before that demand materializes is measured in months, not years. KnoxNet is the only blockchain positioned inside that window with working offline execution code. If mainnet delivers — functional offline transfers, security-audited homomorphic settlement, and initial network adoption — the repricing is straightforward. A 5% share of the existing privacy coin market implies $500M–$1B market cap range. Against the full TAM of privacy infrastructure, regulatory-driven demand, and mesh-economy penetration, the addressable ceiling is higher by an order of magnitude. Either scenario represents a significant multiple from \~$28.4M FDV. Watch for four signals that confirm or invalidate this thesis in sequence: team disclosure or credible institutional backing, security audit results from a recognized firm, mainnet launch with verifiable offline transaction volume, and developer adoption of the SDK beyond the core team. Each one reduces the risk profile materially. All four together mean the architecture is real, the team can execute, and the network is forming. The architecture doesn't need permission to work. It just needs to be live. * **X**: [@knoxnetofficial](https://x.com/knoxnetofficial) * **Website**: [https://knoxnet.io](https://t.co/845Zz5MdU9) * **Community**: [https://t.me/KnoxnetOfficial](https://t.co/G47g1SnBrM) * **CA**: 0xf19304e6bFE0A18D2a0171758aA433921F192897 This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Mantle (/research/mantle) # Mantle [#mantle] Image ## The Broken Settlement Infrastructure [#the-broken-settlement-infrastructure] Most people move money the same way they did in 1985. A wire from New York to Singapore takes 3 to 5 days, passes through multiple correspondent banks, and the sender often has no visibility into when or whether it arrives. This isn't friction that better mobile apps can solve. It's baked into the infrastructure itself. SWIFT was built for a world where batched, end-of-day settlement represented the technological frontier. Layering modern interfaces on top of a system built for 1970s batch processing doesn't change what's happening underneath — it just hides the waiting behind better-designed forms. The costs compound across the entire chain. Every correspondent bank takes a cut, typically a flat fee per transfer. Foreign exchange spreads widen at each conversion point. Compliance checks create additional settlement delay as documents bounce between departments. A professional trader can arbitrage price differentials across global markets in milliseconds — but moving the actual capital home snaps back to days. Keep capital fragmented across jurisdictions, or accept multi-day delays when consolidating. Neither is efficient. The problem extends beyond international transfers. ACH in the United States still settles next-day in many cases. Real-time rails exist but adoption is patchy — banks have to opt in, and many haven't. Large-value systems like Fedwire move money in real time but are reserved for banks. Individuals settle through the slower systems. We are left with a system optimized for internal bank structures instead of maximized capital utility — and the consequence is a tax on capital mobility across the entire financial system. ## The Fragmentation Trap [#the-fragmentation-trap] A money manager in Malaysia with capital split across a U.S. brokerage, a European bank account, and a crypto exchange has no unified view and no native way to move value between those systems without converting, bridging, waiting, and paying. Traditional finance doesn't solve this because it functions through isolated institutional frameworks. Crypto doesn't solve it either — it was built for traders who already know how to use terminals. At the asset level, capital is locked into non-composable forms. A U.S. Treasury bill held at a bank cannot be used as collateral on a DeFi lending protocol without first selling it, bridging the proceeds, and redeploying — each step introducing conversion costs, settlement delay, and counterparty exposure. The owner chooses between leaving it idle or paying the fragmentation tax to make it productive. Institutional capital lives in three incompatible worlds. Traditional finance holds the assets and the regulatory adherence but can't move them efficiently. DeFi holds programmability and composability but lacks institutional-grade custody standards. CeFi sits between them, adding friction and extracting fees at every conversion. A family office allocator who wants to use European bank deposits as DeFi collateral typically has no path that satisfies compliance departments on either side. The fragmentation adds up across jurisdictions. Swiss FINMA, Singaporean MAS, European MiCA — each operates under distinct custody and reporting rules. What works in one jurisdiction often requires restructuring in another. The result is parallel compliance frameworks for each geography, because no single structure covers the entire footprint. The cost isn't theoretical. It's the spread between what capital could earn deployed optimally and what it actually earns given these constraints. ## The Missing Fiat Front Door [#the-missing-fiat-front-door] Stablecoins cracked the problem open. USDT and USDC proved that dollars could move on-chain in seconds for cents. But everyday spending stayed broken. Converting to local fiat still requires brokers or exchanges — heavily regulated in most markets, outright banned in some. The user who wants to spend USDT at a Zurich restaurant still has to go through five steps that none of them were designed to tolerate. Stablecoins solved the transportation problem. Not the access problem. The gap isn't technical capability — it's user experience and regulatory access. Consider the journey from stablecoin to coffee. Option one: a crypto card that auto-converts to fiat at the point of sale, but with onboarding friction, KYC, and fees that often exceed normal card networks. Option two: sell on an exchange, withdraw to a bank account, wait 2 to 3 days. Option three: find a merchant who directly accepts stablecoin — rare outside crypto-native venues, and the merchant still faces the problem of converting to fiat to pay suppliers. Every option requires an intermediary. None provides the smooth experience users expect from modern financial services. The regulatory barrier compounds everything. In many jurisdictions, fiat-to-crypto on-ramps are restricted to licensed operators with strict capital requirements. The user who just wants to move money programmably faces compliance procedures designed to catch money laundering — legitimate and necessary, but keeping most potential users away entirely. The missing piece is a product that provides regulated financial services — accounts, cards, transfers — on top of programmable rails, without requiring users to interact with the rails themselves. The bank account that happens to settle on-chain. The debit card that happens to hold stablecoins. The fintech app that integrates DeFi yield invisibly underneath. No L2 has addressed this population with a credible product stack. Until now. ## From Bitcoin Rollup to Banking Layer [#from-bitcoin-rollup-to-banking-layer] Mantle functions as a settlement and liquidity backbone for a broader financial stack. Understanding why that matters requires understanding what "modular" actually delivers in practice. Traditional L2s handle execution, consensus, and data availability inside one architecture. When you upgrade one layer, you touch everything. When costs spike in one component, the whole system absorbs the hit. This architecture separates these concerns. In March 2025, Mantle became the first major L2 to fully integrate EigenDA, expanding its data availability infrastructure from 10 operators to over 200, each subject to slashing conditions and backed by staked economic security. The upgrade delivered dramatic performance improvements: network capacity expanded more than 200-fold while data throughput reached approximately 15 megabytes per second. Those aren't theoretical numbers — they're why Aave v4 launched on this network and not somewhere else. The ZK transition is complete. Following the Arsia upgrade on April 16, 2026, Mantle officially transitioned from a Validium to a ZK Rollup, leveraging Ethereum for Data Availability via blobs. This eliminates reliance on external DA layers and removes data withholding attack risks entirely. Mantle currently holds the third position in Total Value Locked across all rollups, having secured. By bringing in SuccinctLabs' SP1 validity proofs, the network has added ZK-based verification capabilities to its OP Stack foundation. Additional enhancements include fee-scalar controls for managing L1 data footprint precisely, full implementation of EIP-1559 standards, EIP-7706 operator fee structures. According to L2BEAT's evaluation system, Mantle now qualifies as a Stage 0 Rollup with a green DA risk rating, indicating that it fulfills all fundamental requirements for L1 data availability and state root posting. Withdrawal times have compressed from seven days to under one hour. That single change unlocks a class of institutional use cases: collateral posting, cross-chain arbitrage, treasury rebalancing — that were impossible under optimistic rollup constraints. ``` Mantle Full-Stack Architecture: [Fiat / TradFi Rails] [Crypto / DeFi Rails] │ │ ↓ ↓ [UR Neobank] ←──────→ [mETH / ƒBTC / MI4] │ [Mantle Network L2] / | \ [Ethereum DA] [OP Succinct] [EVM] \ | / [Ethereum Mainnet] │ [MNT token / Treasury] ``` Settlement flows up and down the stack. Value accrues to MNT at every layer. The six pillars of Mantle 2.0 aren't marketing. Three are live and generating revenue: the network, mETH (liquid staking, now over $1B in TVL), and ƒBTC (productive Bitcoin, live on Mantle, Arbitrum, Berachain, and Sonic). Three are rolling out: MI4 (institutional crypto index fund, $400M committed), UR (on-chain neobank, currently in beta), and MantleX (AI research and incubation). When all six are running simultaneously and feeding each other, value capture for MNT holders looks structurally different from any other L2 token in the market. ## Why Other L2s Can't Catch Up [#why-other-l2s-cant-catch-up] Arbitrum has TVL. Optimism has Superchain. Base has a Coinbase distribution. None of them have a community-owned treasury, an institutional-grade index fund, a Swiss-regulated neobank in beta, or a deep CeFi alliance with a top-3 exchange. The treasury is the first-order advantage. Inherited from BitDAO, it holds approximately $2.59B in AUM — one of the largest on-chain treasuries in crypto. This isn't locked tokens waiting to dilute. It's deployed: as liquidity support across network protocols, as anchor investment in MI4, as a balance sheet behind UR's banking operations. When a competitor wants to bootstrap TVL, they run an incentive campaign. When Mantle wants to bootstrap TVL, they deploy treasury capital that earns a return. One model burns money. The other compounds it. The Bybit alliance is the second edge — and it's deeper than most realize. MNT holders unlock higher borrowing limits on Bybit products, longer fixed-rate loan maturities, trading fee discounts, and VIP acceleration perks. That integration turns Bybit's tens of millions of users into a distribution channel for Mantle's products. No other L2 has a comparable CeFi gateway. This matters especially in Asia, where Bybit's market share is dominant and where Mantle has positioned UR's initial launch market. The mETH flywheel reinforces both of the above. mETH is Mantle's liquid staking token — users deposit ETH, receive mETH, while accumulating staking rewards. cmETH layers restaking on top. The protocol crossed $1B in TVL. That ETH isn't sitting idle; it funds DeFi markets, collateralizes lending positions, while generating fees that flow back through the network. When institutions arrive via MI4 or UR, they reach a platform that already has deep, native liquidity. That's not something you build in six months. KelpDAO's rsETH incident in April 2026 tested the network under real stress. Within 48 hours, cumulative repayments across core USD assets reached approximately. Mantle's own contracts were not exploited — LayerZero confirmed the exploit was isolated entirely to KelpDAO's rsETH configuration, with zero contagion to Mantle infrastructure. The recovery speed and coordination with Aave demonstrated something a spreadsheet can't show: liquidity depth and a team capable of managing a crisis without panic. We are aware of the ongoing rsETH incident involving @KelpDAO and are actively monitoring the situation with our partners to support the community and ensure security is maintained at every level. As a precautionary measure, we have temporarily paused bridging through the Mantle The x402 gateway integration adds another dimension to Mantle's advantage. This gateway enables builders and creators to connect to the x402 protocol via the facilitator and start experimenting with faster development cycles today. Together with Questflow, Mantle is bringing x402 to everyone, everything, and everywhere within their network — a capability that sits outside the scope of what traditional L2 competitors are even pursuing. What competitors can't replicate is the combination of capital, distribution, and a product vision that extends beyond the L2 itself. Spinning up an L2 takes months. Building a treasury takes years. Earning a regulated banking partnership takes credibility that can't be purchased. Mantle has all three and has had them long enough to build on top of them. ## The Tokenized Everything Market [#the-tokenized-everything-market] Stablecoins processed more than 5x PayPal's trading volume and more than half of Visa's over the past twelve months. Circle's IPO was 25x oversubscribed. Citi projects stablecoin issuance could reach $1.9 trillion by 2030. These aren't crypto-native metrics — they're signals that traditional capital markets are waking up to on-chain settlement. The RWA market is moving in the same direction. xStocks launched on Mantle in April 2026, enabled by BackedFi and Flowdesk, bringing tokenized equities to on-chain liquidity for the first time. Users can trade some of the world's top assets 24/7 via Fluxion Network — a capability that previously had no home for migration. The platform hit $300M in AUM almost immediately, demonstrating institutional appetite for bridging traditional equity markets to DeFi. DigiFT and Deshare Finance brought SpaceX pre-IPO exposure on-chain via Mantle. Redstone launched Redstone Live — a data layer for RWA perpetual markets — directly on the network. These aren't testnet deployments. They're production-grade financial products serving real capital. MI4 addresses the disconnect between institutional ETFs and native DeFi yield opportunities. The fund has secured $400M in committed capital, establishing it as the most substantial non-Treasury bill tokenized fund currently available. Its asset composition follows traditional portfolio management principles, with approximately half invested in Bitcoin, 28% in Ethereum, 7% in Solana, and the balance in stablecoins. This structure closely resembles standard crypto indices, offering institutional investors a familiar investment vehicle. What sets it apart as crypto-native is the yield enhancement layer comprising mETH, bbSOL, and sUSDe. Securitize oversees tokenization operations while Fireblocks handles custody arrangements. The fund can be accessed by a Geneva family office without requiring MetaMask knowledge. The AI agent layer introduces another demand vector. Over two thousand autonomous agents are currently active on the network. Virtuals Protocol has produced around $4 million in revenue from agent-to-agent transactions. Allora Network's predictive AI infrastructure became operational in February 2026. The Turing Test Hackathon deployed numerous competing agents into operational DeFi markets with $20,000 in prize money. This differs from typical research initiatives, representing a functioning agentic economy that operates on Mantle infrastructure in real time. Several forces are converging to create favorable conditions: stablecoin usage is expanding, institutions are seeking tokenized asset exposure, with autonomous agents becoming more prevalent on-chain. This environment enables Mantle's extensive infrastructure to demonstrate real structural benefits. Layer 2 solutions focused exclusively on throughput struggle to attract institutional capital. Traditional banking platforms without programmability cannot effectively use DeFi yield opportunities. Mantle sits at the point where these two worlds meet. ## Project Valuation [#project-valuation] Current figures (April 22, 2026): * Market cap: $2.12B * FDV: $4.02B * Circulating supply: 3.28B MNT (\~53% of total) * FDV / market cap ratio: \~1.9x — meaningful future issuance pressure from the remaining 47% of supply The market is pricing Mantle as an L2. Pure-play L2s trade at P/TVL multiples ranging from 0.3x (Arbitrum) to over 2x (Base, early stage). At $303M in Total Value Secured (3rd among rollups) and a $2.12B market cap, Mantle trades at roughly 7.0x P/TVL — which looks compressed until you account for the treasury. ``` | Source |Forecast Range | Outlook | |------------- |----------------|---------------- | | CoinCodex | $0.43 – $0.63 | Bearish-neutral | | MEXC | $0.50 – $0.72 | Base-to-bearish | | Flitpay | $1.45 – $2.31 | Bullish | | CoinStats AI | $3.00 – $3.60+ | Stretch case | ``` ## Tokenomics [#tokenomics] Supply overhang is real. 46% of the total supply hasn't circulated yet. That's a ceiling on the thesis unless adoption grows faster than dilution. The TVL run from September 2025 to March 2026 suggests the absorption rate is accelerating — but it needs watching. The Rewards Station has distributed over 29M USDT-equivalent in yield rewards since launch — paid in MNT, WOO, EIGEN, ENA, and others. Six Bybit Megadrop events used MNT staking as access mechanism. That demand loop doesn't exist on any other L2. ``` Bybit users want higher borrowing power / VIP perks ↓ They buy / stake MNT ↓ Network activity rises, gas fees accumulate ↓ Fees flow to MNT stakers ↓ Higher MNT price makes Bybit integration more attractive ↑──────────────────────────────────────────────┘ ``` ## The Team [#the-team] The team behind Mantle hasn't sought public profiles. The output speaks instead. Bybit's Helen Liu (Co-CEO) and Emily Bao (Head of Spot Trading) came on as strategic advisors in August 2025 — not as token consultants but as executives reshaping Mantle's institutional product roadmap. The timing of MI4's launch, combined with UR's banking rails and the CeFi integrations that followed, tracks directly against that appointment. MantleX is led by Jordi Alexander, who published research on LLMs and DeFi agents before ClawHack deployed 2,000 autonomous agents into live markets. The focus is applied, not theoretical. The Economics Committee Service Providers managing treasury deployment — authorized under MIP-25, MIP-26, and MIP-28 — operate across a multisig structure covering L1, L2, and cross-chain positions. Dynamic liquidity support, AMM positions with impermanent loss accounting, staked derivative management across BTC, ETH, and SOL. That's institutional-grade treasury operations running as DAO infrastructure. What the team has shipped since 2023: EigenDA full integration (first major L2 to do it), OP Succinct testnet deployment, Skadi hardfork with full Prague/Pectra support, MI4 at $400M, UR in beta with Swiss banking rails, ƒBTC live across five chains, and 300+ dApps on the network. The execution record makes the roadmap credible. ## Trade Setup [#trade-setup] ## Technical Snapshot [#technical-snapshot] The first momentum trigger sits above roughly $0.78. A move through that level would signal that buyers are beginning to absorb overhead supply and push the price into a stronger breakout structure. Until that happens, MNT is more likely to remain range-bound, with traders watching for volume confirmation before expecting a larger move higher. MNT ran from $0.56 in July 2025 to over $2.7 in October 2025 on the Bybit alliance and MI4 governance approval. The current $0.63 price marks a 77% drawdown from that move. That's not breakdown territory — it's typical post-run digestion in a weak macro environment. Whales who positioned ahead of the Bybit announcement have taken partial profits. This range is a re-accumulation for anyone who missed the last leg. The KelpDAO rsETH incident creates a temporary overhang. Bridging through the Mantle Super Portal remains paused. Once that lifts — and the $204M in repayments that came in within 48 hours suggests it lifts soon — the forced-exit sell pressure clears. ## Catalyst Categorization [#catalyst-categorization] Mantle Strategic Catalysts Bridge / Portal Re-opening (Post-rsETH) * Expected Timing: Near-term * Impact: This is a crucial technical milestone. It clears existing sell pressure and restores full DeFi composability, allowing assets to move fluidly across the ecosystem again. UR (Beta → Full Launch) * Expected Timing: 2026 * Impact: Positions Mantle as the first L2-native neobank. By integrating Swiss banking rails, it creates a unique bridge between traditional finance and on-chain utility. Additional CeDeFi Flywheel Listings * Expected Timing: Ongoing * Impact: Creates a continuous growth loop. Each new asset listing on Bybit acts as a catalyst to drive deeper liquidity into the Mantle DeFi ecosystem. ## Future Outlook [#future-outlook] Near-term (0–12 months): Bridge re-opening removes the immediate pressure. Watch TVL holding above $1.72B and CeDeFi flywheel accelerating with each new Bybit asset listing. Medium-term (1–3 years): UR scales in Asia with Bybit distribution. MI4 becomes a recognized institutional product. MNT re-rates from "L2 token" to "exchange-platform token" — the same rerating BNB underwent when Binance Chain became the backbone of Binance's product strategy. If that thesis lands, the $8B–$10B FDV base case doesn't require a bull market. ## Key Risks [#key-risks] Supply dilution — 46% of the total supply hasn't entered circulation. If adoption doesn't outpace issuance, overhang caps price appreciation. TVL growth is encouraging; it needs to continue. Risk window: ongoing. Estimated impact: 20–40% price ceiling in a weak adoption environment. Bybit concentration — Bybit's growing influence over governance and strategy is a structural risk. If Bybit's interests diverge from token holders', the DAO model may not be sufficient to override that pull. It's the same tradeoff that made BNB a strong performer and created governance questions for Binance Chain in equal measure. Third-party contagion — The April 2026 rsETH incident showed that partner integrations carry tail risk. Mantle's own smart contracts remained secure, but the incident still created liquidity pressure that spread across the network. Future incidents in Aave, mETH, or ƒBTC could trigger similar — or worse — cascades. The $204M recovery within 48 hours demonstrates resilience, but past performance doesn't guarantee future safety. Technical execution risk — While the Arsia upgrade successfully delivered ZK rollup functionality, maintaining and expanding the CeDeFi flywheel through continuous Bybit asset listings requires sustained coordination. Each new integration introduces operational complexity and potential technical issues. The infrastructure now runs on Ethereum DA via blobs, reducing external dependencies but increasing reliance on Ethereum's capacity during high-congestion periods. Competitive pressure — Base has Coinbase. Arbitrum has deep DeFi liquidity and a large grants program. If either moves into the neobank or institutional fund space with comparable capital, Mantle's differentiation narrows. Current timing and treasury advantages are real but not permanent. Token demand vs. platform growth disconnect — TVL and product adoption can grow without MNT price following. If value accrual to MNT holders isn't direct enough — gas fees, staking rewards, Bybit perks — the token underperforms even as the underlying business succeeds. Despite these risks, the structural case holds. A treasury worth more than the market cap, a product stack generating real TVL, and a CeFi distribution channel no other L2 possesses — those are durable edges that don't evaporate in a down market. The risks are real. The upside, if execution continues, is disproportionate to current pricing. ## Conclusion [#conclusion] Mantle has assembled the only full-stack financial layer in crypto with a credible path to institutional and retail adoption at scale. The L2 is live and growing. The timing matters for a precise reason: major catalysts are already shipping. The bridge re-opening after rsETH clears immediate sell pressure. The Arsia upgrade has already delivered sub-1-hour withdrawals, unlocking institutional use cases that previously couldn't run on optimistic rollup constraints. The CeDeFi flywheel accelerates with each new Bybit asset listing via Fluxion. UR moving from beta to live launch turns the neobank narrative into an active user acquisition event in one of Bybit's strongest markets. If the base case plays out — TVL holds above $1.72B, UR scales, MI4 reaches [$1B+](https://x.com/search?q=%241B%2B\&src=cashtag_click), then MNT re-rates from a pure L2 token to the backbone of a banking platform. That's an $8B–$10B FDV event from a current $4B FDV, with an asymmetric setup intact because the treasury alone supports current prices. The bull case, where MNT undergoes a BNB-style rerating as the CeFi-DeFi bridge token for Bybit's platform, targets $18B–$25B FDV. If those key signals resolve in the next 12 months, the thesis is on track. * X: [https://x.com/Mantle\_Official](https://x.com/Mantle_Official) * Website: [https://www.mantle.xyz/](https://www.mantle.xyz/) * CA: 0x3c3a81e81dc49a522a592e7622a7e711c06bf354 This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Ovpp (/research/ovpp) # Ovpp [#ovpp] Image # The Coming Grid Collapse They Don't Talk About [#the-coming-grid-collapse-they-dont-talk-about] Energy infrastructure built decades ago cannot handle the current demand. Data center needs are exploding with AI training requiring gigawatts of capacity. EV sales hit 17 million units in 2024 and are projected to exceed 30 million annually by 2030. Rooftop solar installations are growing at double-digit rates every year. Home batteries, smart thermostats, and controllable HVAC systems are adding millions of distributed energy resources to a grid designed for centralized, one-way power flow. Elon Musk has been signaling the energy crisis for years. Tesla's entire business model shifted from pure EVs to an integrated energy network — vehicles, solar, storage, and grid services all working together. The Cybertruck was marketed with energy capabilities baked in. Tesla Energy expanded rapidly to build out battery storage capacity. The reason is simple: Musk understands that energy, not capital, is the real constraint on technological advancement. The grid operators see this coming. US electricity demand is projected to grow 15-20% by 2030 after decades of stagnation. Peak demand events are becoming more frequent and more severe. The existing transmission and distribution infrastructure cannot handle this load without massive investment. Traditional solutions — building new power plants and transmission lines — take 10-15 years and face enormous regulatory and environmental hurdles. The only path forward is to make the grid smarter, more flexible, and more distributed. The regulatory environment is pulling in the same direction. California, New York, Texas, and Massachusetts all have active virtual power plant procurement targets. The GENIUS Act is moving regulatory clarity on stablecoins forward in the US. Europe's ENTSO-E framework is pushing similar requirements across EU grid operators. State-level mandates for VPPs and demand response are creating utility procurement pressure that didn't exist two years ago. The timing is asymmetric — the need is urgent, the solutions are emerging, and the regulatory window is opening. # The Multi-Trillion Economy Running on Fax Machines [#the-multi-trillion-economy-running-on-fax-machines] The physical infrastructure is transforming. The payment infrastructure is not. Your electric vehicle finishes charging at 2 AM. It drew power during an off-peak window, helped stabilize the grid, and maybe exported stored energy back during a demand spike. The grid operator benefited in real time. Your reward? A line item adjustment on next month's bill — if the program even tracks it correctly. That's not a software bug. That's the architecture. The global electric utility industry settles transactions on payment rails designed for once-a-month, human-initiated billing cycles. The meter reader has been replaced by a smart device. The settlement system has not. When a utility tries to integrate an EV charger or a home battery into a demand-response program, they build a custom "one-off" integration with that device vendor. Then another one for the next vendor. Each integration breaks when software updates. Each has its own counterparty agreements. Each settlement cycle takes 30–90 days to clear. At the powerplant level, reconciliation can take six months. None of it was designed for micropayments denominated in kilowatt-hours at machine speed. The gap is structural. Legacy meter-data management systems are proprietary. They speak only to their own hardware and have no standard API for external devices. Over 40 brands of EVs are on the road. Rooftop solar installations, home batteries, smart thermostats — every year adds millions more distributed energy resources to a grid that wasn't built to interact with them at the device level. The existing utility back-end can only speak to its own meters. It has no payment layer for third-party devices at all. > "In the last week the amount of EV's connected has gone up approximately 60% from 250 to 415. Metcalfe's law is taking place here, still at the early stages. This is why crypto was created, for real world use where web2 falls short." — [@Saltwater\_Alpha](https://x.com/@Saltwater_Alpha) # The DNS for Energy Devices [#the-dns-for-energy-devices] OpenVPP is the first purpose-built, on-chain payment and settlement layer for the electric utility industry — a universal routing protocol that lets utilities, device vendors, and consumers transact at machine speed, denominated in any unit that energy programs require. The core architecture rests on two layers working in parallel. The first is a stablecoin payments engine that lets utilities settle in USDC directly or wrap it into energy-native tokens via on-chain oracles. One token can represent one dollar, one kilowatt-hour, one kilogram of avoided CO₂, or a time-of-use rate window. Settlement happens in under 10 seconds. Cost per transaction is under one cent. The second is what OpenVPP calls a "DNS for DERs" — a decentralized routing and registry service that works like the internet's domain name system but for energy devices. A device manufacturer integrates once. A utility integrates once. After that, any device can connect to any utility automatically, with no custom bilateral integration required. The registry stores device identity, capability, protocol, and program enrollment on-chain. Every new device that joins expands the network value for everyone already on it. ```text OpenVPP Architecture: [EV / Solar / Battery / Charger] │ single integration ▼ [Integration Service] ←→ [Registry Service (on-chain)] │ ↑ ▼ │ [Routing Service] ────────────────── │ ▼ [Utility / Grid Operator / DERMS] │ ▼ [Stablecoin Settlement Layer] Direct: USDC Oracle: $kWh / $NEM / $DR / $VPP ``` The flywheel is straightforward. Each new device that registers makes the network more useful to utilities: more dispatchable capacity, more grid visibility, more program candidates. Each new utility that integrates makes the network more useful to device vendors: more distribution, more programs, more revenue per device. Neither side needs the other to move first once a critical mass exists on either side. The network is already in motion. 448 devices are live. 528 MWh of energy has settled on-chain. 31,128 energy transactions have cleared. OpenVPP supports over 40 EV brands — Tesla, Rivian, Porsche, BMW — and any OCPP-compliant charger. The expected value to a device owner is $100–$1,000 per year in program participation rewards, settled in [$OVPP](https://x.com/search?q=%24OVPP\&src=cashtag_click) and USDC. Image This is a 0→1 infrastructure play. The analog isn't a better demand-response platform. It's the payment layer that makes demand-response programmable at all. # Why Nothing Else Closes This Gap [#why-nothing-else-closes-this-gap] The natural question: why hasn't this been built? The answer isn't that electric power companies haven't tried. They have. The answer is that the problem isn't solvable from inside their existing architecture. Utilities operate on proprietary back-end systems — meter data management platforms built by a handful of incumbents. These systems can speak to their own hardware. They cannot speak to a Tesla or a Rivian or an Enphase battery by design, because each of those devices speaks different protocols, and the utility would need to build and maintain a certified integration for each one. That's exactly the fragmentation OpenVPP eliminates with a single integration from each side. Existing blockchain DePIN protocols aren't built for this either. Protocols like Helium or Hivemapper solve device coordination for wireless or mapping networks. Energy utility settlement has requirements that are genuinely different: sub-cent micropayments at high frequency, kWh-denominated accounting, time-of-use pricing windows, compliance with state-regulated tariff structures, and metering-grade audit trails for regulatory reporting. None of the existing DePIN infrastructure handles those constraints natively. OpenVPP is building on Arc (Circle's Ethereum L1) for enterprise utility settlement and on Base for consumer-facing transactions. The choice of Arc matters — it was purpose-built for mission-critical financial settlement with sub-second finality, USDC-denominated gas, and built-in privacy. Revenue-grade settlement is native to Arc's architecture. A utility running a demand-response program tied to power market economics needs deterministic performance, not probabilistic finality. This is not a protocol that could run on any general-purpose chain. Image The team's competitive advantage is not just the technology. The CEO, Parth Kapadia, was Director of Technical Product Management at AutoGrid, Schneider Electric's grid intelligence platform and the software layer sitting between utilities and DER fleets across the industry. He knows the existing infrastructure from the inside. Craig Cremean ran VP of Transmission Operations at Exelon, one of the largest US utilities. Vish Vankadari came from Tesla Energy's programs and product team. These are not crypto founders learning the energy industry. They are energy industry leaders building on crypto rails. That background created a partnership pipeline that would take years to replicate. OpenVPP has already announced a Day 1 Architect relationship with Circle's Arc blockchain. A world-leading stablecoin issuer and a multi-billion dollar utility infrastructure vendor — both to be named post-launch — have committed as partners. Blackstart Infrastructure Partners (one of the largest US data center developers) signed an MOU to bring data centers on-chain as flexible VPP resources. Noon Energy joined the OpenVPP alliance to develop on-chain energy receipts for ultra-long-duration storage targeting AI infrastructure. These are not logo partnerships. They are the distribution channel into the regulated utility infrastructure. This edge compounds with data. Every device registered, every settlement cleared, every dispatch event executed builds a proprietary dataset of real-time grid behavior at the device level. That data has commercial value. Utilities and grid operators pay for "grid-level device awareness" via API, priced in [$OVPP](https://x.com/search?q=%24OVPP\&src=cashtag_click). No new entrant can replicate years of on-chain device telemetry. # The Market That's Being Created [#the-market-thats-being-created] The global electric utility industry processes trillions in payments annually. That number is the baseline of transactions currently flowing through legacy billing systems. OpenVPP's immediate target is not all of it. The near-term wedge is the DER segment, which is growing faster than any other part of the grid. The global distributed energy resources market was valued at $282 billion in 2022 and is projected to reach $745 billion by 2030, a CAGR of 11.4%. EV adoption is accelerating: global EV sales hit 17.1 million units in 2024 and are projected to exceed 39 million annually by 2030. Each EV is a mobile battery capable of two-way grid interaction. Each rooftop solar installation is a micro-generator. Each smart thermostat and home battery is a controllable load. The addressable device count is in the billions by the end of the decade. Grid flexibility programs — which pay consumers to reduce power usage during peak times — are projected to grow from $4.5 billion in 2023 to $30 billion by 2032. These programs require exactly the settlement capabilities that don't exist today and that OpenVPP is building: instant verification of device behavior, real-time reward issuance, and device-level audit trails. The market is being created by the infrastructure gap, and OpenVPP is closing the gap. Timing is not coincidental. The GENIUS Act is moving regulatory clarity on stablecoins forward in the US. Circle's Arc launch opens a settlement layer with revenue-grade finality that didn't exist 18 months ago. State-level mandates for virtual power plants are expanding — California, New York, Texas, and Massachusetts all have active VPP procurement targets. Europe's ENTSO-E framework is pushing similar requirements across EU grid operators. The regulatory environment is pulling utilities toward exactly the kind of programmable, auditable settlement infrastructure that OpenVPP provides. OpenVPP's distribution model is not direct-to-consumer. It is a regulated utility vendor partnership model — plugging into the existing software platforms that utilities already use for meter data management. That gives them access to utility customer bases of millions of devices without building a direct sales channel to each one. # Project Valuation [#project-valuation] Grid flexibility programs hit $30B by 2032. If OpenVPP captures 2% market share in settlement infrastructure, that generates approximately $600M in annual protocol fees and API revenue. At a 20x revenue multiple — conservative relative to Helium Network's historic peak multiples or comparable early-stage DePIN infrastructure — that implies a $12B market cap. More near-term: if OpenVPP captures just 0.1% of annual global DER transactions, protocol fees at sub-cent per transaction still generate [$50M+](https://x.com/search?q=%2450M%2B\&src=cashtag_click) annually at scale. At 15x (discount for early stage), that implies $750M market cap from current $13.8M — roughly 50x from here. The realistic 12-month case is more modest. If the undisclosed utility vendor partnership gets announced and brings 10,000 devices onto the network, that's a 20x increase in network scale from the current 448 devices. Protocol revenue begins to be measurable. The token re-rates toward comparable early-stage DePIN projects that have achieved $100–$300M market caps on similar device counts and weaker foundations. That implies 7–20x from the current price. Today's price implies almost nothing has to work. At $13.8 market cap, the market is pricing in a near-zero probability of utility-scale adoption. The asymmetry is real. # Token Mechanics [#token-mechanics] [$OVPP](https://x.com/search?q=%24OVPP\&src=cashtag_click) has three economic functions. Every new device registration requires a discrete amount of [$OVPP](https://x.com/search?q=%24OVPP\&src=cashtag_click). Every commercial API call, specifically utilities paying for grid-level device awareness data, is denominated in [$OVPP](https://x.com/search?q=%24OVPP\&src=cashtag_click). As device count scales, fee volume scales. Total supply is fixed at 1 billion tokens. There is no inflationary emission schedule. The tokenomics are deflationary by design as utility demand for registry access grows. Governance gives [$OVPP](https://x.com/search?q=%24OVPP\&src=cashtag_click) holders' voting rights on protocol direction, including decisions on future device support. This matters because device support decisions directly affect the addressable network. Each new supported EV model or charger protocol expands the TAM. Staking launched on April 8, 2026. Device owners earn rewards for demand-response participation, paid in [$OVPP](https://x.com/search?q=%24OVPP\&src=cashtag_click) and USDC. Token holders without EVs can stake for network security rewards. The early-staker premium is explicit in the design: highest rewards for the earliest participants. 1% of the total supply has been allocated to the Fomo trading platform for liquidity distribution. With \~80% of supply circulating, dilution risk is low compared to most early-stage DePIN tokens, where 70–80% of supply is still locked. The unlock overhang that kills token price post-TGE for most protocols is largely absent here. # The Team [#the-team] **Parth Kapadia (CEO/Founder)** — Former Director of Technical Product Management at AutoGrid (Schneider Electric's grid intelligence platform). Prior roles at Exelon Corp. He spent years inside the infrastructure he's now replacing. **Craig Cremean** — VP, Transmission Operations at Exelon Corp. Brings direct utility operations experience and the credibility needed for regulated utility partnerships. **Kumara Aditya** — Digital Innovation at Schneider Electric. Technical depth on the utility software stack. **Vish Vankadari** — Programs & Product at Tesla Energy. Understands DER fleet management from the largest EV manufacturer's perspective. **Michael Grasso (Strategic Advisor)** — Former CRO at Sunnova Energy (NYSE: NOVA), CMO at Sunrun (NASDAQ: RUN), and TXU Energy (Vistra Corp, NYSE: VST). Brings utility commercialization and GTM experience at scale. **Matt King** — Founder & Managing Partner, Vanquish Ventures. The team is ex-Schneider Electric, ex-Exelon, ex-Tesla Energy. These are the people who ran the software and operations at the platforms OpenVPP is integrating with. The network effects of their prior relationships are not replicable. # External Signals [#external-signals] [@tryfomo](https://x.com/@tryfomo) — 45,943 followers — Consumer trading platform [@Saltwater\_Alpha](https://x.com/@Saltwater_Alpha) — Independent analyst — On-chain observer **Blackstart Infrastructure Partners** — MOU signed — One of the largest US data center developers/operators **Circle Arc (Day 1 Architect)** — Partnership — World-leading stablecoin issuer **1M miles driven on-chain** — Network milestone — April 4, 2026 # Trade Setup [#trade-setup] Current market cap: . Fully diluted valuation: . Circulating supply is approximately 80% of total supply — minimal unlock overhang relative to most early-stage DePIN protocols. The FDV/market cap ratio is 1.24x — one of the tightest ratios in DePIN, meaning unlocks are not the risk here. Volume over the past 24 hours was $1.48M against a $13.8M market cap — a 10% daily volume/market cap ratio indicating active trading at this price level. The token is in a prolonged accumulation phase at $5M–$30M market cap — the precise window where whales, private groups, and smart money historically position before protocol metrics become undeniable. 60% EV growth in one week, staking launch on April 8, and the upcoming utility partner announcement are all catalysts that haven't been priced in yet. Market sentiment reinforces this setup. The crypto fear and greed index sits at 27 (Fear) with a 7-day average of 21.9 — deep in fear territory. BTC dominance at 59.4% with USDT dominance rising signals the broader market remains risk-off. This creates the ideal environment for asymmetric entries. Near-term catalysts are stacked: the undisclosed utility vendor partner announcement (described as "multi-billion dollar" in docs), the Circle stablecoin partner announcement, and continued device network growth as staking rewards pull more EV owners onto the platform. The Blackstart data center MOU is the first institutional-scale VPP asset in the network — watch for more enterprise announcements in Q2. The near-term accumulation range is $0.012–$0.022. Position before the utility partner announcements. $0.03–$0.05 is the first technical resistance range if device count accelerates toward 2,000–5,000 in Q3. The 12-month thesis target is $100–$300M market cap on utility partnership confirmation and 5,000+ devices live. The 12-month path is clear. Utility partner announcements drive re-rating toward $100–$300M market cap. At 12–24 months, full MDM 2.0 deployment through the utility vendor's distribution channel pushes device count toward 50,000+ and makes commercial API revenue material. At 3+ years, the DNS for DERs becomes the standard settlement layer across multiple regulated utility territories — capturing a meaningful share of the world's 1B+ connected energy devices coming on-chain. # The Risks [#the-risks] **Regulatory fragmentation** — Utility regulation is state-by-state in the US and jurisdiction-by-jurisdiction globally. Each territory has its own tariff structures, program approval processes, and data privacy requirements. OpenVPP's compliance architecture needs to work across all of them. A single regulator blocking a key market could delay revenue timelines significantly. **Partnership dependency** — The undisclosed utility vendor and stablecoin partner are central to the go-to-market thesis. If these partnerships are delayed, restructured, or fall through entirely, the distribution model changes. The "multi-billion dollar" utility vendor claim is unverifiable until announced. **Device network adoption rate** — 448 devices is proof of concept, not proof of scale. Crossing from early adopters (EV enthusiasts willing to connect their cars to a crypto protocol) to mainstream utility program participants requires a different distribution motion. The regulated vendor partnership model addresses this, but execution timelines are uncertain. **Competitive response from incumbents** — AutoGrid, Oracle Utilities, Itron, and other utility software vendors have existing relationships with every major US utility. If any of them build a comparable DER settlement layer, OpenVPP's early lead erodes. None has done so yet, but the gap creates an incentive. **Token liquidity at current market cap** — $13.8M market cap means small position sizes can create significant price swings in both directions. Sizing accordingly is not optional. **Smart contract and technical risk** — OpenVPP settles real energy transactions tied to physical grid events. A smart contract failure or oracle manipulation during a demand-response event has operational consequences beyond token price. The security requirements are higher than a typical DeFi protocol. **BTC/macro correlation** — At $13.8M market cap, [$OVPP](https://x.com/search?q=%24OVPP\&src=cashtag_click) trades like a micro-cap token, not a utility infrastructure protocol. A broad BTC correction will take it down regardless of fundamentals. The fear index at 21.9 seven-day average, signals that risk is present now. The thesis holds through most of these risks because the structural gap is real and the team has credible, non-replicable access to the distribution channel. The utility industry needs this infrastructure — the risk is execution timing, not whether the need exists. # Conclusion [#conclusion] The energy grid has become a distributed, real-time network of machines that generate, store, and consume power dynamically. The payment layer has not kept up. That gap represents transactions running on infrastructure that can't denominate value in kilowatt-hours, can't settle in under 30 days, and can't speak to a Tesla or a Rivian without a custom integration built from scratch. OpenVPP is the first protocol designed to close it — not by building another DePIN experiment, but by building the settlement standard the utility industry actually needs. The timing aligns. Circle's Arc is live. Stablecoin regulation is advancing. State VPP mandates are creating utility procurement pressure that didn't exist two years ago. The team has spent their careers inside the infrastructure they're replacing, with direct relationships at the platforms that serve the utility industry. A world-leading stablecoin issuer and a multi-billion dollar utility vendor are both in the pipeline, both unannounced. The window between "announced partnership" and "priced in" is closing. If the thesis is correct: 10,000+ devices by the end of the year, utility partner distribution enabling 100,000+ devices within 24 months, and commercial API revenue beginning to accrue — [$OVPP](https://x.com/search?q=%24OVPP\&src=cashtag_click) should trade at $100–$300M market cap within 12 months, and [$1B+](https://x.com/search?q=%241B%2B\&src=cashtag_click) is a reasonable 2–3 year target if even 0.5% of DER settlement volume routes through the protocol. The current $13.8M market cap prices in nearly zero probability of any of that happening. Watch for the utility vendor announcement. Watch for device count crossing 1,000, then 5,000. Watch for the first major utility territory signing an MDM 2.0 program through OpenVPP. Those are the signals that convert the thesis from an infrastructure play to a protocol revenue story. The architecture is built to last. * **X:** [@OpenVPP](https://x.com/OpenVPP) * **Website:** [https://openvpp.energy](https://openvpp.energy/) * **Community:** [https://t.me/OpenVPP](https://t.me/OpenVPP) * **CA:** 0x8C0d3ADCF8Ce094E1aE437557Ec90A6374dC9BDD This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Pengu (/research/pengu) # Pengu [#pengu] Image ## Why The Old IP Model Died, And Nobody Noticed [#why-the-old-ip-model-died-and-nobody-noticed] Every major consumer brand of the last century was built the same way. You spend years, sometimes decades, manufacturing cultural relevance. You pay celebrities. You run Super Bowl spots. You plant your IP in the hands of children through toys, cartoons, and coloring books, betting that the impressions compound into loyalty before the next challenger gets there first. It works, slowly. Sanrio built Hello Kitty over fifty years. Pokémon took two decades to go from a Game Boy cartridge to a $150 billion franchise. Disney has been compounding Mickey Mouse since 1928. The model works well — but only if you get there first, and only if your community never gets the chance to own a piece of what they're building. That last condition is where the entire model breaks. Fans pour billions into licensing revenue for IP they will never share in. A die-hard Pokémon collector who has spent $30,000 on cards over twenty years captures exactly zero of the value he helped create. No royalty. No equity. No upside beyond the cards themselves. The relationship is transactional by design: you consume, they capture. What nobody in the traditional IP world has yet reconciled is that this model is now structurally replicable — and for the first time in history, a challenger can build community ownership from day one. Not later. Not as a reward for long tenure. From the moment someone buys the first toy off a Walmart shelf, scans the QR code on the package, and lands on-chain for the first time. It works, slowly. Sanrio built Hello Kitty over fifty years. Pokémon took two decades to go from a Game Boy cartridge to a $150 billion franchise. Disney has been compounding Mickey Mouse since 1928. The model works well — but only if you get there first, and only if your community never gets the chance to own a piece of what they're building. That last condition is where the entire model breaks. Fans pour billions into licensing revenue for IP they will never share in. A die-hard Pokémon collector who has spent $30,000 on cards over twenty years captures exactly zero of the value he helped create. No royalty. No equity. No upside beyond the cards themselves. The relationship is transactional by design: you consume, they capture. What nobody in the traditional IP world has yet reconciled is that this model is now structurally replicable — and for the first time in history, a challenger can build community ownership from day one. Not later. Not as a reward for long tenure. From the moment someone buys the first toy off a Walmart shelf, scans the QR code on the package, and lands on-chain for the first time. The window to build the next great global IP using the old rules is closing. The window to build using the new rules has been open for exactly four years. One team saw it early, executed without pause, and is now sitting on an asset that cannot be replicated on a compressed timeline. The moat isn't the penguin. The moat is four years of compounding decisions that would take any competitor a decade to retrace. What makes this IP different is that it was born in crypto, not in a corporate boardroom. Four college students launched Pudgy Penguins on July 22, 2021 — 8,888 uniquely generated penguin NFTs with over 150 traits on Ethereum. The collection sold out in 19 minutes at 0.03 ETH. Floor prices rocketed to 100x mint value, with the rarest Pudgy (#6873) selling for 225 ETH ($775,000) in August 2021. By year's end, the project had generated over $100M in secondary market volume. The acquisition story matters here. By January 2022, community revolt reached its peak. Holders voted to remove founding team members amid rumors of fund misuse and failed roadmap delivery. The project in crisis was acquired for 750 ETH ($2.5M) in April 2022 by Igloo Inc., founded by Luca Netz (CEO), Lorenzo Melendez (President), Peter Lobanov (CCO), and Vedant Mangaldas (Head of Strategy). They completely restructured the vision with a refreshed mission statement: "Pudgy Penguins exists to create a home where everyone can be somebody." Floor prices recovered from sub-1 ETH to above 5 ETH by year's end as the turnaround began. Here's the evolution that most miss: culture tokens and memecoins follow a simple lifecycle — idea, launch, narrative dies, community dies. Social currencies take a different path — idea, launch, narrative becomes brand, brand proliferates, ecosystem forms, globally adopted currency. PENGU has already crossed from the first path to the second. That transition is the structural edge. ## The Gif Empire Nobody Saw Coming [#the-gif-empire-nobody-saw-coming] The internet's relationship with culture is measured in GIFs. This sounds trivial until you look at the data. GIPHY processes over 10 billion API requests per day — embedded in every major messaging app, social platform, and keyboard in the Western hemisphere. When you send a reaction in iMessage, Slack, or Instagram, you are almost certainly sending a GIF sourced from GIPHY. The brand that controls the most-viewed GIF library controls the emotional vocabulary of internet communication. Pudgy Penguins has 28,500 GIFs on GIPHY with 278 billion GIF views and 387+ billion total views across all platforms. Disney, with a century of IP and the most recognizable characters on earth, has 587 uploads and 23 billion views. Pokémon — a $150 billion franchise — has 10.8 billion. Hello Kitty, 7.4 billion. The brand reaches 5 million global followers across social platforms. Image The gap is not a rounding error. Pudgy Penguins has more than 12x the GIF views of Disney. They did not get there through a hundred-year legacy. They got there by treating impression volume as a primary business metric when every other brand, crypto or otherwise, was optimizing for revenue. This is the key insight most analysts miss when they model the business. Luca Netz said it plainly at KBW in April 2026: "I am in the business of proliferating the penguin. Impressions and eyeballs trump all. I am a little less concerned about how much money that Pudgy Penguin brand and business makes and more concerned about how popular the penguin is in Web3 and Web2 culture." That is not a cope. That is a deliberate sequencing decision made by someone who watched how Disney built Mickey and decided to compress the timeline from a century to a decade. The infrastructure to deliver that impression volume, a brand character versatile enough to be funny, warm, sad, and celebratory, is now built. 300 million people interacted with the brand daily by January 2025. That number does not appear from nowhere. It is the compounding result of a specific decision made in 2022 to treat GIF distribution as a distribution channel, not a marketing tactic. The awareness matters here. Culture tokens lack awareness — they monetize viral moments until those moments disappear. Social currencies are aware — they create trends and catch them, remaining relevant as culture shifts. PENGU has demonstrated this awareness for four straight years across bull and bear markets. Awareness equals relevance, relevance equals attention, attention equals momentum. Unless you are at the top of crypto legacy, anything that lacks awareness will die. ## What The Market Is Getting Wrong About Pengu [#what-the-market-is-getting-wrong-about-pengu] Most analysts look at PENGU and see a meme coin with toy sales. That framing is wrong in ways that matter to the price. PENGU is not a memecoin. It is what Luca Netz calls a "social currency" — a token that has graduated into something with fundamentals. Social currencies are strategic. They create trends rather than monetize them. They are built as Player vs Everyone — bringing new people into crypto — not Player vs Player, the musical chairs game most projects play. The correct frame is this: Igloo Inc. is a brand-building machine that has figured out how to wire community ownership into every layer of the funnel — and is now building the financial rails to make that ownership liquid, institutionalized, and globally accessible. **The physical products aren't toys. They are onboarding infrastructure.** Every Pudgy toy sold at Walmart, GameStop, and Target — 3 million units across 10,000+ retail locations globally — comes with a QR code. Scan it, go through a wallet creation flow, and within 60 seconds you are an on-chain Abstract Chain user. No prior crypto knowledge required. The toy is not a revenue line. It is a distribution mechanism for a Layer 2 blockchain, dressed as a $15 plush. The retail expansion followed a specific playbook. The launch of Pudgy Toys in May 2023 generated over $500,000 in first-weekend sales, with 20,000+ units sold and #1 rankings on Amazon. Success expanded beyond the initial 2,000 Walmart locations worldwide to include Target, GameStop, Smyths, Five Below, Big W, and Walgreens, ultimately reaching upwards of 10,000 retailers worldwide and selling over 2 million toys globally. Notably, penguin designs were licensed directly from NFT holders who received royalties for toys sold worldwide. Meanwhile, Pudgy Penguins Instagram amassed hundreds of millions of views and reached 1 million followers in under a year, establishing true mainstream cultural relevance. **The royalty structure isn't a gimmick. It's a reinvention of the IP licensing model.** Every toy sold pays a royalty in perpetuity to the NFT holder whose penguin was used to design it. These are not large individual checks. But the structural implication is enormous: for the first time, early believers in an IP brand capture a share of every physical unit that brand sells, forever, at every retailer in the world. Luca's framing at KBW is useful here. Imagine owning a first-edition Charizard that earns you a royalty every time a new Pokémon toy ships. That ship never came for Pokémon fans. It is already sailing for Pudgy holders. **The community isn't a Discord. It is a distribution network embedded into every major institution in crypto.** Luca describes what he calls the "Pengu Pal Mafia" — the observation that in virtually every major organization in the crypto space, someone in leadership holds a Pudgy Penguin NFT or PENGU tokens. Market makers, liquid funds, media companies, exchanges, institutional investors. This isn't correlation. It is a compounding network effect that turns every new institution entering crypto into a potential distribution partner, investor, or ally. Image The cafeteria table analogy he uses lands because it's accurate. Being Pudgy Penguin aligned is a social signal in crypto. That kind of network effect doesn't appear on a balance sheet, but it shows up in institutional filings, ETF launches, and the speed at which partnerships get done. ```text Traditional IP Model: Pudgy IP Model: [Brand] → [Products] → [Fans] [Brand] → [Products] → [Consumers] ↓ [QR Code / Scan] ↓ [On-chain / Token Holder] ↓ [Royalties + Community] ↑ [Builders / NFT Holders] ↑ [Reinvests in Brand Growth] ``` The core difference: fans of traditional IP consume and leave. Pudgy participants are aligned with the brand's upside from first contact. ## Why No One Catches Up [#why-no-one-catches-up] It is easy to say "Pudgy has a strong brand." It is harder to quantify why the lead is structurally insurmountable for anyone trying to enter in 2026 or later. But the answer becomes clear when you map the sequence of decisions since April 2022. The brand was acquired for $2.5 million — 750 ETH — in April 2022. Bear market. NFT sentiment is at a low. The team's first move was not a token launch or a floor-price campaign. It was a Bloomberg feature, a "Quest Map" for IP development, and a partnership with PMI Toys — the manufacturer behind Fortnite and Nickelodeon branded products. By September 2023, Pudgy toys were in 2,000 Walmart stores. By February 2024, Walmart placed a re-order expanding to 3,100 stores. Consider what that re-order represents. Walmart does not extend shelf space for products that don't move. A re-order from Walmart is one of the most credible external validations a consumer brand can receive — more meaningful, operationally, than any endorsement deal. By June 2024, the team announced Abstract Chain and Igloo Inc., turning the brand into a full technology company with its own Layer 2 blockchain. The toys now onboard users into a proprietary chain. The GIF library drives traffic to branded experiences. The token captures value across all layers. No competitor can replicate four years of Walmart re-orders, 387 billion total views, a $9M seed from 1kx, WME representation for film and TV, a Random House book deal, a DreamWorks Kung Fu Panda collaboration, a Manchester City uniform deal, a GameStop partnership, and now a PlayMonster Games collaboration — and compress it into 12 months. The compound interest on four years of delivery is not catchable. A new entrant would need to start from GIF zero, toy shelf zero, and community zero simultaneously, during a market cycle where attention is finite and Pudgy already occupies the "crypto mascot" position in the public mind. The brand Luca is building toward is not "crypto's best NFT project." It is crypto's face to the mainstream world — and beyond that, the face of finance itself. When Pengu appeared in the Bitwise ETF commercial and the VanEck ETF commercial in 2024, it was not a sponsorship. It was validation that institutional products were choosing this brand, not the other way around. ## Market Opportunity [#market-opportunity] The consumer IP business is a $300+ billion annual licensing market. The plush toy segment alone is $20 billion. Pokémon, the most successful entertainment IP ever built, generates approximately $15 billion annually across all verticals. The business Pudgy is building is not trying to capture a percentage of these markets — it is trying to own a new category that none of them occupy: community-owned global IP with on-chain equity rails. Social currencies combine the best of both worlds. They have the retail appeal and viral mechanics of culture tokens, but they are interesting enough for institutions to participate. This is why VanEck and Bitwise chose Pudgy for their institutional ETF commercials. This is why the Canary Capital ETF filing exists. You get upside potential with fundamentals that justify institutional allocation. That combination is rare. The near-term addressable market is concrete. At $50 million in annual revenue from toys and apparel across 10,000 retail locations — a milestone already reached — Pudgy is generating more real-world revenue than almost any other Web3 native project that exists today. The pathway from $50M to $500M is a product of two things: retail expansion into Asia (where Line Friends and Lotte are live partnerships) and monetization of digital products. The Pengu Card launched globally across 170+ countries in early 2026 with Visa and KAST. Usable at 150 million merchants. This product does not generate immaterial transaction fees — it wires the Pengu brand into daily financial behavior for users who may have no prior crypto exposure. The Pengu Card is Pudgy's entry into consumer finance. Luca has said plainly that Pengu will be the face of finance. The card is the first instrument that makes that statement operational. The Canary Capital spot PENGU ETF filing with the SEC is the institutional layer. If approved, this becomes the first ETF structure built around a community-born token — combining NFT exposure with token exposure in a single regulated product. The filing was picked up by the CBOE. This is not uncertain. It is the formalization of an asset class that institutions have been informally participating in since 2022. Citi projects a 45% CAGR for the stablecoin market. The gaming market for collectible card games — which Pudgy enters through Vibes TCG — is projected at $12 billion by 2030. Pudgy World launched with 50,000 sign-ups in its first month. Pudgy Party surpassed 500,000 downloads in two weeks. A new Lil Pudgys brand features its own YouTube series targeting children and tweens, with a standalone product line planned for retail launch in 2026-2027. Pudgy Party, a highly anticipated iOS game developed with Mythical Games, is set for global launch, alongside a refreshed Pudgy Penguins product line hitting retail in late 2026. Most significantly, Igloo Inc. is establishing APAC operations to aggressively position Pudgy Penguins across major Asian markets, with dedicated APAC-specific creative, marketing, and product teams being assembled to meet rapidly growing regional demand. This multi-pronged approach positions Pudgy Penguins not just as a crypto success story but as a global entertainment franchise spanning digital experiences, physical products, and cultural markets worldwide. PenguBot extends the ecosystem into agentic AI trading as the ultimate agentic trading companion on Telegram. Trade smarter, faster, and safer with a self-custodial wallet across Solana, Ethereum, and Abstract. This brings PENGU into the agentic AI category, a major growth area in crypto, and provides more practical utility. This multi-pronged approach positions Pudgy Penguins not just as a crypto success story, but as a global entertainment franchise spanning digital experiences, physical products, and cultural markets worldwide. The total market Pudgy competes in is not crypto. It is a global consumer culture: toys, games, GIFs, fashion, finance, and entertainment. The crypto-native equity structure is the unfair advantage inside that competition. ## Valuation [#valuation] At $50M annual revenue and a $709M FDV, PENGU trades at roughly 14x revenue. Compare that to Funko at 1x, Hasbro at 2x, and Disney at 2.5x. The premium appears steep on a traditional comp basis — but those companies are not growing at Pudgy's rate, do not have their community structure, and are not simultaneously building a Layer 2 blockchain, launching a Visa card, filing for an ETF, and pursuing a 2027 IPO. The correct comparable is not a toy company. It is a hybrid consumer-tech brand with a defensible community moat and institutional distribution entering its first proper growth phase. On that basis, the 14x multiple is not a stretch — it is closer to fair value assuming the $50M revenue trajectory compounds at 40–50% annually toward the IPO. The upside scenario: **$50M revenue × 30x growth multiple = $1.5B market cap** — approximately 3x from the current price — as a base case before the IPO narrative fully prices in. A mainnet Abstract Chain success story, sustained gaming DAUs, and ETF approval represent incremental catalysts that do not require extrapolating beyond the current trajectory. The FDV at $709M versus a $501M market cap is a 1.4x ratio, with most unlocks tied to community claims and already behind us after the burn. Minimal unlock overhang relative to most tokens at this stage. ## Tokenomics [#tokenomics] PENGU launched in December 2024 with a max supply of 88,888,888,888. The [$PENGU](https://x.com/search?q=%24PENGU\&src=cashtag_click) launch took the crypto space by storm, achieving a $2+ billion market cap on day one and trending across all major exchanges. The token explosively expanded brand participation from 4,000 NFT holders to nearly 1 million [$PENGU](https://x.com/search?q=%24PENGU\&src=cashtag_click) holders worldwide. The project airdropped over $1.5 billion to early believers and community members, with individual Pudgy holders receiving approximately $75,000 per penguin. After the claim period closed in February 2025, 13.69% of the supply — 12.16 billion tokens worth approximately $98.2 million — was permanently burned. The token now has 737,046 holders. Combined with the current circulating supply, this positions PENGU as one of the most credible deflationary narratives in consumer-facing crypto. The token also powers a Solana validator with 7-11% EST APY, 130,000 SOL staked by 393 unique stakers. This creates additional demand and staking mechanics beyond traditional token utility. The token serves three distinct functions. First, as a cultural asset: integrated into 7,000+ Shopify stores globally, accepted on Lufthansa flights, and embedded as the native currency of the Pengu Card. Second, as a gaming primitive, PENGU operates as in-game currency across Pudgy Party, Pudgy World, and Vibes TCG — with Abstract Chain providing the settlement layer. Third, as an institutional-grade asset, the Canary Capital ETF filing combines NFT and token exposure in a single regulated structure, something no other consumer-born token has achieved. The supply dynamic is structurally favorable. Post-burn, the deflationary story is real — not projected. Each toy sold that triggers a QR-code wallet creation adds a net new holder to the circulating base, without adding supply. Each new game user who acquires PENGU for in-game utility adds demand without inflationary pressure. ## The Team [#the-team] **Luca Netz** acquired Pudgy Penguins and turned it into crypto's most recognized consumer brand within three years. Prior to Pudgy, he ran a D2C brand doing eight-figure revenue — experience that directly informed the retail-first, impressions-first strategy. His KBW keynote in April 2026 is the clearest articulation of the thesis: three verticals, one flywheel, one destination — the face of global finance. The Igloo Inc. team shipped five distinct products in the last 24 months: the PENGU token, Abstract Chain mainnet, Pudgy Party, Pudgy World, and the Pengu Card. Teams that can ship across gaming, token economics, retail, and infrastructure simultaneously are rare. That execution velocity is the most credible signal available. ## External Signals [#external-signals] * **Canary Capital.** Spot PENGU ETF S-1 filing with the SEC, first-of-its-kind for a community-born token — An ETF filing from a credible issuer signals institutional conviction in the asset. Approval would create a regulated on-ramp for capital that currently cannot touch crypto-native tokens. * **VanEck + Bitwise.** Both chose Pudgy Penguins as the brand for their Ethereum ETF commercials — Institutional asset managers chose Pudgy as the face of their regulated products. That brand judgment does not happen by accident. * **Nasdaq Opening Bell.** The team rang the opening bell in 2025 alongside VanEck — Access to Nasdaq symbolics is earned, not bought. This positions the brand directly inside institutional financial infrastructure. * **Congressman Tim Moore.** Changed his House floor profile picture to a Pudgy Penguin — Political mindshare is a leading indicator for regulatory favorability. Having sitting congressmen publicly aligned with the brand is without precedent in crypto. * **SEC Commissioner Hester Peirce** — Direct meeting with the Pudgy team to discuss Web3 and consumer protection. **Why this matters**: Regulatory engagement at this level signals the brand is being treated as a mainstream stakeholder, not a crypto curiosity. * **Technical Government Advisors** — Pudgy Penguins now holds the unique distinction of being technical government advisors. **Why this matters**: This cements their evolution from internet meme to serious institutional player shaping the future of financial culture. Few crypto projects have this level of government recognition. * **Manchester City** — Premium collectible deal targeting 300 million global fans — Manchester City has 300 million global followers. This partnership directly addresses the brand's stated priority of Asia and Europe expansion. * **Mediacom Toy BE\@RBRICK** — Limited-edition high-end art collectible available in Japan — BE\@RBRICK crosses Pengu's playful design with signature silhouette, available in Mediacom Toy stores across Japan from November 24, positioning Pudgy in the high-end collectible market alongside traditional art brands. * **The Hundreds Collaboration**. Pudgy Penguins x The Hundreds collectible collection — Both brands started with stories shared through images. This collaboration expands Pudgy's presence into the streetwear culture, another avenue for mainstream crossover. * **VANDYTHEPINK® Collaboration**. Streetwear drop combining two beloved characters — This limited drop brings together VANDYTHEPINK® and Pudgy Penguins in a playful fusion of cuteness and culture. It's as bold as it is adorable, expanding Pudgy's reach into the iconic streetwear space. * **PlayMonster Games Partnership**. Bringing Pengu to life in IRL viral games — PlayMonster creates some of the most viral IRL games on the internet. This partnership extends Pengu's presence into physical gaming culture beyond digital experiences. * **Sotheby's Auction** — "Snowed In: A Rare Pudgy Penguins Sale" — Sotheby's auctions position Pudgy Penguins in the fine art collectible market, validating the brand as art-worthy beyond toy pricing. This signals institutional art market acceptance. ## Trade Setup [#trade-setup] [$PENGU](https://x.com/search?q=%24PENGU\&src=cashtag_click) is currently trading at $0.00779, with a market cap of $501M and an FDV of . The token is down approximately 83% since the 2025 high and has been in a very tight re-accumulation range for the last few months. The recent daily volume spike could create a larger upside move and a potential breakout. However, if the crypto bear market continues, we might see an extended accumulation period. Image The 90-day drawdown tracks the altcoin market's overall weakness rather than any project-specific decline. If anything, the brand has become structurally stronger over that period: the Pengu Card launched, the ETF filing went live, Pudgy World crossed 50,000 sign-ups, and $50M annual revenue was confirmed. Price went down while fundamentals went up. That divergence is the setup. Key near-term catalysts are specific and trackable: ETF approval or SEC response to the Canary Capital S-1, the 2027 IPO roadmap becoming public, any movie or TV announcement (Luca referenced a potential movie at KBW), continued Asia expansion through the Line Friends and Lotte pipelines, and Pudgy World DAU milestones through mid-2026. **Near-term (0–12 months):** ETF ruling, IPO announcement framing, movie/TV confirmation, Pudgy World to 500K users, Abstract Chain TVL crossing . Target: $1.5B–$2B market cap on sustained delivery. **Medium-term (1–3 years):** IPO in 2027 if revenue trajectory holds. Asia retail rollout through Lotte, Line Friends, and new Korean/Japanese partnerships following the KBW focus. PENGU as default cultural currency in Western digital communication. The brand has participated in the largest TikTok livestream event, collaborated with major social influencers, and partnered with established brands like Penguin Random House, cementing Pudgy Penguins as not just an NFT success story but a legitimate cultural and financial phenomenon. Target: $2B–$5B FDV range if IPO valuation signals land in the $5B–$10B range for Igloo Inc. **Long-term (3+ years):** The face of finance thesis plays out or it doesn't. If it does, you are looking at a Pokémon-scale IP with on-chain equity — and a token that is woven into the financial infrastructure of the brand from the beginning. ## The Risks [#the-risks] **Memecoin Risk** The market still prices PENGU partially as a memecoin. If broader speculative markets collapse or sentiment shifts, PENGU could face sell pressure unrelated to fundamentals. The challenge is continuing to build fundamentals that separate it from pure volatility. **Execution Risk on Multiple Fronts** The team is running five distinct product lines simultaneously: retail toys, gaming (two titles), a Visa card, an L2 blockchain, and an ETF process. Dropping any one of these below the quality threshold damages the others. The most credible risk is Pudgy World user retention — DAUs that inflate at launch and collapse within 60 days would undermine the digital world thesis. **ETF Denial or Delay** The Canary Capital S-1 is with the SEC. A denial on policy grounds — the commission ruling that a community-born token with NFT components is not suitable for an ETF structure — removes one of the strongest institutional catalysts. Not a thesis-killer, but a few month price headwind if it happens. **Token Supply Overhang** Circulating supply is 62.8B of 88.8B max — approximately 70.7% circulating post-burn. The remaining 26B tokens represent potential future sell pressure depending on vesting schedules and team allocations. This is manageable but should be tracked against unlock dates. **Asia Execution** Luca named Asia as the number one growth focus. The partnerships are in place — Lotte, Line Friends, Suplay in China, and the KBW keynote itself signals intent. But Asia retail delivery requires local partners, supply chains, and marketing that is culturally different from the US market. Stumbling on localization would delay the most important growth vector. **NFT Floor Dependency** The royalty model — where NFT holders earn on every toy sold — creates alignment but also creates a price feedback loop. If the Pudgy Penguin NFT floor collapses significantly, the most engaged community members (NFT holders) are financially demotivated. A sustained NFT bear market would slow community-driven brand amplification. Pudgy Penguins reached unprecedented heights in late 2024 and early 2025, achieving all-time high NFT floor prices above 36 ETH while maintaining its position as the third most valuable collection globally. This floor strength validates the brand's premium position in the market. **Competitive Response from Web2** Disney, Sanrio, or Pokémon Company could launch token-based community programs. They have not, and the structural barriers to doing so through legacy corporate governance are significant — but the risk is nonzero over a five-year horizon. Any major Web2 IP brand that successfully wires token ownership into its community would challenge the "first mover" narrative. **Concentration Risk on Leadership** The brand's narrative is closely tied to Luca Netz personally. His presence at Nasdaq, KBW, congressional meetings, and ETF roadshows is part of the signal. A leadership transition would create uncertainty disproportionate to what it would at a more decentralized protocol. ## Conclusion [#conclusion] Four years ago, somebody bought a dying NFT project for $2.5 million and decided that the most important variable in building a generational IP was not storytelling, not product design, not even community — it was community ownership. Fans of every major IP brand on earth spend billions they will never see again. Pudgy Penguins changed that by wiring ownership into every layer of the brand: from the toy shelf to the blockchain, from the GIF library to the stock exchange. PENGU is the execution bet. Everything else is hoping for luck. The result is a brand that has 12x the GIF views of Disney, over 387 billion total views, 5 million global followers, $50M in annual physical product revenue, a Visa card in 170 countries, a spot ETF on the SEC's desk, a Solana validator with 393 stakers, a Mediacom Toy high-end collectible launch, and a congressman who changed his profile picture to a penguin on the House floor. None of that was accidental. Every data point traces back to a sequencing decision made early that most teams would not have made — optimize for reach before revenue, build community ownership before product market fit, wire the token into the physical product before the token was even launched. But here's what most analysts miss about what Luca is actually betting on. Impressions are the engine, but they're not the destination. The thesis has three pillars: cultural dominance as the distribution layer, community ownership as the economic layer, and financial infrastructure as the monetization layer. Each pillar reinforces the other. Billions must huddle, but they also get paid. The proliferation of the penguin across GIFs, toys, games, and now financial infrastructure creates a feedback loop that traditional IP cannot replicate. When a child scans a QR code on a Walmart toy and becomes a token holder, they are not just joining a community — they are buying equity in the brand they just helped build. When an ETF filer uses Pudgy Penguins in institutional commercials, they are not choosing a mascot — they are choosing the face of the asset class they are about to sell. When PENGU becomes spendable on Lufthansa flights, the token has crossed from crypto curiosity to payment infrastructure. The timing is now asymmetric. The ETF filing has no historical precedent for a community-born token. The 2027 IPO would create the first crypto-native brand to go public on the strength of physical licensing revenue, not protocol fees. The Pengu Card wires the brand into daily financial behavior for users who have never touched crypto. The Abstract Chain turns every toy sale into a blockchain onboarding event. If the thesis is correct — and the data to support it is not hypothetical, it is already printed — PENGU at $501M market cap is trading at a significant discount to its 12-month destination. The base case scenario of $1.5B market cap requires no new assumptions, only that current revenue compounds at the same rate it has for four years and that one of the five major catalysts (ETF, IPO roadmap, movie/TV, Asia scale, Pudgy World DAU) lands. Watch the Canary Capital ETF ruling, the IPO timeline announcement, and Abstract Chain TVL as the three confirmation signals for this thesis. The penguin was always going to win the GIF war. The question is whether the market prices in that this is the first IP brand where the fans hold the equity before or after the IPO papers hit. * **X:** [@pudgypenguins](https://x.com/pudgypenguins) * **Website:** [https://www.igloo.inc](https://www.igloo.inc/) * **Community:** [https://discord.gg/pudgypenguins](https://discord.gg/pudgypenguins) * **CA:** 2zMMhcVQEXDtdE6vsFS7S7D5oUodfJHE8vd1gnBouauv This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # PsyopAnime (/research/psyopanime) # PsyopAnime [#psyopanime] Image ## The Architecture That's Holding Legacy Media Back [#the-architecture-thats-holding-legacy-media-back] The way most people under 30 consume news is broken — but not for the obvious reasons. It's not that journalism is dying. It's that the format is no longer captivating. Text articles scroll past. Cable news runs in the background. The aesthetic language of institutional media — talking heads, lower-thirds, B-roll — was designed for a world where you had no other option. Today, attention is the scarcest resource on the internet, and legacy formats were never built to compete for it. The deeper problem is structural. Traditional news production is slow by design. A story breaks, gets verified, gets edited, gets approved, gets published. The news cycle has compressed from days to hours. But production cycles haven't followed. The gap between "this just happened" and "here's a polished, shareable explainer" is still measured in hours at best — and the output that fills it is almost always either dry text or low-quality clips optimized for speed over impact. At the same time, anime has quietly become the aesthetic language of the internet. Not just as entertainment — as a communication format. The visual vocabulary of dramatic reaction cuts, expressive characters, and cinematic pacing is fluent to anyone who has spent time on X, Reddit, or YouTube. It crosses linguistic barriers in a way a Western news anchor never will. A PsyopAnime clip got dubbed into Japanese and circulated with 43K views — that's not a curiosity, that's distribution no traditional news outlet has access to. The gap this creates is precise: there's an enormous audience that processes the world through the lens of narrative drama, fluent in anime aesthetics, that gets its information from X in real time. Nobody was producing content specifically for that audience at broadcast quality. Nobody with production credibility, at least — until Aiden Guo started shipping. ## The Studio Model Nobody Saw Coming [#the-studio-model-nobody-saw-coming] PsyopAnime is a decentralized AI-native anime studio that converts real-time world events into cinematic short-form content — funded entirely by token fees, accountable entirely to its community. The distribution strategy runs on multiple tracks simultaneously. The most visible is the quote-reply — a major news event breaks, PsyopAnime replies directly to the highest-engagement thread with a cinematic anime short, tapping existing audience momentum and riding the algorithm. When [Iran protests coverage](https://x.com/PsyopAnime/status/2010006573364748497) hit 244K views, and the [Chinese cargo anime](https://x.com/PsyopAnime/status/2043535169559130432?s=20) reached 135K views, that was the quote-reply engine at work. But that's only one lane. The second track is the standalone drop — original narrative content that frames PsyopAnime's own cultural worldview and becomes the story itself. ["I get my news from psyopanime"](https://x.com/PsyopAnime/status/2013369656539574729?s=20) hit 892K views and became a self-reinforcing meme. ["The gaslighting is crazy"](https://x.com/PsyopAnime/status/2029267645707796640?s=20) landed 626K views without anchoring to any third-party thread. These aren't reactions — they're original cultural artifacts. The third track is platform-native discoverability. X's trending algorithm has already featured PsyopAnime content in the ["What's Happening"](https://x.com/PsyopAnime/status/2013405252867744248?s=20) section [multiple times](https://x.com/PsyopAnime/status/2020152982986199048) — organic placement is typically reserved for major verified media outlets. That's the algorithm confirming what the engagement numbers already show: this content performs at the platform level, not within a crypto niche. The fourth track is long-form episodic. YouTube at 62.3K subscribers runs as a parallel narrative universe — the [WW3 Venezuela episode](https://www.youtube.com/watch?v=QtVXX2bpGjA) hit 611K views, the [Iran Revolution episode](https://www.youtube.com/watch?v=XMOG-5TTiCg) 241K, Episode 3 hit 225K. These aren't short viral clips. These are cinematic episodes building a serialized narrative around geopolitical events, creating returning audiences who come back for the next drop. All four tracks compound into each other. A viral clip drives YouTube subscribers. A trending placement drives X followers. A news outlet embed drives both. The studio is running a media network, not an X account. The genuine breakthrough is what [@aidenguoai](https://x.com/@aidenguoai) brings to the production pipeline. He's credited on One Piece #1024 and Dandakan #4 — that's not a hobbyist with Midjourney. That's a professional anime director who understands shot composition, character consistency, and emotional pacing, applying that expertise to AI tools in a way that solves the hardest problem in AI video: style drift. The PsyopQueen character appears across dozens of clips with consistent design, expression range, and cinematic identity. That consistency is a moat. The tools are available to anyone. The directing eye is not. ```text Breaking Event / Original Narrative ↓ ┌────────┴──────────────┬─────────────────┐ ↓ ↓ ↓ Quote-reply Standalone Episodic to trending cultural YouTube thread drop series ↓ ↓ ↓ └──────────── Viral pickup ───────────────┘ ↓ News outlets embed as explainer ↓ X Trending placement (organic) ↓ Token fees → studio headcount → scale ↓ Next event reaches compounding base ↑___________________↓ ``` The studio started with one person and zero budget in early 2026. By April, it had multiple full-time employees, professional director talent contracted in, a live broadcast platform at [psyopanime.xyz](https://psyopanime.xyz/), and a YouTube channel with individual videos clearing 600K views. That's roughly 90 days of operating history. ## The Tool Iteration Strategy [#the-tool-iteration-strategy] Here's what most analysts miss about AI-native studios: the tools are not everything. The iteration speed is. PsyopAnime runs a live competitive testing process across every major AI video platform as each drops. Not as a side experiment — as a core production strategy. * WonderCanvas [was tested and shipped](https://x.com/PsyopAnime/status/2025991934297481721) publicly. * Seedance was [put through its paces](https://x.com/PsyopAnime/status/2021449395938762769) on actual content. * Grok Imagine was [integrated and stress-tested](https://x.com/PsyopAnime/status/2017842852428980282?s=20), then [pushed further as the model improved](https://x.com/PsyopAnime/status/2038602864784732468?s=20). * [The Grok Imagine community contest](https://x.com/PsyopAnime/status/2026732558806081811) in February 2026 — [$1,700 USDC prize pool](https://x.com/PsyopAnime/status/2032348791093776736?s=20), community-submitted 30s–2min animations — was simultaneously a quality stress-test and a community engagement play, generating free content and organic reach in a single move. This matters because AI video generation is improving every 60–90 days in ways that completely reshape what's possible. A studio passively using one tool will be perpetually behind a studio actively evaluating every tool as it ships. PsyopAnime's production process is a public documentation of this advantage: iterative testing across platforms, post-production compositing across outputs, and deliberate aesthetic choices about which tool handles which kind of scene. The result is output that looks like it came from one coherent pipeline — because the director's eye is the constant, not the underlying model. Any competitor entering this space starts from zero on tool optimization. PsyopAnime has 150+ days of live production data across every major AI video platform on the market. That gap widens every month. ## Why News Outlets Are Already Using Their Content [#why-news-outlets-are-already-using-their-content] The most under-discussed signal in this thesis is not Elon's follow. It's the organic newsroom behavior. * Breaking911 [posted a PsyopAnime clip](https://x.com/Breaking911/status/2027032625387343904) that reached 2.1M views. * The Middle East Observer [embedded a clip](https://x.com/ME_Observer_/status/2013415711079633137) as a primary news source. * ME24 [chose the video](https://x.com/MiddleEast_24/status/2010755211162161514) for breaking coverage. * RTSG [embedded independently](https://x.com/RTSG_Main/status/2014051190904902053). * BitcoinNews [picked it up](https://x.com/BitcoinNewsCom/status/2022430343106908638) without prompting. * TBC [used it](https://x.com/TBC_on_X/status/2020544409281200548) as an explainer format. None of this was coordinated. All of it was rational. News outlets face the same engagement problem as everyone else — their audiences are migrating to formats that hold attention. A PsyopAnime clip on Iran protests outperforms a text headline by orders of magnitude in shares, replies, and time-on-content. Embedding it isn't an editorial compromise; it's an algorithm optimization. The outlets get engagement they couldn't produce themselves. PsyopAnime gets distribution it didn't have to pay for. The scaling implication is direct: this pattern has no ceiling based on outlet size. A 500-follower account embeds a clip the same way Breaking911 does. A 50M-follower account does the same. The content earns placement through performance, not deals or ad spend. As geopolitical events accelerate and PsyopAnime's library deepens, more outlets covering more events will find existing content that fits the story they're covering. The embedded flywheel doesn't require PsyopAnime to do anything except keep producing. The internet does the distribution. [@MarioNawfal](https://x.com/@MarioNawfal) has embedded their content twice — [Trump SOTU coverage](https://x.com/MarioNawfal/status/2026844690968985792) reaching 167K views and [Iran rescue coverage](https://x.com/MarioNawfal/status/2040933502317650050) reaching 152K. [@dom\_lucre](https://x.com/@dom_lucre) framed PsyopAnime as "[the US turned into anime](https://x.com/dom_lucre/status/2027032376572858853)" with 201K views. [@beffjezos](https://x.com/@beffjezos) [embedded a news cycle clip](https://x.com/beffjezos/status/2027652139087212560) with 55K views. [Infowars ran the content](https://x.com/infowars/status/2030083508794704020?s=20). None of these required outreach. All of them reinforced the same conclusion: this is what breaking news looks like when it's formatted for the people who actually run the internet. ## The Edge That Compounds With Every News Cycle [#the-edge-that-compounds-with-every-news-cycle] Every major media operation has a distribution advantage. PsyopAnime's is unusual because it gets stronger every time the world produces a story worth covering. The core structural advantage is timing. Traditional studios cannot produce high-quality content in real time. The barrier isn't just technical — it's organizational. A traditional studio has approvals, legal review, compliance processes. PsyopAnime has a founding director, AI tools, and a community that amplifies on sight. When something breaks at 6am, PsyopAnime can post a cinematic anime short by 8am or even earlier. The distribution network is the second edge. [@HotForMoot](https://x.com/@HotForMoot)'s quote tweet — "[he did in fact, send it all](https://x.com/beffjezos/status/2027652139087212560)" — reached 1.52M views and 17.8K likes. [@Babygravy9](https://x.com/@Babygravy9) independently [quoted](https://x.com/beffjezos/status/2027652139087212560) the same clip for 459K views and 10.2K likes. These are organic pickups from credible accounts with no financial incentive to share. The content earns placement. The Elon dynamic is its own category. His follow in January 2026 created the first major upside movement. A PsyopAnime-adjacent clip subsequently [reached 35M views on his account](https://x.com/elonmusk/status/2031228289998795237) — that's not a follow-related bounce, that's the platform's owner implicitly endorsing the format. His smart followers list for [@PsyopAnime](https://x.com/@PsyopAnime) includes toly, Balaji, [@pmarca](https://x.com/@pmarca), and Nic Carter. When the people who built Solana, invested in crypto at its foundational layer, and defined web3 culture, are paying attention to the same account, that's a signal about where smart money's attention is pointing. Aiden's director credentials matter more over time, not less. As AI video tools proliferate and more accounts attempt the same format, style consistency becomes the differentiator. Anyone can prompt WonderCanvas. Only a director with One Piece credits can maintain character continuity, emotional depth, and cinematographic consistency across 50+ clips at production speed. The AI tools are a commodity. The directing eye is not replicable. ## The Raise and What It Signals [#the-raise-and-what-it-signals] In February 2026, PsyopAnime [publicly detailed their studio expansion plans and funding model](https://x.com/PsyopAnime/status/2028941532946968951?s=20) — token fees combined with community support fuel the scaling from solo operation to full studio. This is not a VC round. There's no cap table, no preferred shares, no liquidation preference sitting above token holders. The funding mechanism is the community itself, which means incentives run in one direction: output quality drives token value, which drives studio capacity, which drives output quality. A traditional media company would raise a Series A at this stage and spend the next 18 months in board meetings justifying headcount. PsyopAnime hires when the product demands it, using capital that flows directly from community conviction. The scaling trajectory confirms execution: zero-budget solo operation in early 2026, multiple full-time employees by April, professional director talent contracted in, and live broadcast infrastructure operational. That's not a studio raising money and building toward something. That's a studio that built something and is now raising to accelerate it. The distinction matters for timing. ## Market Opportunity [#market-opportunity] The market PsyopAnime is building into is not "crypto meme coins." That framing undersells it by several orders of magnitude. The actual market is digital news media — roughly $27B in annual global revenue and structurally losing the attention of everyone under 35. Short-form video has already demonstrated the format shift: TikTok's news-related content reaches more 18–24 year olds in the US than any traditional outlet. YouTube news channels generate billions of views monthly. The question isn't whether there's a market for video-native news. It's those who capture the segment that want cinematic, narratively rich content rather than talking-head clips. PsyopAnime's addressable segment sits at the intersection of geopolitics-engaged audiences and anime-native culture — young, global, internet-first. Conservative estimates put anime viewership above 500M globally. That demographic is politically engaged, underserved by current media formats, and demonstrably responsive to PsyopAnime's output. The channel built its audience in 90 days on a relatively small budget. That's product-market fit, not luck. The growth drivers are structural. AI video generation improves at a pace that makes real-time production more viable every month — the studio's live tool testing process ensures it captures each wave of improvement before competitors know the tool exists. Geopolitical instability is producing an accelerating stream of content-worthy events. Every conflict, every hearing, every policy shift is a production opportunity. The WW3 series — Venezuela, Iran, Episode 3 — generated over 1M views on YouTube without promotional spend. The expansion path is a live broadcast network. The [psyopanime.xyz](https://psyopanime.xyz/) infrastructure with live trackers and broadcast framing is already operational. That's not a content account — that's a media platform. Adjacent verticals are wide open: sports, finance, entertainment, political commentary beyond geopolitics. Each new vertical multiplies content surface area without requiring a new audience. A studio with this distribution density, this production velocity, and this level of cultural resonance is not a $2.9M asset. The market cap reflects the current narrative discount on an early-stage culture play. It does not reflect what this becomes when a generation that grew up on anime is the primary news-consuming demographic on the planet. ## Project Valuation [#project-valuation] Valuation for cultural tokens and content studios requires comparables, not revenue multiples. No direct comp exists, but the proxy landscape is instructive. [@joecoin\_](https://x.com/@joecoin_), at a comparable stage — sub-$15M market cap, confirmed KOL follows, consistent virality — reached a $50M–$70M market cap as the cultural narrative solidified. That was the conservative outcome for a brand with a clear aesthetic identity and holders who came back after every correction. PsyopAnime has a similar polished content strategy, a professional director, a live studio, ongoing creative output that major news accounts are using without being asked, and a raise underway to accelerate it. The current market cap is approximately . The ATH was $27M — driven by a single catalyst, before the studio had employees, before YouTube had 62K subscribers, before Breaking911 and Middle East Observer were embedding clips, before the live broadcast platform existed. All of that now exists. The token hasn't re-rated to reflect any of it. FDV vs. circulating supply: clean. Fair launch via [pump.fun](https://pump.fun/), no VC allocation, no team cliff, no private round overhang. What capital flows into the operation comes from token fees and community — transparent, verifiable, and aligned. Conservative scenario: cultural narrative solidifies, studio scales, PsyopAnime becomes the recognizable default for AI-native anime news. That's a $200M–$500M market cap outcome — a category-defining media brand that built its distribution through pure performance. Upside scenario: a sustained viral run, a platform partnership, or an Elon repost reprices the token ahead of narrative, and the market starts pricing the terminal media company case. At that point, the conversation isn't about hundreds of millions — it's about billions. The risk/reward at $2.9M reflects neither outcome. ## Tokenomics [#tokenomics] [$PSYOPANIME](https://x.com/search?q=%24PSYOPANIME\&src=cashtag_click) is a pure utility-alignment token. Its economic function is direct: transaction fees from trading volume flow back to fund studio operations. The founder's wallet is publicly disclosed — a transparency signal that distinguishes this from anonymous team launches. The supply structure is clean. Fair launch via [pump.fun](https://pump.fun/) — no pre-mine, no VC allocation, no cliff unlocks, no private round overhang. Circulating supply reflects actual market participants. This is the correct model for a token that functions as a cultural alignment mechanism: holder interests are structurally aligned with studio success because the studio's output is what drives the token's cultural relevance. Demand for the token is narrative and attention-driven. As studio output reaches new audiences — new embeds, new viral clips, new KOL exposure — new participants enter the ecosystem. Volume drives fees. Fees fund production. Production generates virality. The loop is self-funding and auditable. ## The Team [#the-team] **Aiden Guo (**[@aidenguoai](https://x.com/@aidenguoai) **)** — Professional anime director. Credits include One Piece #1024 and Dandakan #4. Founded PsyopAnime and serves as creative director across all production. Publicly doxxed, wallet disclosed in [community bio](https://x.com/i/communities/2010866445803012309). By April 2026, the studio had multiple full-time employees and contracted professional director talent. Hires were announced publicly on X. The creative direction, aesthetic identity, and production standard originate from Aiden — and he has publicly committed to this as a long-term cultural movement, not a short-term token play. The solo-to-team trajectory in 90 days is the most underappreciated signal in this thesis. It demonstrates execution velocity and a founder who treats the token as infrastructure, not exit liquidity. ## External Signals [#external-signals] * [@PsyopAnime](https://x.com/@PsyopAnime) — This is crazy. Didn't expect to blow up like this from 400 followers. — **1.4M views** [View Tweet](https://x.com/PsyopAnime/status/1996640003745894407) * [@PsyopAnime](https://x.com/@PsyopAnime) — The internet made this possible. Thanks to that we're only going to get bigger from here. — **984K views** [View Tweet](https://x.com/PsyopAnime/status/2011122540148584950) * [@PsyopAnime](https://x.com/@PsyopAnime) — "I get my news from psyopanime" — **892K views** [View Tweet](https://x.com/PsyopAnime/status/2013369656539574729) * [@PsyopAnime](https://x.com/@PsyopAnime) — "no kings" — **746K views** [View Tweet](https://x.com/PsyopAnime/status/2038113738205577371?s=20) * [@PsyopAnime](https://x.com/@PsyopAnime) — "The gaslighting is crazy" — **626K views** [View Tweet](https://x.com/PsyopAnime/status/2029267645707796640) * [@PsyopAnime](https://x.com/@PsyopAnime) — Still waiting for the mainstream press to finally acknowledge what's been happening in Iran the last month — **351K views** [View Tweet](https://x.com/PsyopAnime/status/2028154224668704773) * [@PsyopAnime](https://x.com/@PsyopAnime) — Bitcoin crash anime — **319K views** [View Tweet](https://x.com/PsyopAnime/status/2019548484001755446) * [@PsyopAnime](https://x.com/@PsyopAnime) — A new challenger appears! — **183K views** [View Tweet](https://x.com/PsyopAnime/status/2009846589896945974) * [@PsyopAnime](https://x.com/@PsyopAnime) — Iran protests quote-reply — **244K views** [View Tweet](https://x.com/PsyopAnime/status/2010006573364748497) **News Outlets & Major Accounts** * [@MarioNawfal](https://x.com/@MarioNawfal) — Trump SOTU anime embed — **167K views** [View Tweet](https://x.com/MarioNawfal/status/2026844690968985792) * [@MarioNawfal](https://x.com/@MarioNawfal) — Iran rescue anime embed — **152K views** [View Tweet](https://x.com/MarioNawfal/status/2040933502317650050) * [@Middle](https://x.com/@Middle) **East Observer** — Clip as primary news source — **165K views** [View Tweet](https://x.com/ME_Observer_/status/2013415711079633137) * [@infowars](https://x.com/@infowars) — Organic content embed — **29.7K views** [View Tweet](https://x.com/infowars/status/2030083508794704020) **Other Notable Quotes** * [@OwenShroyer1776](https://x.com/@OwenShroyer1776) — "The kids are anime mogging Pam Bondi" — **1.9M views** [View Tweet](https://x.com/OwenShroyer1776/status/2021806207862751427?s=20) * **@**[MyLordBebo](https://x.com/MyLordBebo) — "lmao" — **309K views** [View Tweet](https://x.com/MyLordBebo/status/2022195200895123598?s=20) * [@Babygravy9](https://x.com/@Babygravy9) — "Send it all" — **459K views** [View Tweet](https://x.com/Babygravy9/status/2028060429688176784) * [@BoLoudon](https://x.com/BoLoudon/status/2028999600321777867?s=20) — "🚨BREAKING: President Trump's Iran operation has been turned into an Anime animation and is going viral." — **371K views** [View Tweet](https://x.com/BoLoudon/status/2028999600321777867?s=20) * [@Rothmus](https://x.com/@Rothmus) — "10/10 accou" **— 327K views** [View Tweet](https://x.com/Rothmus/status/2022175913417576862?s=20) * **@**[Grummz](https://x.com/Grummz) — "You have to see this…it’s ai but not slop. It’s so good. Anime is gonna change forever." — **665K views** [View Tweet](https://x.com/Grummz/status/1996775505081913846?s=20) * [@DonutOperator](https://x.com/DonutOperator) — "literally what happened" — **288K views** [View Tweet](https://x.com/DonutOperator/status/2031093022071332891?s=20) * [@dom\_lucre](https://x.com/@dom_lucre) — "US turned into anime" SOTU coverage — **201K views** [View Tweet](https://x.com/dom_lucre/status/2027032376572858853) * **@**[JackPosobiec](https://x.com/JackPosobiec) — "Magnificent" — **119K views** [View Tweet](https://x.com/JackPosobiec/status/2026627017358110746?s=20) * [@NiohBerg](https://x.com/@NiohBerg) — "You should unironically get your news from [@PsyopAnime](https://x.com/@PsyopAnime), it's more factual and entertaining than legacy media." — **68K views** [View Tweet](https://x.com/NiohBerg/status/2031064746976268744) * [@8teAPi](https://x.com/@8teAPi) — “Somali Scam King” — **72K views** [View Tweet](https://x.com/8teAPi/status/2007219210804703414) * [@SarahisCensored](https://x.com/SarahisCensored) — "If you’re not following [@PsyopAnime](https://x.com/PsyopAnime) you’re missing out." — **59K views** [View Tweet](https://x.com/SarahisCensored/status/2038689080645464183?s=20) * [@beffjezos](https://x.com/@beffjezos) — News cycle anime embed — **55K views** [View Tweet](https://x.com/beffjezos/status/2027652139087212560) * [@Excellion](https://x.com/@Excellion) **(Samson Mow)** — Saylor anime retweet — **43K views** [View Tweet](https://x.com/Excellion/status/2026468909482914181) * [@tkatsumi06j](https://x.com/@tkatsumi06j) — Japanese dub ("sick of these people") — **43K views** [View Tweet](https://x.com/tkatsumi06j/status/2021815729805570550) * [@AutismCapital](https://x.com/@AutismCapital) — Epstein Files embed — **48K views** [View Tweet](https://x.com/AutismCapital/status/2019295698618114276) * [@NRv\_gg](https://x.com/@NRv_gg) — Core bull thesis — most-quoted external take — **53K views** [View Tweet](https://x.com/NRv_gg/status/2016260672238031043) ## Trade Setup [#trade-setup] [$PSYOPANIME](https://x.com/search?q=%24PSYOPANIME\&src=cashtag_click) launched on [pump.fun](https://pump.fun/) around January 11, 2026. The Elon follow catalyst hit mid-January, producing a move to . Standard distribution followed as early participants took profit. As of April 2026, the token trades around $2.9M — an 89% drawdown from the ATH. What that number doesn't capture: the token has weathered multiple significant pullbacks across 3+ months and recovered each time. This is not a token that died after its first correction. That pattern of survival and return is a tell about holder conviction. The chart is 90+ days old. The post-launch distribution phase is almost complete. What remains is a market cap pricing in the median outcome — retraced pump, no further narrative — while the studio has done nothing but grow since the ATH. More employees, more content, confirmed news outlet embeds, live broadcast infrastructure, 62K YouTube subscribers with videos clearing 50K-600K views. None of that is in the price. This is a smart accumulation range. Given the lower market cap, a measured scaling strategy outperforms aggressive entries — build a position deliberately across the range rather than chasing catalysts. **Near-Term (0–6 months):** Continued major geopolitical events generating viral clips, further high-profile KOL embeds, live broadcast platform traction at [psyopanime.xyz](https://psyopanime.xyz/), and studio raise execution. Any Elon repost — distinct from his existing follow — is a binary catalyst with no warning. **Medium-Term (6–24 months):** Studio scales to multiple verticals — sports, finance, entertainment. Embed flywheel matures across larger media organizations. Token reprices to reflect media company fundamentals rather than meme token framing. Target range: $200M–$500M. **Long-Term (2+ years):** If PsyopAnime becomes the default anime news network for a generation that runs the internet, the valuation case crosses into billion-dollar territory. The terminal vision is a live global broadcast network — [psyopanime.xyz](https://psyopanime.xyz/) as the destination, not just the X account. Watch studio headcount, news outlet embed frequency at scale, and whether the format gets adopted by any major media company as a content partnership. ## The Risks [#the-risks] **Early-stage volatility.** The token has survived multiple pullbacks, but at $2.9M market cap, a single coordinated exit can cause a rapid and significant downside movement. This is the structural reality of small-cap tokens and the reason a scaled entry strategy outperforms aggressive positioning. Size accordingly. **AI content commoditization.** WonderCanvas, Seedance, and Grok Imagine are available to any creator. As quality improves across the board, the production quality moat narrows for the average account. PsyopAnime's counter is Aiden's directing eye — not replicable — and an established distribution network that took years of relationship-building to assemble. The risk is real, the offset is structural. **Founder dependency.** Aiden Guo is the creative director and the primary quality guarantor. The studio is scaling, but the aesthetic vision and production standard flow from his involvement. A departure or reduced capacity would materially affect output quality. No indication that this risk is imminent, but key-man risk is always present in a founder-led early-stage operation. **Platform moderation risk.** The explicit counter-media, psyop-exposing ethos that makes the content compelling also creates deplatforming risk. A major action on X or YouTube would break the distribution flywheel. The decentralized token model provides resilience at the financial layer, but the content lives on centralized platforms. **Market structure risk.** [$PSYOPANIME](https://x.com/search?q=%24PSYOPANIME\&src=cashtag_click) is a Solana-native token at a low market cap. In a broad risk-off environment — macro downturn, crypto bear market, Solana-specific contagion — correlation to the broader market dominates any fundamental thesis. Cultural moats don't hold during liquidity crises. **No recurring revenue floor.** Token value is entirely narrative and attention-driven. If virality plateaus for a sustained period, there's no fee revenue or TVL providing a fundamental floor. The risk is real but mitigated by the accelerating pace of global events and the studio's expanding production capacity. The resilience case: PsyopAnime has demonstrated viral production independent of any crypto-native catalyst, across multiple pullback cycles, without any sustained promotional push. The distribution network is real. The founder's credentials are verifiable. A team that shipped consistent 50K-3M+ views content in 90 days on a low budget has already proved the hardest part of the thesis. The format works. ## Conclusion [#conclusion] Three things are converging that rarely converge at this stage: a format the internet was always going to build, a founder technically credentialed enough to build it properly, and a community that has proved the distribution model works — repeatedly, across multiple corrections, without needing to be told to come back. AI video tools are in a quality inflection window — good enough to produce cinematic output at speed, not yet commoditized enough for every account to replicate the PsyopAnime aesthetic identity. The studio is building its distribution network and cultural vocabulary while the first-mover advantage in AI-native anime news is still available. The tool iteration process PsyopAnime runs — live testing WonderCanvas, Seedance, Grok Imagine as each ships — means every improvement in the AI video landscape extends their lead rather than closing it. If the thesis is right — if PsyopAnime becomes the default anime news network for the generation that runs internet culture — a $500M market cap is the conservative scenario. That's a substantial multiple from current levels on a token with no VC overhang, a doxxed founder, and a studio already operating at viral scale. The path to a billion-dollar valuation runs through what [psyopanime.xyz](https://psyopanime.xyz/) becomes: not a link in a bio, but the live broadcast destination for a global audience that stopped trusting legacy media and started trusting cinematic anime shorts made by a professional director with AI tools. Watch studio headcount, news outlet embed frequency, and live broadcast platform traction. Those are the three signals that separate a persistent media brand from a one-cycle meme. The token has already survived enough pullbacks to put the second scenario to rest. The architecture of this thing — AI tooling, director credentials, token-funded studio, no VC overhang, community-driven raise — was built to last. * **X**: [https://x.com/PsyopAnime](https://x.com/PsyopAnime) * **Website**: [https://psyopanime.xyz/](https://psyopanime.xyz/) * **Community**: [https://x.com/i/communities/2009788573893943463](https://x.com/i/communities/2009788573893943463) * **CA**: 2nP9yKQNSGQy851iyawDvBkzkK2R2aqKArQCKc2gpump This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Real Finance (/research/realfinance) # Real Finance [#real-finance] Image ## The System That Runs on Paper [#the-system-that-runs-on-paper] Every time a large asset changes hands — a bond, a real estate portfolio, a private credit instrument — the same sequence plays out. Lawyers verify ownership. Banks confirm reserves. Auditors sign off on valuations. Custodians hold the paper. Each party runs its own records, cross-checks them against every other party's records, and charges for the privilege. The asset moves in days or weeks. The paperwork moves faster, but only barely. This is not a technology problem. It is a trust architecture problem. Every intermediary in that chain exists because the layer beneath it cannot be trusted directly. Clearinghouses exist because banks do not trust each other's settlement records. Custodians exist because ownership cannot be self-reported. Auditors exist because financial data cannot be verified in real time by the counterparties relying on it. The system did not evolve badly — it evolved logically, adding one verification layer at a time, until the cost of maintaining trust exceeded the cost of the underlying transactions in many cases. The global debt market surpassed $353 trillion by 2026. That market runs on a stack of intermediaries that would be unrecognizable to any technologist but is invisible to everyone who has worked inside it long enough. You do not notice the friction until you step outside the system and look back at it. Image That is exactly what happened in a London meeting room in 2017, where a former ECB official and $1.2 billion fund manager spent three weeks structuring a guarantee scheme that involved four institutions, dozens of people manually cross-referencing the same data, and a timeline that had nothing to do with the underlying asset and everything to do with the paperwork surrounding it. The realization that followed was not that the process was inefficient. It was that the entire structure existed only because there was no shared system that all parties could trust simultaneously. ## What Access Does Not Solve [#what-access-does-not-solve] The first wave of blockchain-based tokenization made a good bet: that access was the problem. Fractional ownership, 24/7 trading, T+0 settlement. The bet was not wrong — those properties matter. But access is not why institutional capital has stayed on the sidelines. Large allocators have three requirements that no access-layer product resolves. * First: evaluation. How does an allocator confirm the underlying asset is what the issuer claims? * Second: custody. Where does the asset legally sit, and under which framework? * Third: fraud prevention. What stops the same asset from being tokenized on two chains and sold twice to separate buyers? Ethereum and Solana answer none of these. A token on a public chain is only as credible as the off-chain process that created it — and that process is invisible to the chain itself. Image The platforms that have built RWA products on existing chains have largely treated tokenization as a minting exercise. Upload a document, deploy a contract, issue a token. That process digitizes an asset. It does not make the asset verifiable. For a family office to allocate $10 million to a tokenized private credit instrument, they need verifiable provenance, ongoing credit assessment, and a recovery mechanism if the underlying defaults. None of the existing platforms provides that at the protocol level. They provide the token and outsource everything that matters. ## The Layer That Cannot Be Bolted On [#the-layer-that-cannot-be-bolted-on] The problem is not that existing platforms lack features. It is that their architecture makes the missing features structurally impossible to add. When you separate the financial intelligence layer from the settlement layer, the gap is permanent. The token moves on-chain. The risk assessment lives in a PDF. The insurance policy sits in a legal agreement. The credit score gets updated quarterly by a third party with no stake in whether the chain reflects reality. For a retail DeFi user making directional bets, that gap is tolerable. For an asset manager running a fixed-income mandate, it is disqualifying. The liability exposure is too large. The audit requirements are too strict. No compliance officer signs off on a system where the most important financial data lives outside the instrument itself. Image Centrifuge, Maple Finance, and Goldfinch all ran into this ceiling at scale. When loans went bad on Maple in 2022 — over $52 million in defaults from Orthogonal Trading — the recovery looked like traditional collections. Credit assessment lived off-chain. Collections lived off-chain. Dispute resolution lived off-chain. The chain was a ledger, not a financial system. The blockchain added zero efficiency at the point where it mattered most. You cannot add financial logic onto a general-purpose chain after the fact. Ethereum was not designed to hold insurance policy records. Cosmos-based chains were not built to enforce probability-of-default scoring. Compliance infrastructure built on top of a neutral settlement layer creates a permanent gap — a place where the on-chain record and the legal reality diverge, becoming the counterparty's problem at exactly the wrong moment. The only solution is a chain where the financial logic is native to the consensus layer from the first block. That infrastructure did not exist until it was built from scratch. ## The Financial System as Protocol [#the-financial-system-as-protocol] Real Finance is a sovereign, EVM-compatible Layer 1 blockchain built for the tokenization, risk assessment, and lifecycle management of real-world assets — with insurance, credit scoring, and institutional custody embedded at the protocol layer. The network runs two classes of validators. Normal validators maintain consensus using Proof-of-Stake. Business Function Validators — licensed tokenization companies, risk scoring entities, and insurance providers — must stake [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) proportional to their activity on the chain. If a tokenizer misrepresents an asset or an insurer fails to honor a claim, their stake is slashed. That is not a policy rule. It is a protocol-level enforcement mechanism. Every piece of financial data these entities submit carries real capital behind it. ```text Standard RWA Model: Real Finance Model: Token Contract (on-chain) Token Contract (on-chain) | | PDF Document (off-chain) Embedded Metadata: | - PD Score (on-chain, staked) Legal Agreement (off-chain) - Insurance Policy (on-chain, staked) | - Risk Grade A–F (on-chain, staked) Audit Firm (quarterly, off-chain) | Business Validator stakes → consensus = one source of truth, one chain ``` Every onboarded asset carries an embedded risk grade from A to F and an insurance status queryable directly through the chain via CLI, REST, or gRPC. Grade A assets carry 100% principal and cash flow coverage. Grade B assets have at least 75% of cash flows insured. That coverage is a protocol-level record, underwritten by an insurance entity that has posted capital it stands to lose if the claim is disputed. The Disaster Recovery Fund closes the final gap. If an insurer defaults, asset holders receive Network Debt Tokens matching their realized losses, redeemable monthly against the DRF at 1:1. The fund is financed by redirecting a portion of inflation rewards from business validators — no net new issuance, no separate bailout mechanism. The recovery logic is built into the economic design before the first asset goes live. Serious capital does not move on opportunity alone. It moves when the downside is defined. ## The Edge That Does Not Transfer [#the-edge-that-does-not-transfer] Real Finance's position is architectural, not executional — and that distinction is what makes it durable. A competitor building on Ethereum cannot replicate this without constructing its own sovereign chain. If they build their own chain, they face the same cold-start problem Real Finance has already cleared: sourcing validators, attracting licensed financial institutions, structuring legal frameworks across jurisdictions, and doing all of it before a single asset goes live. That process took years. The lead cannot be bought or forked. The inclusion of Wiener Privatbank SE as a Business Function Validator is where the architecture becomes a distributional advantage. A bank that validates and settles directly on the chain has rebuilt its operational workflow around the network. That transition does not reverse. Its presence signals to every other European allocator evaluating the space that the legal and custody framework is already in place — not aspirational. Phase 1 of the Wiener Privatbank integration targets approximately $50 million in on-chain assets. The mainnet-year goal is $500 million in tokenized assets across the network. Real Finance launched the mainnet with 20 million euros in assets already prepared for migration. The infrastructure is live, the pipeline is sourced, and the counterparty structure is confirmed before most of the sector has a working mainnet. Nimbus Capital, managing $1.4 billion in real estate assets, anchored the $29 million raise alongside Magnus Fund and Frekaz Group. These are asset managers who need a destination for institutional-grade tokenized assets — not financial sponsors looking for a multiple. The capital and the pipeline arrived together. ## Market Opportunity [#market-opportunity] The global debt market at $353 trillion is a ceiling, not a target. The near-term opportunity is the fraction moving on-chain over the next five to seven years, driven by three forces operating at the same time. Institutional adoption has passed proof-of-concept. BlackRock's tokenized money market fund, BUIDL, crossed $1 billion in assets under management within months of launch. Tokenized money market funds grew 10x between 2023 and 2025. Franklin Templeton, WisdomTree, and Fidelity are all running live products. The direction of institutional capital is not ambiguous. The question is which infrastructure layer captures the settlement fees. Settlement cost has become a competitive issue at scale. Traditional clearing infrastructure carries expenses that grow with volume. T+0 settlement and programmable cash flows are not features for institutional allocators — they reduce operational overhead on products running at thin margins. Tokenized private credit and structured products with automated settlement logic save money in ways that accrue directly to the issuer's economics. Image The regulatory window in Europe is opening. The EU's MiCA framework, combined with Wiener Privatbank's existing relationships across European markets, gives Real Finance a credible compliance path that U.S.-domiciled competitors cannot easily match. A chain with a licensed European bank in its validator set is structurally different from a chain seeking regulatory approval after the fact. European allocators have been waiting for a public blockchain that satisfies their legal requirements. Furthermore, if Real Finance captures 0.1% of the global private credit market — estimated at $1.7 trillion — that is $1.7 billion in tokenized assets generating fee flow for [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) holders at valuations that currently price none of it. ## Valuation [#valuation] Real Finance completed its TGE in late April 2026. Market cap sits at $5.77 million. The token has $3.63 million in 24-hour volume across Uniswap, KuCoin, MEXC, and Kraken. At $115.55 million FDV, Real Finance is priced as if the institutional pipeline it has already confirmed will produce nothing. The Wiener Privatbank relationship targets $500 million in tokenized assets within the first operating year. If that pipeline generates annualized fee revenue at a conservative 0.5% rate — well below typical institutional structuring fees — that implies $2.5 million in annualized protocol revenue. At a 20x revenue multiple, standard for infrastructure in early adoption, that supports a $50 million market cap on the circulating float alone. The current FDV is pricing pipeline failure, not any version of execution. The closest comparable is Centrifuge, which reached a $400 million FDV during its growth phase with simpler architecture, less institutional traction, and no embedded insurance or bank-validator model. Real Finance's design argues for a premium to that baseline — conditional on the pipeline executing. ## Tokenomics [#tokenomics] **Supply** Total supply is 1,000,000,000 [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click). Circulating supply at launch is 43,376,451 tokens, representing 4.34% of total. The FDV-to-market cap ratio of approximately 20x is the single most important number for position sizing. The vast majority of the supply has not entered the market. Buyers entering now do so before the team and investor vesting creates consistent sell pressure. That window is real. So is the dilution risk on the other side of it. **Allocation** Treasury and Community hold 52% of the total supply. Seed Investors hold 16.5%. Team holds 15%. Liquidity receives 10%. The remaining 6.5% covers other categories. Team and investor allocations carry 6-to-12-month cliffs followed by linear monthly vesting over 24 to 36 months. First significant seed investor unlocks arrive in Q4 2026 at the earliest. **Economic Design** [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) operates across three functions: * Transaction fuel: every tokenization event, asset transfer, and contract execution requires [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) for gas. * Validator skin-in-the-game: Business Function Validators stake [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) proportional to their activity, with slashing as the enforcement mechanism. * Governance: staked [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) provides voting power over protocol upgrades and parameter changes. Inflation starts at 5% in year one and decreases by 0.5% annually until reaching a 1% floor. Block rewards of approximately 10 [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) per block produces roughly 52.5 million tokens annually, split 50/50 between normal validators and business function validators. The economic interest of insurers, tokenizers, and risk assessors is tied directly to network activity. Remaining inflation is distributed to stakers (70%), the Ecosystem Fund (20%), and community incentives (10%). ## The Team [#the-team] **Ivo Grigorov (Co-founder & CEO).** Holds an honors degree in Banking and Finance from a London institution, worked at the European Central Bank, and managed a $1.2 billion Fund of Funds before founding Real Finance. The 2017 guarantee scheme structuring moment that started the project came from someone who had spent years inside the institutions he set out to replace. **Valentin Dimitrov (Co-founder & COO).** Former fund manager with €600 million AUM and a background in European financial policy and capital markets. Structuring a licensed bank as a network validator required legal, regulatory, and financial fluency that most blockchain teams do not carry. **Hristo Piyankov (Lead Economist).** Led tokenomics design for over 200 projects raising more than $1 billion combined. The [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) economic model — inflation decay schedule, dual-validator reward split, DRF funding through redirected rewards — reflects design depth unusual at this stage. ## External Signals [#external-signals] **Armors Security Audit.** First external audit of REAL's on-chain infrastructure returned 0 critical, 0 high, 0 medium, and 0 low findings. Marked Technically Verified. **Start In Block Top 100.** Selected from 1,000+ startups at Paris Block Week 2026. Nominated in the Top 10 for the RWA category. Finalists pitched at the Louvre on April 16. **RedStone Oracle Integration.** Partnership with RedStone for real-time price feeds on tokenized assets. RedStone is one of the primary oracle providers across institutional DeFi. **RWA Inc. Partnership.** Strategic collaboration covering tokenized asset issuance on REAL, investor onboarding, post-issuance lifecycle support, and AI-powered governance automation. **Token Narratives Podcast (Ep. 99).** REAL's strategic advisor Pauli Speaks joined hosts Graham Stone and Alex Richardson to discuss RWA infrastructure, institutional adoption, and the [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) TGE. May 4, 2026. **When Shift Happens Podcast.** CEO Ivo Grigorov joined host Kevin for an in-depth discussion on the founding thesis, institutional trust architecture, and the 2030 vision for clearing house displacement. \[[source](https://www.youtube.com/watch?v=c1432pMNViU)] ## Trade Setup [#trade-setup] **Market Snapshot** ```text Current Phase: Post-TGE early price discovery Price: $0.1156 (May 13, 2026) ATH: $0.1345 (May 12, 2026) All-Time Low: $0.04307 (Apr 30, 2026) 24h Range: $0.09957 – $0.1345 7d Range: $0.0744 – $0.1345 24h Volume: $3.63M Exchanges: Uniswap, KuCoin, MEXC, Kraken ``` [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) launched April 30 and ran 169% in 48 hours — from an all-time low of $0.04307 on listing day to an all-time high of $0.1158 on May 1. Simultaneous listings across OKX, KuCoin, Kraken, and MEXC created bid-side momentum that outpaced natural sell pressure from early holders. Volume expansion over the past 24 hours, with price hitting new ATH, puts this in a pure post-TGE price discovery. **Scenario Analysis** ```text | Scenario | Assumptions | Target FDV | Multiple from Current | | -------- | ----------------------------------------------------------------------------------------- | ---------- | --------------------- | | Bear | Pipeline fails, no institutional asset volume, unlock pressure dominates | $30–50M | ~0.26–0.43x | | Base | $100–200M in tokenized assets within 12 months, KuCoin/Kraken liquidity deepens | $200–400M | ~1.73–3.46x | | Bull | $500M+ tokenized assets, second bank validator confirmed, $ASSET listed on top-3 exchange | $800M–1.5B | ~6.92–12.9x | ``` **Catalysts** The highest-priority event is Wiener Privatbank Phase 1 close — on-chain confirmation of the first $50 million tranche. That is the proof-of-pipeline moment. A single on-chain transaction record confirming Phase 1 moves the institutional pipeline from stated intent to verifiable fact, and changes the FDV conversation entirely. Second is the REUR stablecoin launch. Without a native euro-pegged unit of account, institutional interbank deals and structured products cannot settle natively on REAL. The REUR is the monetary layer that makes the chain self-contained for European institutional finance. It is described as a "stage two" development in the source materials — the logical next milestone after mainnet stability is proven. Third is any additional licensed institution joining as a Business Function Validator. One bank establishes that the model works. Two establishes that it scales. That transition from proof-of-concept to repeatable pattern is where the FDV multiple expands. **Future Outlook** **Near-term (0–12 months).** Wiener Privatbank Phase 1 close ($50M on-chain), REUR stablecoin launch, first meaningful protocol fee data. The gap between the $5.77M market cap and the $29M raised makes this one of the more asymmetric early-stage setups in the current cycle. That gap closes in one direction or the other within 12 months. Simultaneous exchange listings and the Wiener Privatbank announcement, all arriving in the same calendar week was deliberate narrative stacking — the question is whether on-chain volume follows. **Medium-term (1–3 years).** [$500M+](https://x.com/search?q=%24500M%2B\&src=cashtag_click) in tokenized assets, a second institutional validator, liquidity across Cosmos IBC-connected chains via the Kima Network partnership. The RWA Foundation membership alongside the Byzanlink, Stobox, and Toto Finance collaborations create an asset sourcing network that most Layer 1s lack entirely. **Long-term (3+ years).** By 2030, the stated vision is that traditional clearing houses become obsolete for European mid-market credit instruments because on-chain settlement is faster, cheaper, and verifiably compliant. If that directional claim is even partially correct, the network holding the institutional relationships and the compliant infrastructure captures the fee flow that currently goes to clearinghouses. Price holds above the launch-day low of $0.04307 as long as the pipeline narrative remains intact. A break below that level on meaningful volume is the invalidation signal — it would mean the post-listing bid exhausted without natural demand forming beneath it. ## Key Risks [#key-risks] **Supply Overhang.** Only 4.34% of the total [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) supply is circulating. Seed investor cliff periods of 6 months and team vesting over 24–36 months means unlock events will recur through 2027–2028. If network activity does not scale ahead of those events, sell pressure will compress price regardless of fundamental progress. Q4 2026 is the first significant risk window. **Pipeline Execution.** The $500M tokenized asset target within year one is ambitious. Institutional asset migration routinely requires 12–24 months longer than projected due to legal preparation, regulatory coordination, and counterparty sign-off. Real Finance has sourced the pipeline. It has not confirmed delivery. **Single Validator Concentration.** Wiener Privatbank is the only confirmed institutional validator. If that relationship deteriorates, the trust architecture loses its anchor. **Competitive Displacement.** BlackRock, Franklin Templeton, and Fidelity are all building within the tokenized asset category. A permissioned chain backed by a major custodian with established institutional distribution could capture the pipeline Real Finance is targeting without requiring a public L1. **Regulatory Reclassification.** The [$ASSET](https://x.com/search?q=%24ASSET\&src=cashtag_click) token's utility functions — staking, governance, gas — do not by themselves constitute a security under current EU frameworks. MiCA provides clarity. A reclassification event or enforcement action in a key jurisdiction would create immediate legal overhang, particularly if U.S. operations expand. The architecture cannot be replicated on an existing chain without starting from zero. The institutional relationships are not theoretical. The European regulatory environment is moving toward clarity rather than restriction. These factors do not eliminate the risks above, but they set a floor under the downside that purely speculative projects at this market cap do not have. ## Conclusion [#conclusion] The London meeting room in 2017 produced something specific: a founder who understood every layer of the system he was replacing, because he had operated inside each one. Grigorov spent years at the ECB and managing institutional capital before deciding to rebuild the infrastructure from the protocol layer up. That context shows in the architecture. Insurance is not an add-on. Credit scoring is not outsourced. Bank custody is not a partnership announcement. They are network primitives, enforced by the same consensus mechanism that validates every block. Right now, both viable alternatives have proven inadequate at scale. Permissioned chains run by major banks offer institutional trust but no secondary market and no composability. Public chains offer liquidity but cannot satisfy the legal and custody requirements that institutional allocators require. A sovereign, EVM-compatible L1 with a licensed European bank in the validator set — and an on-chain audit trail for every piece of financial data — is the only architecture that answers both objections. The question is whether Real Finance executes the pipeline it has already sourced before a well-capitalized competitor clears the same regulatory and institutional hurdles. At $110 million FDV with $29 million raised, a licensed bank as a validator, 20 million euros in assets prepared for migration, and a $500 million mainnet-year pipeline, the token is priced for failure. Centrifuge reached $400 million FDV with less infrastructure, fewer institutional partners, and no embedded insurance model. The baseline upside on execution is not speculative — it is a re-rating to what comparable infrastructure traded at with comparable traction. Watch three things. First: on-chain confirmation of the Wiener Privatbank Phase 1 tranche — the proof-of-pipeline event that moves the FDV conversation from narrative to data. Second: REUR stablecoin launch, the moment the chain becomes self-contained for European institutional finance. Third: a second institution joins the validator set. One bank is a bet on a model. Two is a market forming. * **X:** [https://x.com/RealFinOfficial](https://x.com/RealFinOfficial) * **Website:** [https://www.real.finance/](https://www.real.finance/) * **Community:** [https://t.me/RealFinanceRWA](https://t.me/RealFinanceRWA) * **CA:** 0x99e980265bf36516c442be982df1772a6ccb3233 [#UCCC](https://x.com/hashtag/UCCC?src=hashtag_click) This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Sui (/research/sui) # Sui [#sui] Image # The man who built Facebook's payment system and watched Congress kill it [#the-man-who-built-facebooks-payment-system-and-watched-congress-kill-it] In 2019, Adeniyi Abiodun was part of a small team inside Meta trying to do something no company had ever pulled off: construct a single payment rail for three billion people. Not an application. The layer underneath all applications, the foundation that would let a person in Lagos send funds to São Paulo the way they'd send a text message. They got close. The technology worked. The architecture held up under load. Then Congress called the executives in for hearings, governments threatened to revoke banking licenses, and Facebook shut the whole thing down. Abiodun left Meta. He didn't abandon the challenge. He took all the team had learned, each hard lesson about what it actually takes to develop at that magnitude, and decided to construct it again. This time without a corporation in the middle. This time on a foundation that no single regulator could kill. The fundamental insight he carried out of that experience was something most builders never get the chance to learn: designing for a billion users forces different decisions than designing for ten thousand. You cannot add parallelism later. You won't retrofit a better user experience atop a network engineered for engineers. It's wrong to assume your median user has ever heard of a private key. When size is the starting assumption, the entire mental model changes, from "how do we process transactions" to "how do we make it structurally impossible for the framework to fail under real-world load." ## The infrastructure deficit that survives each generation of platforms [#the-infrastructure-deficit-that-survives-each-generation-of-platforms] Each generation of fintech has tried to solve the same issue with a new interface. Faster applications on the same backend. Slicker UX over the same correspondent banking chain. The settlement still happens at end of day. The funds still travel through four intermediaries before they arrive. The problem isn't cosmetic. It's architectural. The payment systems that underpin worldwide finance were designed for a world where end-of-day batch processing was the technological frontier. Layering modern tools above that doesn't change what's happening underneath, it just hides the latency behind better design. Image This is the obstacle Abiodun kept running into at Meta. Each country had its own payment rail. None of them connected. To send value across borders, you had to route through correspondent banks, each taking a fee, each adding a delay, each creating a reconciliation event that might fail. The technology to move funds instantly had existed for years. The framework to do it worldwide, at volume, without trusting any single intermediary, did not. That's the challenge. And that's what he left to build. ## Object-first: The architecture that doesn't break under load [#object-first-the-architecture-that-doesnt-break-under-load] The network built from that brief is a Layer-1 network where each asset is an independent object owned by a defined address, not a field in a shared ledger that all nodes must update sequentially. On Ethereum or Solana, your USDC balance is a field inside Circle's smart contract. When you send it, the network must register that transaction in the shared sequence before processing anything else touching the same contract. On this platform, your USDC is its own object. Transactions involving different objects have no causal relationship, they run simultaneously across different cores, without queuing. The Mysticeti v2 consensus engine, launched in November 2025, delivers 390ms median finality, which is 80% lower latency than the original consensus design. For simple peer-to-peer transfers, a "fast path" bypasses consensus entirely, requiring only two round-trips to a quorum of validators. At $0.0023 per transaction with fees that stay stable under congestion, the cost structure is different from any major chain operating today. Image The theoretical ceiling is 297,000 TPS. The more instructive number is what Pilotfish autoscaling demonstrated in practice: scale the hardware eightfold and throughput scales eightfold with zero latency cost. Double the hardware, double the throughput. That's the claim Abiodun made publicly, and the architecture is built to deliver it. The Move programming language closes the loop. Created by Mysten Labs CTO Sam Blackshear at Meta, Move treats digital assets as first-class citizens with ownership enforced at the type level. An item cannot be accidentally duplicated or destroyed, the language eliminates entire categories of smart contract exploits that have drained billions from Solidity contracts. For institutions building compliant financial infrastructure on-chain, language-level safety is as important as raw throughput. ## The edge that compounds [#the-edge-that-compounds] Solana's Firedancer client launched on mainnet in late 2025, targeting sustained throughput above one million TPS. Genuine engineering. But the underlying account-based model stays, as sequential state access for shared contracts doesn't change when you add a faster validator client. What Firedancer also introduced is a second validator client running alongside the original, adding operational complexity to a network with a history of stability issues. Aptos is the closest architectural peer. Both networks use Move, both trace origins to Meta's Diem. The divergence: Sui chose the object model; Aptos retained account-based design with parallel execution bolted on top. The outcomes to date show Sui's TVL peaked 5-6x higher than Aptos' peak, with search interest running 9x Aptos. Image What neither Solana nor Aptos has built is the full vertical stack sitting above the chain: Walrus for decentralized storage (467TB stored, now the second-largest decentralized storage network by volume), DeepBook as a native central limit order book (60% lower gas than alternatives, shared liquidity infrastructure across DeFi), SuiNS for human-readable wallet addresses, and Slush Wallet, the unified experience combining zkLogin, passkeys, and token-sending via links that could be handed to a person who has never used a crypto product. Grayscale's research team noted in July 2025 that no other chain has assembled a fully integrated application suite from the base layer up the way this network has. Developer momentum backs it: Sui Overflow 2025 drew 599 project submissions from 85 countries, with $600K in prizes. Sui Overflow 2026 is already building. OpenZeppelin's smart contract library launched on Sui in March 2026, bringing Ethereum's most widely used security infrastructure to the Move environment. ## Three converging markets [#three-converging-markets] **DeFi.** TVL grew from $250 million at the start of 2024, reaching a $2.6 billion peak by October 2025, a 10x move in under two years. It has since pulled back to approximately $570 million as macro conditions compressed the broader market. The underlying activity did not disappear. Daily active addresses are up 83% year-over-year, network fees rose 268% and protocol revenue climbed 572% over the same period. Suilend, NAVI, Bluefin, and Cetus are still running. The TVL will recover before the chain gets credit for it. **Payments.** Cumulative stablecoin transfer volume crossed $1 trillion by March 2026. The network processed $111 billion in stablecoin transfers in January 2026 alone. Stablecoin market cap on-chain sits near $517 million. USDsui (Sui Dollar, issued by Bridge, a Stripe company) launched in March 2026 and is already live across Cetus, Bluefin, NAVI, Turbos, and Ferra. Erebor Bank, a U.S. national bank with an OCC charter built from the ground up without legacy systems, integrated Sui as one of the few blockchains it formally supports, enabling stablecoin deposits and withdrawals as direct banking primitives. SUI and USDC-Sui went live on RedotPay on April 21, 2026, reaching 7 million customers, 130 million merchants, and 100+ countries. SUI staking became available inside the Revolut app in March 2026, providing a fintech with 50+ million users a direct onramp to the network. **BTCFi.** Bitcoin is a $1.4 trillion asset. Less than 0.5% of it currently works in DeFi, because existing synthetic products lack the transparency institutions require. Hashi changes that. Launched on devnet in March 2026 with commitments from BitGo, Bullish, Erebor Bank, and Ledger, Hashi is a trustless, smart contract-based foundation that lets native BTC be used directly in on-chain services like institutional credit markets, BTC-backed stablecoins, and automated yield vaults, all without bridges or synthetic proxies. Wave Digital is already using it to issue secured bonds collateralized by Bitcoin, with instantaneous settlement. CF Benchmarks provides pricing. Cubist handles BTC custody movement. Soter Insure is building native BTC-denominated insurance on top. If even 1% of idle Bitcoin enters productive yield on Sui through Hashi, that's $14 billion in TVL. No other L1 has the institutional counterparty stack to make that credible. **AI agents.** The next phase of AI is not better chat. It's agents that execute, book, transact, and manage resources autonomously at machine speed. The current internet wasn't built for this. Human-centric checkout flows don't scale to millions of automated micropayments. Sui addresses this through the Agent Payments Protocol (AP2), co-developed with Google, and the x402 programmatic signaling standard. Every agentic transaction on Sui groups data, permissions, and history together, so it's always clear what an agent is authorized to touch. WaterX, a 24/7 AI-native trading engine, is building directly on the network for this reason. Visa tops out at 50,000 TPS. Agentic payments will need more. The investment case sits at the intersection of all four: a chain purpose-built for scale, with BTCFi infrastructure coming online, stablecoin payment rails that processed $1T in volume, and the first serious agentic payment architecture in crypto. ## Current Valuation [#current-valuation] **April 23, 2026:** * Price: $0.9370 * Market cap: $3.70B * FDV: \~$9.37B (10B total supply) * Circulating supply: 3,953,388,932 SUI (\~39.5% of total) * 24h trading volume: $380.7M across 84 exchanges * FDV/market cap ratio: \~2.53x * CMC rank: #26 | CoinGecko rank: #29 At a $3.70B market cap, this trades at roughly 13% of Solana's market cap and \~4% of Ethereum's circulating cap, which is notable for a chain that processed more daily transactions than Ethereum's base layer, with faster developer growth than Solana, and three regulated spot ETFs already trading. **Revenue multiple:** Grayscale Research (July 2025) reported approximately $15M in annualized network fees. Solana generated $603M in on-chain fees in 2025 (Nansen). The difference is structural, not incidental, as the $0.0023 average transaction cost is the product differentiator. At 30x P/S (sector median for high-growth early-stage L1s), the current fee run-rate implies \~$450M fair value on fees alone. That's already exceeded, meaning the market is pricing forward growth rather than current monetization. **Comparable approach:** At $3.70B market cap against $570M current TVL, Sui trades at a P/TVL ratio of \~6.5x, which is higher than Solana's current multiple but consistent with early-cycle positioning for a chain whose TVL peaked 5x higher just six months ago. If TVL recovers to its October 2025 peak of $2.6B, the same market cap implies a P/TVL of \~1.4x, below Solana's historical range during its comparable growth phase. **If the BTCFi thesis holds:** [$14B+](https://x.com/search?q=%2414B%2B\&src=cashtag_click) in potential TVL from 1% BTC activation through Hashi would re-rate the chain entirely on TVL multiples alone. ## Tokenomics [#tokenomics] Image **Next unlock:** 52,030,000 SUI (\~0.52% of total supply) on May 1, 2026. At the current price, approximately $49.7M entering circulation, which is modest relative to the [$380M+](https://x.com/search?q=%24380M%2B\&src=cashtag_click) in daily trading volume. The April 1, 2026 unlock of comparable size produced a 4% drawdown from local highs. Whether the May 1 event absorbs cleanly is the nearest binary test for the accumulation thesis. If the price holds above $0.87 into the CME futures launch on May 4, the base is confirmed. **Supply Unlock Timeline (simplified):** ```text Supply Unlock Timeline (simplified): May 1, 2026 ────── 52M SUI (~$49.7M at current price) 2026 ──────────── Ongoing monthly vesting clips 2027 ──────────── Team/investor tranches accelerate 2028-2030 ──────── Community reserve linear releases 2030+ ─────────── Final long-tail from 7-year community schedule ``` The IEO price was $0.03. Early backers are at roughly 30x at current levels. Structured selling from that cohort is largely behind us, as remaining unlocks skew toward community reserves and foundation grants deployed back into the network. Each staking-embedded ETF (GSUI, TSUI) reduces effective float by locking SUI with embedded yield. The storage fund mechanic adds a second layer: as on-chain data grows, more SUI is locked in the reserve fund and removed from the liquid supply without a burn event. Fundraising history: Mysten Labs raised $36M in its first round, then a $300M Series B in September 2022 at a [$2B+](https://x.com/search?q=%242B%2B\&src=cashtag_click) valuation. SUI Group Holdings added $20M via OTC purchase in August 2025, which was a secondary market transaction at prices above where the token trades today. Mill City Ventures, a Nasdaq-listed company, holds over 76 million SUI in treasury, acquired at an average of \~$3.64 with backing from Galaxy Digital, Pantera Capital, and Electric Capital. ## The Team [#the-team] **Evan Cheng (CEO).** Former Director of Engineering at Meta's Diem project. Built the compiler infrastructure underlying Swift's runtime before joining Meta. Made the decision to architect this chain around horizontal scaling as a first principle, not an afterthought. **Sam Blackshear (CTO).** Wrote the Move programming language at Meta. Move is now live on two L1 blockchains (Sui and Aptos) and is the first language purpose-built for on-chain asset ownership with formal verification built in. Not a language port, but built for the problem from scratch. **Adeniyi Abiodun (CPO).** Led product for Meta's crypto division. Built Facebook's payment infrastructure before Congress shut Libra down. Now building the outward-facing layer of the network, including Hashi for Bitcoin finance and the institutional custody stack that brought BitGo, FalconX, and Ledger into the network. **George Danezis (Chief Scientist).** PhD computer scientist, one of the original architects of the Narwhal/Tusk DAG consensus that became Mysticeti. Published the academic foundation that the chain's consensus runs on. **Kostas Chalkias (Chief Cryptographer).** 2012 ACM Software System Award recipient, one of the architects of zkLogin. Responsible for the cryptographic layer that makes seedless wallets and passkey authentication practical at the protocol level. Mysten Labs raised $336M across Series A (led by a16z) and Series B. After FTX's collapse, the team bought back FTX's entire stake for $96M, deploying treasury capital to protect governance independence rather than accepting dilution from a distressed seller. ## External Signals [#external-signals] **Institutional Access (ETFs):** * Grayscale Sui Staking ETF (GSUI) launched on the NYSE Arca on February 18, 2026 — first staking-embedded ETF for a non-BTC/ETH L1 in the US. \[[source](https://blog.sui.io/grayscale-sui-staking-etf-gsui-launches-nyse-arca/)] * 21Shares Spot SUI ETF (TSUI) was approved by the SEC and has been trading on Nasdaq since February 24, 2026. \[[source](https://blog.sui.io/21shares-spot-sui-etf-nasdaq-tsui/)] * Canary Capital Spot SUI ETF (SUIS) with staking live on Nasdaq. \[[source](https://blog.sui.io/grayscale-sui-staking-etf-gsui-launches-nyse-arca/)] * CME SUI Futures launching May 4, 2026 — cash-settled contracts, the same institutional access pathway that preceded ETH ETF approval. **Partnerships:** * Google Cloud — Sui data integrated into BigQuery; Vertex AI for Move code; AP2 agent payments protocol integration. \[[source](https://www.googlecloudpresscorner.com/2024-04-30-Sui-Teams-Up-with-Google-Cloud)] * Erebor Bank, N.A. — U.S. national bank with an OCC charter integrated Sui for stablecoin banking, enabling regulated on/off-ramps directly on-chain. \[[source](https://blog.sui.io/erebor-bank-global-payments/)] * Franklin Templeton Digital Assets — exploring tokenized fund use cases on Sui; $1.5T AUM manager signaling chain-level conviction. * [@RealVision](https://x.com/@RealVision) has partnered with Sui to integrate high-performance blockchain functionality into its financial media and membership platform. This collaboration enables secure attribution of member contributions and establishes a foundation for future crypto-powered rewards. \[[source](https://blog.sui.io/real-vision-integrates-sui/)] * Hashi protocol — backed by BitGo, FalconX, Bullish, and Ledger for BTC-native institutional finance on Sui. \[[source](https://blog.sui.io/new-era-of-bitcoin-based-finance-begins-meet-hashi/)] **Network Signals:** * Grayscale Research (July 2025): Sui holds 6.68-8.55% allocation in Grayscale Smart Contract Platforms Fund. \[[source](https://research.grayscale.com/reports/built-for-scale-why-sui-stands-out)] * Mill City Ventures holds 76M+ SUI in treasury at \~$3.64 average cost, backed by Galaxy Digital, Pantera Capital, and Electric Capital. \[[source](https://blog.sui.io/mill-city-ventures-sui-treasury/)] * SUI attracted $2.2M in weekly ETF inflows in the week of April 20, 2026 — institutional capital continuing to flow despite broader altcoin lag. \[[source](https://coinmarketcap.com/cmc-ai/sui/latest-updates/)] ## Trade Setup [#trade-setup] **Market Snapshot** ```text Current Phase: Post-unlock consolidation / accumulation Price: $0.9370 (April 23, 2026) Market Cap: $3.70B ATH: $5.35 (January 2025) | Drawdown from ATH: ~82% Recent High: $3.47 (early 2026) Recent Low: $0.87 (post-April 1, 2026 unlock) RSI: ~50 (neutral) Support: $0.87 Resistance: $1.20 Volume: $380.7M/day (84 exchanges) Sentiment: 46 (Fear) | 7d avg: 30.6 BTC Dominance: 60.05% ``` SUI runs on narrative catalysts, then distributes into actual launch events and unlock dates. The current range, with RSI neutral and volume recovering, reads as post-distribution consolidation. The 200-day moving average maintains a bullish slope. Whales and private groups have been positioning into this range ahead of Q2 catalysts while sentiment ran negative. This is the same setup that preceded each major move since the 2024 bull run. **Quarterly Price History** ```text | Year | Q1 | Q2 | Q3 | Q4 | |------|-----------|---------------------|----------|---------| | 2023 | N/A | -57.8% | -32% | +66.4% | | 2024 | +145.4% | -57.3% | +116.8% | +132% | | 2025 | -44.9% | +22.5% | +17.4% | -57% | | 2026 | -37.4% | +8.88% (so far) | N/A | N/A | ``` The pattern is readable: violent distribution after each major run, re-accumulation into the next catalyst cluster. Q2 2026 is already positive with Q1's drawdown behind us. Image **Scenario Analysis** ```text | Scenario | Assumptions | Target FDV | Multiple from Current | |----------|------------------------------------------------------------------------|-------------|------------------------| | Bear | Competition intensifies, unlocks weigh, macro weakness | $6B | ~0.6x (~$0.60) | | Base | TVL recovers to $3-5B, stablecoin layer scales, Mysticeti v2 sustains | $15-20B | ~1.6-2.1x ($1.50-$2.00)| | Bull | BTCFi captures 1%+ of BTC float, AI/payments volume compounds | $40-60B | ~4-6x ($4-$6) | ``` **Catalysts** The May 1, 2026 unlock of 52M SUI (\~$49.7M) arrives right before the CME futures launch on May 4. Clean absorption equals base confirmed. CME futures create the institutional hedging infrastructure that preceded meaningful price discovery for both BTC and ETH. The Miami conference (May 5-7) brings a16z, Fidelity, Mysten Labs, and Real Vision onto the same stage. EVE Frontier hackathon results on April 24, with an $80K prize and gaming narrative are the nearest near-term catalysts. Sui Overflow 2026 is building, with 2025's 599-submission benchmark to beat. Pending Bitwise/VanEck ETF approvals add a further institutional access catalyst when they arrive. Hashi moving from devnet to mainnet is the largest medium-term catalyst. The BTCFi thesis doesn't price in until it's live and processing volume. Watch the first Hashi TVL number as a signal for how institutional Bitcoin allocation actually responds. **Market Position** Break above $1.20 clears post-unlock resistance and historically signals re-entry of momentum buyers. The next level sits around $1.50, coinciding with the base case FDV scenario. Near-term target if Q2 catalysts land: $1.50-$2.00. Medium-term target on TVL recovery to [$3-5B](https://x.com/search?q=%243-5B\&src=cashtag_click): [$15-20B](https://x.com/search?q=%2415-20B\&src=cashtag_click) FDV. ## Key Risks [#key-risks] **Token Unlock Pressure:** 60.5% of the total supply remains unlocked. The May 1, 2026 event (52M SUI, \~$49.7M) is the immediate test. Risk window is persistent through 2030. Severity is high on individual events, manageable if ETF inflows and staking absorption scale with supply. **Competitive Pressure:** Solana's Firedancer client, live on mainnet since late 2025, targets above 1 million TPS and commands the largest developer base among high-throughput L1s. Monad's EVM-compatible parallelism targets the same market. Neither resolves the object-model advantage, but both represent credible alternatives with stronger network effects today. **Network Reliability:** On January 14, 2026, the mainnet experienced a 6-hour halt caused by an edge-case consensus bug. User funds were never at risk. The network halted rather than risking a state fork. Mysten Labs has since implemented faster detection, automated recovery tooling, and expanded consensus-related testing. The event is a known data point. Institutions evaluating Sui as a payment rail will price it in. **Centralization Risk:** 117-122 validators and high hardware requirements place Sui below Ethereum on decentralization metrics. Mysten Labs' dominant role as both core developer and application builder creates a single point of influence that could limit censorship-resistance claims at the institutional level. **Move Language Adoption Ceiling:** Move is not Solidity. EVM-compatible chains carry Ethereum's developer toolchain forward without retooling. OpenZeppelin's library landing on Sui helps, but the absolute base of active developers remains small relative to Solana's 2,000+ and Ethereum's 3,300+. **Revenue Scale Gap:** Solana generated $603M in on-chain fees in 2025 (Nansen). Sui's $0.0023 average transaction cost is the product differentiator, but it means orders of magnitude more transaction volume is needed to close the monetization gap. This is measured in years. **Macro Sensitivity:** At 39.5% circulating supply and BTC dominance near 60%, SUI is a high-beta alt. BTC breaking below $70K puts SUI at risk of testing $0.60 or lower. **Regulatory Overhang:** Pending Bitwise/VanEck ETF approvals are not guaranteed. A negative SEC ruling on staking-embedded structures removes that institutional catalyst. The GENIUS Act's stablecoin framework, if it restricts non-bank issuers, could affect USDsui's growth trajectory. The thesis holds as long as: TVL begins recovering toward [$1B+](https://x.com/search?q=%241B%2B\&src=cashtag_click), the May 1 unlock absorbs cleanly, and BTC holds above $80K into Q3 2026. ## Conclusion [#conclusion] Right now, three elements align on this asset that rarely appear together. The technology is genuinely differentiated at the architectural level. The object model enables parallelism that account-based chains cannot achieve without rebuilding their foundation. Institutional access infrastructure just arrived, with three regulated spot ETFs trading, CME futures launching May 4, a U.S. national bank integrated on-chain, and Fidelity and Grayscale on the same Miami stage next week. And the token is sitting 82% below its all-time high with neutral RSI, while the product ships faster than ever. Why now? The CME futures launch is the structural catalyst. Regulated derivatives preceded meaningful institutional price discovery for both BTC and ETH. The mechanism is the same. Create the hedging infrastructure that makes it easier for large allocators to hold spot exposure. Hashi is in devnet with BitGo and Ledger, already committed. The Sui Dollar is live. Revolut staking is live. Erebor Bank is integrated. The Miami conference is one announcement away from resetting the narrative on this whole cycle. This is the pre-event window. If the base case plays out — TVL recovering to [$3-5B](https://x.com/search?q=%243-5B\&src=cashtag_click), stablecoin volumes compounding, BTCFi going live on Hashi — the FDV target is [$15-20B](https://x.com/search?q=%2415-20B\&src=cashtag_click). The bull case, where Hashi captures a meaningful slice of idle Bitcoin and AI agents settle on Sui's rails at scale, puts FDV at [$40-60B](https://x.com/search?q=%2440-60B\&src=cashtag_click). Watch for TVL breaking back above $1B as the signal that recovery is real. Hashi's first reported TVL number is the BTCFi proof of concept. Price clearing $1.20 confirms the post-unlock range has resolved. The infrastructure was built by the team that had already built products that scale for billions of users. The next twelve months will prove whether the demand was waiting for it. * **X:** [@SuiNetwork](https://x.com/SuiNetwork) * **Website:** [https://sui.io](https://sui.io/) * **Community:** [https://discord.gg/sui](https://discord.gg/sui) This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Unipeg (/research/unipeg) # Unipeg [#unipeg] Image ## The Standard That Quietly Collapsed [#the-standard-that-quietly-collapsed] There's a version of on-chain digital culture that never fully arrived. CryptoPunks were radical in 2017, not because they were images. They were the first objects that genuinely lived on a blockchain without external dependencies. Autoglyphs did it properly. Early Art Blocks got close. Then the market scaled, corners were cut, and the standard everyone celebrated quietly collapsed. By 2021, most NFTs were jpegs hosted on IPFS with metadata pointing somewhere that might not exist in five years. The "on-chain" part became aesthetic, not literal. The format became the problem. The distribution mechanism was always the failure point. Building on-chain art is not technically difficult — producers have been creating genuinely interesting generative work for years. The gap was always between the art and the infrastructure that delivered it: vanilla mints, IPFS links, metadata pointing off-chain, external storage, Arweave dependencies. The art itself could be brilliant, but the moment you linked it to a server or a pinning service, it became fragile. A URL that can rot is a URL that will rot. The ownership was real; the object was provisional. The problem ran deeper than storage. Every NFT collection with external metadata has a single point of failure that no contract can protect: the image is separate from the token. You can own the token permanently. The image disappears whenever the hosting does. No amount of on-chain verification changes what is fundamentally an off-chain dependency. And because the distribution mechanism was always separate from the art itself, it shaped the culture in ways nobody wanted. Launch-day hype machines, coordinated reveals, collection-wide metadata refreshes. The art and the economics were structurally disconnected. Image What nobody had built was a system where the delivery mechanism and the art were the same thing. Where every trade is part of how the work gets made. Where the object cannot be separated from the chain because it is the chain. ## The Layer That Was Missing [#the-layer-that-was-missing] The conversation became circular. On-chain art developers knew the problem. The community knew the problem. The solution seemed to require either building a new chain or accepting the compromise. Some teams tried calldata-based approaches: 0xmons, Blitnauts, Ethscriptions. Interesting experiments. None of them solved the mechanism question at the point of exchange itself. Meanwhile, Uniswap v3 had become the defining liquidity infrastructure of DeFi with no capacity for custom logic at the point of a swap. If you wanted to extend what happened when someone traded, you had to build outside the protocol, bolt your logic on top, and accept the resulting complexity and attack surface. The AMM and any creative application of it were fundamentally separate layers. Exchange was exchange. Everything else was something else. The tooling gap was not abstract. The builders working on on-chain art for months said they were desperately looking for an "anti-cringe distribution mechanism." Not a better image format. Not a new hosting solution. A mechanism where the way the work reached collectors was as considered as the work itself. This encapsulates what was missing from on-chain culture for eight years. The art existed. The infrastructure wasn't. ## What Hooks Actually Unlocked [#what-hooks-actually-unlocked] When Uniswap v4 shipped, one architectural detail changed the design space entirely: hooks. Custom logic that runs directly at the point of exchange, not wrapped around it, not bolted on top. Inside it. Before a swap executes, after it closes, before liquidity moves. Arbitrary code with access to the exact on-chain state at the moment of the transaction. Image Most developers read that as a DeFi primitive. Dynamic fees, TWAP orders, volatility oracles, limit orders, financial applications of programmable exchange logic. The design space was enormous, and it was obvious. The Uniswap ecosystem has been where all meaningful financial innovation happens in crypto. Over $3 trillion in cumulative volume processed across all protocol versions. Hooks extend that same infrastructure into arbitrary programmable logic, and someone finally asked: what if the swap itself is the creative act? **Unipeg** is what that looks like when built properly. A custom v4 hook generates a unique 24×24 unicorn image entirely on-chain, with no external storage, no IPFS, no Arweave, every time a whole-integer amount of uPEG is swapped. The hash is written permanently to the contract before the transaction closes. The image is derived from the hash directly. Nothing points anywhere external. The object and the chain are the same thing. ```text Traditional NFT Structure: Unipeg Structure: [Contract] → token ID [v4 Pool] → swap triggers hook | | [IPFS/Server] → image |→ reads: swap count + block timestamp | + prevrandao + block number [Token] ≠ [Image] |→ keccak256 hash (separate layers, external link) |→ on-chain SVG renderer |→ hash written to contract [Object] = [Token] = [Chain data] (no external link, no separate layer) ``` The hook reads four inputs at the exact moment of the swap: the number of uPEG transactions before yours, the block timestamp, your block number, and prevrandao — genuine on-chain randomness introduced post-merge via EIP-4399, generated by the validator who proposed your block, ungameable by design. Those inputs are hashed with keccak256, encoding every visual property of the unicorn: body, eyes, horn, hair, wings, tail, colors, background, and the original owner's wallet address. All of it written to the contract permanently before the transaction closes. As long as you hold it, the image stays. The market keeps generating new swaps, new seeds, new unicorns. Yours does not change until you sell. Whoever buys next gets a different hash entirely. The object is a function of the chain state at the moment you bought, locked to you until you let it go. The name completes the picture. Hayden Adams originally wanted to call the protocol Unipeg (unicorn plus pegasus). When the demo was shown to Vitalik, Vitalik said it sounded more like Uniswap, and the name changed. The name that got dropped in 2018 turned out to describe something v4 made possible seven years later. Uni + JPEG = uPEG. A peg being a rule enforced at the point of exchange, which is precisely what a v4 hook is. ## The Self-Enforcing Scarcity Machine [#the-self-enforcing-scarcity-machine] Most collection mechanics are designed. Rarity tables, trait probabilities, reveal schedules, whitelists. The team decides what is scarce and communicates it to the market. The market accepts it or doesn't. The scarcity is a claim backed by the team. Image Unipeg's scarcity is mathematical. The total supply is 10,000 uPEG tokens. Every whole-integer balance triggers a uPeg object. Fractional amounts don't mint. They accumulate in the liquidity pool as dust. As more trades happen, more fractional amounts (decimal remnants of swaps and sells) sit inert in the pool. The pool's composition shifts. Whole integers become harder to assemble from the dust. The supply of mintable objects only moves in one direction. ```text uPEG Supply Mechanics: [10,000 total tokens] | [Whole integers → uPeg objects with hash + traits] | | [Fractional dust → returns to LP pool] | [Dust dominance ratio rises over time] | [Probability of assembling whole integer falls] | [Scarcer objects, richer provenance] ``` Two distinct things emerge from one contract: * uPeg objects: whole integers carrying a permanent hash, traits, provenance, on-chain identity. * uPeg dust: fractional remnants returning to the pool. With this setup, the token exists but the object may not. What determines the difference is how much accumulates and whether someone puts it together. The scarcity was not written into the contract. The mathematics were. The rarity system compounds this. Two scores drive value: visual (uniqueness of traits relative to every other existing object) and age (how long the current holder has held it). Age score matters because the market creates it. An object held since April 15 accumulates continuously. One extracted in an atomic batch operation four minutes ago starts at zero. Same visual rarity on paper. Completely different provenance in practice. When a coordinated batch attack extracted rare objects in May, the response demonstrated the design philosophy. Contract ownership had already been renounced to 0x0: the hook couldn't be changed, the image renderer couldn't be swapped, the random seed provider was untouchable. Rather than fight the attack, the team absorbed it: the age score made every batch-extracted rare carry its own history permanently. The attacker's objects entered the secondary market stamped with AGE 0. They weren't banned. They weren't blocked. The contract recorded their origin and let the market price it. The attacker was written into the work's catalog. This is what a genuinely decentralized object looks like. No admin key. No upgrade path. No intervention possible. The mechanism runs as designed, and the market discovers what that means. ## First-Mover Provenance Nobody Can Replicate [#first-mover-provenance-nobody-can-replicate] Uniswap v4 hooks only launched in late 2024. The design space is open, and most teams building on it are focused on financial applications: dynamic fees, TWAP orders, custom liquidity curves. Unipeg entered as the first collectibles proof-of-concept at scale on Ethereum, holding #2 hook volume position on the chain with just four pools — a data point that was accurate at the time of writing. The architecture is difficult to replicate not because the code is complex (the SVG generation is open source on GitHub) but because the design took the mechanism seriously. The distribution problem required building at the v4 hook layer, not around it. Every team that launches a hook-based collectibles project after this benefits from Unipeg proving the model works. They cannot replicate the provenance of the first objects that existed. They cannot replicate the scarcity that has already accumulated. Every uPeg object carries a block hash from the chain state at the moment it was minted. That data exists forever on Ethereum. The provenance is provable and permanent. Image Secondary market infrastructure built organically around the object. [Peg2Peg](https://x.com/unipegv4/status/2050278218855276922), a peer-to-peer exchange with no middleman and no custody, launched May 1 and crossed 150 ETH in volume within two days. [OpenSea](https://x.com/unipegv4/status/2051666486486245379) went live May 5. [Element Market](https://x.com/unipegv4/status/2052048650906280265) followed May 6. [42space](https://x.com/42space/status/2051121348618133539) came online May 4. None of this was supplied by a team-controlled platform. The community built the rails because the object warranted them. Zero KOL compensation. Zero partnerships. Zero paid promotion. Growth from 0 to 1,000 followers and hundreds of thousands of impressions and site visits is entirely organic. People are showing up because they find the mechanism interesting, not because someone is paying them to say so. ## Market Opportunity [#market-opportunity] The on-chain collectibles category is at an inflection. The ERC-721 era produced tens of billions in volume, and most of it was built on the compromise of off-chain storage. The first generation of NFTs that are genuinely on-chain is only beginning to form. Ethereum remains the chain where all meaningful innovation happens. Hooks extend Uniswap's infrastructure into arbitrary programmable logic at the point of exchange, and the collectibles design space within that is functionally unexplored. Unipeg has generated approximately $120M in total trade volume since launching in April 2026, operating with four pools and zero paid promotion. The relevant comparison is not to the 2021 NFT market. That market was built on a broken distribution model. The comparison is to the pre-Punk moment, when genuinely on-chain objects didn't exist at an accessible price point. CryptoPunks were free to claim in 2017. The collectors who understood what permanent on-chain ownership meant before the broader market did are the reference group. The valuation gap between Unipeg's current market cap and the eventual market cap of the first real on-chain collectible standard is where the trade lives. Early Punks and Autoglyphs at a similar stage looked like this: low market cap, proven mechanism, market not yet pricing the permanence. Image The expansion path follows the hooks adoption. Every v4 pool that launches with hook-based collectible logic validates the category. Unipeg, as the first and largest example, has provenance no subsequent project can replicate. If v4 hooks become the standard infrastructure for the next DeFi era (the design intent is explicitly to let the market fix decentralized problems rather than team-controlled contracts), the earliest proof-of-concept objects carry historical weight that compounds. The dust dominance ratio is the clearest forward indicator, currently at 0.64. Higher means more fractional accumulation in the pool, fewer whole integers available for minting, existing objects becoming structurally scarcer. The market made the uPeg. The market decides its value. ## Valuation [#valuation] The relevant comparables are early-stage on-chain collectible tokens at a similar phase. Not DeFi protocols with revenue, and not standard NFT collections with a floor price divorced from token economics. CryptoPunks were unclaimed at launch. The Autoglyph collection launched at near-zero. Art Blocks early output traded at the mint price for months before price discovery happened. Each of those had one structural advantage over the NFT collections that followed: the object genuinely lived on-chain. Unipeg shares that structural advantage and adds a mechanism that those projects didn't have: the AMM itself as an automatic scarcity engine. The $7.99M market cap against $120M in total trade volume produces a volume-to-cap ratio consistent with early-stage DeFi protocols, not established collectible collections. The market is not pricing the accumulated scarcity of the objects or the provenance of what already exists. That gap is the trade. ## Tokenomics [#tokenomics] ```text | Metric | Value | |---|---| | Total Supply | 10,000 uPEG | | Circulating Supply | Full supply accessible (no lockups) | | FDV / Market Cap | ~1.0x | | Active Objects (uPegs in existence) | 6,091 | | Holders | 4,770 | ``` The supply structure is clean. 10,000 is the hard cap and the FDV equals the market cap. There are no insider lockups, no vesting schedules, no unlock events to watch. Every token is in the market. What isn't held as whole integers is accumulating as dust in the liquidity pool. The token functions as both a fungible asset and the entry point to a collectible object. Hold a whole integer, and you have a uPeg with permanent hash, traits, and provenance. Sell below a whole integer, and you return dust to the pool. The two forms (object and token) exist within a single contract and convert automatically based on balance. Holding improves rarity. Trading degrades it. The economics of ownership and the economics of collection align, which is what most NFT projects failed to achieve. Permanent liquidity: 13.65 ETH and 717.85 uPEG locked on Uniswap v4 for 255 years and 11 months. That floor is structural, not a team commitment. ## The Team [#the-team] Unipeg is led by [@unipegv4](https://x.com/@unipegv4), a developer associated with the 0xHadrian blog, with demonstrated experience in on-chain experimentation and protocol design. Not fully doxxed — pseudonymous in the tradition of Ethereum's cypherpunk contributors, which is common for early-stage experimental hook projects in the Uniswap v4 ecosystem. [@unipegv4](https://x.com/@unipegv4) **/ 0xhadrian.eth.** Wrote the core Solidity hook contract, the on-chain SVG renderer, and authored three published essays under his ENS address before launch, establishing the philosophical framework. The decision to renounce contract ownership to 0x0 before the May attack demonstrates a commitment to decentralization that goes beyond stated intent. The hook cannot be changed. The image renderer is frozen. The randomness provider is locked. [@gavofyork](https://x.com/@gavofyork)**.** Solidity contract architecture. Contributed the hook that triggers automatically before the transaction closes without a separate user action. [@sendmoodz](https://x.com/@sendmoodz) **and** [@saraareynolds](https://x.com/@saraareynolds)**.** The v4 hook architecture itself was designed by sendmoodz and brought to life by saraareynolds at Uniswap. Unipeg runs on the infrastructure they built. The broader contributor group includes Jordan Lyall (VenturePunk), zac.eth (CoinQuarium), LaserCat397.eth (TinFun), and Minion (GBV Capital), alongside other community contributors. No Discord, no roadmap, no airdrop, no KOL round. Posts on the official account are mechanism updates, not marketing. The project communicates through what it ships, not what it says. ## External Signals [#external-signals] * **Bankless.** Featured Unipeg as the leading example of v4 hook-based collectibles, describing it as a successful proof-of-concept with approximately $120M in trade volume since the April launch, and the largest example of this model in the wild. * **OpenSea CMO Adam Hollander and Uniswap team member niko.** The project gained quick viral attention in the Uniswap v4 and NFT communities after mentions by both, serving as early institutional validation from within the collectibles and protocol layer. * **Bitget Web3 Academy.** Published a dedicated explainer covering Unipeg's mechanism, price outlook, and risks for the Uniswap v4 hook-based token category, reflecting growing researcher coverage beyond crypto-native media. \[[source](https://web3.bitget.com/en/academy/what-is-unipeg-upeg-price-outlook-risks-and-uniswap-v4-hook-based-token-explained)] * [@ztrader369](https://x.com/@ztrader369)**.** One of the first to discover this new trend and fully understand its value. Wrote countless posts on this project. * [@798\_eth](https://x.com/@798_eth). Early supporter in the Asian region. Wrote multiple in-depth articles on Unipeg. ## Trade Setup [#trade-setup] **Market Snapshot** ```text Current Phase: Post-ATH correction / accumulation Price: $793.18 (ATH: $3,050 | ATL: ~$20-$50) Drawdown: ~74% from ATH Recent Perf: -39.27% (24h) | -41.12% (7d) Volume: $5,956,151 (+18.45% 24h) Exchanges: MEXC, Uniswap v4, Lbank, Uniswap v3 Market Cap: $7.99M FDV: $7,931,763 ``` The price action fits the post-launch distribution pattern: explosive move from the ATL range to $3,050 ATH as the mechanism story spread, then a sharp correction as early holders distributed into the narrative. The pattern is typical of category-creating primitives that get discovered faster than they can be evaluated. The narrative moved before the mechanics were widely understood. Now the mechanics are documented: covered by Bankless, analyzed by the community, rarity index is live. The price is reset. Fear index at 38 with BTC dominance showing a slow decline creates room for altcoin rotation, especially into the Ethereum ecosystem. BTC dominance declining alongside USDT dominance signals capital preparing to move into new narratives. UPEG is the right type of project to benefit from that rotation: Ethereum-native, mechanism-driven, with real collector demand and no manufactured hype. **Scenario Analysis** Scenario Assumptions Target FDV Multiple from Current Bear Hooks don't reach mainstream adoption; category stays niche; no CEX listings $2M–$4M \~0.25x–0.5x Base V4 hooks adoption grows; Unipeg maintains first-mover position; 1–2 tier-2 CEX listings $25M–$50M \~3x–6x Bull Tier-1 CEX listing; hooks become DeFi 3.0 standard; on-chain art renaissance validates category $100M–$300M \~12x–37x **Catalysts** The most time-sensitive catalyst is a CEX listing. The community thesis depends on exchange access, expanding the holder base beyond Ethereum DeFi natives. A tier-1 listing at the current market cap would be a major volume event. OpenSea, Element, and MEXC listings are all steps in that direction. The dust dominance ratio rising above 0.64 is a structural catalyst for existing holders. Higher DDR means fewer mintable objects from available dust, which means existing objects become harder to obtain. The object supply contracts while the token supply stays fixed. Watch this number weekly. On-chain certification for provenance, flagged as coming soon, adds a verification layer that makes the genuine-object/farmed-object distinction visible at the contract level rather than requiring marketplace tagging. That closes the rarity integrity question structurally. **Future Outlook** **Near-term (0–6 months):** Tier-1 or tier-2 CEX listing; provenance certification going live; dust dominance ratio pushing toward 0.70+. If the thesis plays out, UPEG reaches $50M–$150M market cap within this window. **Medium-term (6–18 months):** V4 hooks as standard DeFi 3.0 infrastructure. Unipeg objects (the first proof-of-concept) carry permanent historical status. Secondary market volume and object floor prices follow. Target: $50M–$150M market cap on hooks reaching mainstream adoption. **Long-term (18+ months):** If on-chain native objects replace the IPFS-dependent collectible standard, Unipeg sits at the beginning of that transition. The provenance of objects minted in April and May 2026 is permanent. The block data exists on Ethereum forever. The terminal case is a market cap commensurate with early Punk and Autoglyph valuations, where on-chain permanence was the differentiation, and the market eventually priced it properly. ## Key Risks [#key-risks] **Technical. Hook Architecture Exposure.** The v4 hook model is new infrastructure. UpegHook.sol runs automatically at the point of exchange, and with contract ownership renounced, any undiscovered vulnerability in the hook itself or in the v4 PoolManager layer could affect object generation or trading with no ability to patch. If a critical exploit surfaces: price impact is severe, potential permanent disruption of minted objects. **Market. Post-Launch Distribution Ongoing.** The 74% drawdown from ATH with $5.9M in 24h volume against a $7.99M market cap points to active selling. If early holders continue distributing and no new demand cohort arrives before a major catalyst, the price can continue compressing. Risk window: next 4–8 weeks. **Competitive. The Model Is Replicable.** The SVG generation code is open source. Any team can build a hook-based generative collectibles project. The differentiation Unipeg has is first-mover provenance and the accumulated scarcity of existing objects. That advantage disappears if a better-capitalized team launches a higher-quality hook project with paid distribution and a KOL round. The mechanism is not defensible; the provenance of the objects is. **Rarity. Farming Attacks Degrade Category Perception.** The May batch-extraction attack, while handled elegantly via age scoring, created confusion in the community about which objects carry genuine value. If rarity farming persists and on-chain certification is delayed, the secondary market premium on rare objects is suppressed. **Pseudonymous Team.** The core developer is not fully doxxed. If development stops and no community takes over the open-source codebase, the project loses its primary update and communication layer. The contracts are immutable but without further development, engagement could stop. What makes the thesis hold despite these risks is the contract architecture itself. Contract ownership has been renounced. The hook cannot be changed. The image renderer is frozen. No team decision can alter the objects that already exist. Whatever happens to the team, the existing uPeg objects are permanent. The block data that generated each one is in the Ethereum chain forever. The provenance question (can you prove where this object came from) resolves to yes, mathematically, for every object that already exists. ## Conclusion [#conclusion] Something structurally new shipped in April 2026 on Ethereum. Not a better NFT mechanism, not a DeFi protocol with a collectible wrapper. A system where every trade is part of how the art gets made, where the distribution mechanism and the object are the same transaction, and the contract that runs it has been renounced to the zero address. Uniswap v4 hooks became available in late 2024. The first months of the hook era produced financial applications. Unipeg is the first collectibles proof-of-concept at scale — $120M in total volume, listings across four exchanges, a community-built peer-to-peer marketplace that crossed 150 ETH in volume in two days, zero paid promotion. The hook-based collectibles category is proven. The first-mover with permanent on-chain provenance is already in the market at a $7.99M market cap, 74% below ATH, with BTC dominance slowly declining and altcoin rotation building on Ethereum. If the thesis plays out (hooks become the standard for the next DeFi era, the on-chain art category gets a second wave of attention, and a tier-1 CEX listing expands the holder base), UPEG reaches $50M–$150M market cap within 3–6 months. The objects minted in April 2026 carry block hashes from the first weeks of the hook-based collectibles era. Those hashes exist on Ethereum permanently. The market will eventually price that history the way it priced the Punks that nobody claimed in 2017. Watch three things: the dust dominance ratio (currently 0.64 — rising means structural scarcity is compressing the mintable supply), CEX listing announcements, and on-chain provenance certification going live. If DDR crosses 0.70 and a tier-2 CEX lists before the altcoin rotation fully materializes, the setup is in place before the market reprices. The mechanism was designed to be authorless. The objects it created aren't going anywhere. The name that got dropped in 2018 turned out to describe something that took seven years to become possible. Everything else follows from that. * **X:** [https://x.com/unipegv4](https://x.com/unipegv4) * **Website:** [https://unipeg.art](https://unipeg.art/) * **Community:** [https://t.me/unipeglive](https://t.me/unipeglive) * **CA:** 0x44b28991B167582F18BA0259e0173176ca125505 ## Disclaimer [#disclaimer] This document is for informational purposes only and does not constitute investment advice or an offer to sell or solicitation to buy any securities or investment products. All investments involve risk, including the possible loss of principal. Past performance is not indicative of future results. Any forward-looking statements or hypothetical examples are subject to risks and uncertainties and are not guarantees of future performance. No client-adviser relationship is established by this material. The author assumes no responsibility for the accuracy or completeness of third-party information referenced. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Tether Academy (/tether/academy) * **Role:** Curriculum architect and engineering writer, building the academy and authoring the lessons * **Status:** V1, QVAC track live [Watch the demo on YouTube](https://youtu.be/m3e4nDuLERo) · [Try the academy](https://thisonedev.github.io/tether-academy/) ## Background [#background] Over the past few years, Tether has become one of the largest stablecoin issuers. Their main product (USDT) is more useful than 99.9% of all blockchain products combined, and their revenue exceeds that of most major banks. As we are all aware, Tether has recently expanded into other verticals, including P2P and open-source AI solutions. Tether bets that the future lies in private, local, open-source models running on user devices, calling this strategy the "Stable Intelligence Era." ## Goal [#goal] My answer to this opportunity is a fresh Codecademy-style learning center for their full product suite. If my instinct is correct, this company will not stop at one product. They are going to expand. This is why having a place where both humans and agents can learn about their tech will become extremely valuable. The current MVP covers 70 QVAC lessons with 18 chapters dedicated to each capability area, including model loading, image manipulation, and voice assistance. The goal of this version is for people to get familiar with the concept and receive feedback from the Tether team. If there's enough interest, I will dedicate a significant chunk of my time to this project alone. demo ## Setup [#setup] ### 1. Prerequisites [#1-prerequisites] * Node.js 20.18+ (Node 20 LTS works, Node 22 also fine) * npm 10+ (pnpm 11 also works on Node 22.13+) ### 2. Install dependencies [#2-install-dependencies] From the project root: ``` npm install ``` ### 3. Start the dev server [#3-start-the-dev-server] ``` npm run dev ``` The dev server runs Turbopack with HMR. For a webpack fallback, use `npm run dev:webpack`. To start clean, use `npm run dev:clean`. ## Build [#build] The site is a static export. The full pipeline runs the lesson sync and the vendored-example verifier before `next build`: ``` npm run build ``` For a quick visual check without the prebuild: ``` npm run build:dev ``` Output goes to `out/`. Drop the directory on any static host. --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # WDK CowSwap Module (/tether/wdk-cowswap) [WDK CowSwap](https://github.com/thisonedev/wdk/tree/master/wdk-protocol-swap-cowswap-evm) is a lightweight package that lets EVM wallet accounts swap tokens using the Cowswap protocol. It provides a clean SDK for token swaps on EVM chains and works with both standard wallets and ERC-4337 smart accounts. wdk-cowswap ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` git clone https://github.com/thisonedev/wdk.git ``` ### 2. Enter wdk-protocol-swap-cowswap-evm directory [#2-enter-wdk-protocol-swap-cowswap-evm-directory] ``` cd wdk-protocol-swap-cowswap-evm ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ## Tests [#tests] To run the test suites for this module, use the following commands: * Run unit tests (Jest): ``` npm run test:unit ``` * Run integration tests (brittle): ``` npm run test:integration ``` * Run test coverage: ``` npm run test:coverage ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # WDK Sui Wallet Module (/tether/wdk-sui-wallet) [WDK Sui Wallet](https://github.com/thisonedev/wdk/tree/master/wdk-wallet-sui) is a simple and secure package to manage BIP-44 wallets for the Sui blockchain. This package provides a clean API for creating, managing, and interacting with Sui wallets using BIP-39 seed phrases and Sui-specific derivation paths. wdk-sui ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` git clone https://github.com/thisonedev/wdk.git ``` ### 2. Enter wdk-wallet-sui directory [#2-enter-wdk-wallet-sui-directory] ``` cd wdk-wallet-sui ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ## Tests [#tests] To run the test suites for this module, use the following commands: * Run unit tests (Jest): ``` npm run test:unit ``` * Run integration tests (brittle): ``` npm run test:integration ``` * Run test coverage: ``` npm run test:coverage ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Hello World TON (/ton/hello-world-ton) [Hello World TON](https://github.com/thisonedev/vault/tree/master/hello-world-ton) is a sample project that sets and retrieves messages in a TON smart contract onchain. For in-depth tutorial, refer to the [Tutorial](#tutorial). ## Project structure [#project-structure] * `contracts` - source code of all the smart contracts of the project and their dependencies. * `wrappers` - wrapper classes (implementing `Contract` from ton-core) for the contracts, including any \[de]serialization primitives and compilation functions. * `tests` - tests for the contracts. * `scripts` - scripts used by the project, mainly the deployment scripts. ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` https://github.com/thisonedev/vault.git ``` ### 2. Enter hello-world-ton directory [#2-enter-hello-world-ton-directory] ``` cd hello-world-ton ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ## Running the project [#running-the-project] ### Build [#build] `npx blueprint build` or `yarn blueprint build` ### Test [#test] `npx blueprint test` or `yarn blueprint test` ### Deploy or run another script [#deploy-or-run-another-script] `npx blueprint run` or `yarn blueprint run` ### Add a new contract [#add-a-new-contract] `npx blueprint create ContractName` or `yarn blueprint create ContractName` # Tutorial [#tutorial] ## Overview [#overview] A TON smart contract is a program stored on the TON blockchain and executed by the [TON Virtual Machine](https://docs.ton.org/tvm/overview#tvm-overview) (TVM). Each contract has a unique address and consists of two main components: * Code — compiled TVM instructions that define the contract's logic. * Data - persistent state that stores information between interactions. TON offers multiple languages for writing smart contracts. This tutorial uses Tolk, the recommended language for new projects, and [Blueprint](https://docs.ton.org/contract-dev/blueprint/cli) — TON's official development framework for scaffolding, compiling, testing, and deploying contracts. > If you're coming from the EVM development ecosystem, consider reading about [key TON aspects](https://docs.ton.org/from-ethereum) and [basic Tolk syntax](https://docs.ton.org/languages/tolk/basic-syntax) before proceeding with this tutorial. ## What You'll Build [#what-youll-build] By the end of this tutorial, your project will have the following structure: ``` HelloWorldProject/ ├── contracts/ │ └── hello_world_contract.tolk # The smart contract logic (Tolk) ├── wrappers/ │ └── HelloWorldContract.ts # TypeScript class for encoding/decoding contract messages ├── scripts/ │ ├── deployHelloWorldContract.ts # Deploys the contract to testnet │ ├── getMessage.ts # Reads the stored message off-chain │ └── updateMessage.ts # Sends a transaction to update the message └── .env # Wallet credentials and deployed contract address ``` ## Implementation [#implementation] ### Setup [#setup-1] Create your first TON project as follows: 1. Open your terminal and run: ```bash npm create ton@latest ``` You'll see the following prompt: ```bash ? Project name HelloWorldProject ? First created contract name (PascalCase) HelloWorldContract ? Choose the project template ❯ An empty contract (Tolk) An empty contract (FunC) An empty contract (Tact) A simple counter contract (Tolk) A simple counter contract (FunC) A simple counter contract (Tact) ``` 2. Enter your project and contract name, then select `An empty contract (Tolk)`. Blueprint will create a folder with your project and install the required dependencies. 3. Enter the project directory: ```bash cd HelloWorldProject ``` ### Configure Your Environment [#configure-your-environment] Before writing any code, set up your `.env` file in the root folder with the following variables: ```bash # .env WALLET_MNEMONIC="word1 word2 word3 ... word24" # Your 24-word seed phrase WALLET_VERSION="v5r1" # Find this in your wallet app or on Tonscan CONTRACT_ADDRESS="" # Fill in after deployment ``` ### Write Your First Contract [#write-your-first-contract] Your first contract is a simple Hello World contract that stores a single message on-chain. It exposes a `message()` getter to read it, and accepts an `UpdateMessage` transaction to overwrite it. To create the contract, copy the following code and paste it into the `./contracts/hello_world_contract.tolk` file: ``` tolk 1.2 struct Storage { message: cell; } // read the storage struct from persistent storage fun Storage.load() { return Storage.fromCell(contract.getData()); } // write the storage struct back to persistent storage fun Storage.save(self) { contract.setData(self.toCell()); } struct(0x00000001) UpdateMessage { message: cell; } type AllowedMessage = UpdateMessage; // return the current message off-chain get fun message(): slice { val storage = lazy Storage.load(); return storage.message.beginParse(); } // read the op code and route to the right contract action fun onInternalMessage(in: InMessage) { val msg = lazy AllowedMessage.fromSlice(in.body); match (msg) { UpdateMessage => { var storage = lazy Storage.load(); storage.message = msg.message; storage.save(); } else => { assert(in.body.isEmpty()) throw 0xFFFF; } } } ``` The contract has the following components: * `Storage` struct — defines the contract's persistent state. Data is serialized into a `cell`, TON's fundamental unit of storage. * `Storage.load()` / `Storage.save()` — deserializes the contract's root data cell into a `Storage` struct, and serializes it back after any state change. TON contracts store all state in a single root data cell, so every read and write goes through these two functions. * `UpdateMessage` struct — declares the binary format for the update operation. The `0x00000001` annotation is the op code TON uses to identify and route incoming messages. * `get fun message()` — returns the current message stored on-chain. Runs off-chain and cannot modify state. * `onInternalMessage()` — the single entry point for all on-chain calls. Every inbound message arrives here first. Op codes are matched via `match` to route to the correct action. ### Compile the Contract [#compile-the-contract] Compile your contract into bytecode for execution by the TVM: ```bash npx blueprint build HelloWorldContract ``` Expected output: ``` Build script running, compiling HelloWorldContract 🔧 Using tolk version 1.2.0... ✅ Compiled successfully! Cell BOC result: { "hash": "32d0a2d506fcbffdae7975ecabf00439c6b9da106b6d79e5b70f981e3a591de3", "hashBase64": "MtCi1Qb8v/2ueXXsq/AEOca52hBrbXnltw+YHjpZHeM=", "hex": "b5ee9c7241010401003e000114ff00f4a413f4bcf2c80b010201620203003ed0f891f24020d72c200000000c9831d74cc8ccc9ed54e030840f01c700f2f40011a0da23da89a1ae99a1172af91d" } ✅ Wrote compilation artifact to build/HelloWorldContract.compiled.json ``` ### Deploy the Contract [#deploy-the-contract] Deploying a contract on TON requires two components in addition to the contract itself: * A wrapper — a TypeScript class that encodes and decodes messages in the exact binary format your contract expects. Unlike EVM, TON contracts don't have a standard ABI format, so this is how your scripts know how to talk to your contract. * A deployment script — a Blueprint script that instantiates the wrapper and sends the initial deploy transaction. #### 1. Create the Wrapper [#1-create-the-wrapper] Replace the contents of the `./wrappers/HelloWorldContract.ts` file with the following code: ```typescript import { Address, beginCell, Cell, Contract, ContractABI, contractAddress, ContractProvider, Sender, SendMode, toNano } from '@ton/core'; // data required to deploy the contract export type HelloWorldContractConfig = { message: string; }; // serializes the initial message into a cell for deployment export function helloWorldContractConfigToCell(config: HelloWorldContractConfig): Cell { const messageCell = beginCell().storeStringTail(config.message).endCell(); return beginCell().storeRef(messageCell).endCell(); } export class HelloWorldContract implements Contract { abi: ContractABI = { name: 'HelloWorldContract' } constructor(readonly address: Address, readonly init?: { code: Cell; data: Cell }) {} // creates a wrapper instance from an already-deployed contract address static createFromAddress(address: Address) { return new HelloWorldContract(address); } // derives the contract address from the compiled code and initial config, returns a deployable instance static createFromConfig(config: HelloWorldContractConfig, code: Cell, workchain = 0) { const data = helloWorldContractConfigToCell(config); const init = { code, data }; return new HelloWorldContract(contractAddress(workchain, init), init); } // sends an empty-body transaction to trigger deployment with attached TON to cover fees async sendDeploy(provider: ContractProvider, via: Sender, value: bigint) { await provider.internal(via, { value, sendMode: SendMode.PAY_GAS_SEPARATELY, body: beginCell().endCell(), }); } // encodes op code 0x1 followed by the new message as a ref cell and sends it as a transaction async sendUpdateMessage(provider: ContractProvider, via: Sender, newMessage: string) { const messageCell = beginCell().storeStringTail(newMessage).endCell(); await provider.internal(via, { value: toNano('0.05'), sendMode: SendMode.PAY_GAS_SEPARATELY, body: beginCell() .storeUint(0x1, 32) .storeRef(messageCell) .endCell(), }); } // calls get fun message() off-chain and returns the current message as a string async getMessage(provider: ContractProvider): Promise { const result = await provider.get('message', []); const slice = result.stack.readCell().beginParse(); return slice.loadStringTail(); } } ``` #### 2. Create the Deployment Script [#2-create-the-deployment-script] Open the `./scripts/deployHelloWorldContract.ts` file and replace its contents with the following script: ```typescript import { toNano } from '@ton/core'; import { HelloWorldContract } from '../wrappers/HelloWorldContract'; import { compile, NetworkProvider } from '@ton/blueprint'; export async function run(provider: NetworkProvider) { // compiles the contract, derives the address and binds it to the network provider const helloWorldContract = provider.open( HelloWorldContract.createFromConfig( { message: 'Hello, TON World!' }, await compile('HelloWorldContract') ) ); // sends an empty-body transaction with 0.05 TON to trigger deployment await helloWorldContract.sendDeploy(provider.sender(), toNano('0.05')); // polls the network until the contract address becomes active await provider.waitForDeploy(helloWorldContract.address); // reads back the stored message to verify the initial state was written correctly const result = await provider.provider(helloWorldContract.address).get('message', []); const slice = result.stack.readCell().beginParse(); const message = slice.loadStringTail(); console.log('Deployed successfully. Stored message:', message); } ``` #### 3. Run the Deploy Command [#3-run-the-deploy-command] With your contract, wrapper, and deployment script in place, deploy to testnet using the Blueprint CLI with the corresponding `.env` variables (`WALLET_MNEMONIC` and `WALLET_VERSION`): ```bash npx blueprint run deployHelloWorldContract --testnet --mnemonic ``` > If you prefer an interactive prompt to choose the script, network and wallet method, run `npx blueprint run` instead. For all available flags and options, see the [Blueprint deployment guide](https://docs.ton.org/contract-dev/blueprint/deploy). Expected output: ```bash Using file: deployHelloWorldContract Connected to wallet at address: 0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX Sent transaction Contract deployed at address kQD2P_X3OglmVY0lTog5w6d6D6gLe74p0SNmfqUXlvNzd8Cm You can view it at https://testnet.tonscan.org/address/kQD2P_X3OglmVY0lTog5w6d6D6gLe74p0SNmfqUXlvNzd8Cm Deployed successfully. Stored message: Hello, TON World! ``` Copy the deployed contract address from the output and add it to your `.env` file: ```bash CONTRACT_ADDRESS= ``` ### Interact with the Contract [#interact-with-the-contract] With your contract deployed, you can now interact with it using standalone scripts. #### Retrieve the Message [#retrieve-the-message] Create the `./scripts/getMessage.ts` file and paste the following code: ```typescript import { Address } from '@ton/core'; import { HelloWorldContract } from '../wrappers/HelloWorldContract'; import { NetworkProvider } from '@ton/blueprint'; import * as dotenv from 'dotenv'; dotenv.config(); export async function run(provider: NetworkProvider) { const address = Address.parse(process.env.CONTRACT_ADDRESS!); const helloWorldContract = provider.open(HelloWorldContract.createFromAddress(address)); // calls get fun message() off-chain and returns the current message const result = await provider.provider(helloWorldContract.address).get('message', []); const slice = result.stack.readCell().beginParse(); const message = slice.loadStringTail(); console.log('Stored message:', message); } ``` To retrieve the message, run: ```bash npx blueprint run getMessage --testnet ``` Expected output: ```bash Using file: getMessage ? Which wallet are you using? Mnemonic Connected to wallet at address: 0QCxbE7uklPfYi3LTbEvh97XTfBsUwRf5doGEV4rNHXCXAgg Stored message: Hello, TON World! ``` #### Update the Message [#update-the-message] Create the `./scripts/updateMessage.ts` file and paste the following code: ```typescript import { Address, toNano } from '@ton/core'; import { HelloWorldContract } from '../wrappers/HelloWorldContract'; import { NetworkProvider } from '@ton/blueprint'; import * as dotenv from 'dotenv'; dotenv.config(); export async function run(provider: NetworkProvider) { const address = Address.parse(process.env.CONTRACT_ADDRESS!); // prompts for the new message in the CLI const newMessage = await provider.ui().input('Enter new message:'); const helloWorldContract = provider.open(HelloWorldContract.createFromAddress(address)); // sends a transaction with the new message to the contract await helloWorldContract.sendUpdateMessage(provider.sender(), newMessage); console.log('Message updated to:', newMessage); console.log('View transaction at:', `https://testnet.tonviewer.com/${address.toString()}`); } ``` To update the message, run: ```bash npx blueprint run updateMessage --testnet ``` Expected output: ```bash Using file: updateMessage ? Which wallet are you using? Mnemonic Connected to wallet at address: 0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX ? Enter new message: hello 1111 Sent transaction Message updated to: hello 1111 View transaction at: https://testnet.tonviewer.com/EQD2P_X3OglmVY0lTog5w6d6D6gLe74p0SNmfqUXlvNzd3ss ``` --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # TON AppKit Starter (/ton/ton-appkit-starter) [TON AppKit Starter](https://github.com/thisonedev/vault/tree/master/ton-appkit-starter) is a Telegram Mini App starter kit built with [TON AppKit](https://docs.ton.org/ecosystem/appkit/overview), React, TypeScript, and Vite. Covers main AppKit features: wallet connection, balance monitoring, and TON transfers. > Runs on **testnet** by default. Switch to mainnet by changing `NETWORK` in `src/utils/constants.ts`. 01 02 *** ## Features [#features] * 💎 Connect/disconnect TON wallet via TON Connect * 📊 Real-time balance monitoring with polling * 📤 Send TON to any address with optional comment * 🔗 Transaction confirmation with Tonscan explorer link * 📱 Telegram Mini App ready — theme sync, viewport expand, safe area support * 👤 Telegram user info — name * 🌗 Light/dark mode — syncs with Telegram theme, falls back to system preference * 🌐 Works in a regular browser too *** ## Prerequisites [#prerequisites] * Node.js 18+ * A TON wallet (e.g. [Tonkeeper](https://tonkeeper.com)) with testnet mode enabled * Optional: a free [TonCenter API key](https://t.me/toncenter) for higher rate limits *** ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` https://github.com/thisonedev/vault.git ``` ### 2. Enter ton-appkit-starter directory [#2-enter-ton-appkit-starter-directory] ``` cd ton-appkit-starter ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ### 4. Configure environment [#4-configure-environment] ```bash cp .env.example .env ``` Open `.env` and fill in your values: ```bash # Optional but recommended — avoids rate limit errors TONCENTER_API_KEY= # Your app's TON Connect manifest URL # The demo manifest below works fine for local development MANIFEST_URL=https://tonconnect-sdk-demo-dapp.vercel.app/tonconnect-manifest.json ``` ## Running an app [#running-an-app] ```bash npm run dev ``` Open [http://localhost:5173](http://localhost:5173) in your browser. *** ## Running as a Telegram Mini App [#running-as-a-telegram-mini-app] Telegram requires a public HTTPS URL to load a Mini App. During development, use ngrok to tunnel your local dev server. ### 1. Start your dev server [#1-start-your-dev-server] ```bash npm run dev ``` ### 2. In a separate terminal, start ngrok [#2-in-a-separate-terminal-start-ngrok] ```bash npx ngrok http 5173 ``` Copy the `https://` URL ngrok gives you, e.g. `https://abc123.ngrok-free.app` **3. Create a Telegram bot** * Open [@BotFather](https://t.me/BotFather) on Telegram * Send `/newbot` and follow the prompts — pick a name and username * BotFather gives you a bot token — save it for later ### 4. Set the Mini App URL [#4-set-the-mini-app-url] * Send `/mybots` to BotFather * Select your bot → **Bot Settings** → **Menu Button** → **Configure menu button** * Paste your ngrok URL ### 5. Open the Mini App [#5-open-the-mini-app] * Open your bot in Telegram * Tap the **Menu** button (bottom left, next to the message input) * Your app loads as a Mini App Your app hot-reloads automatically on code changes — no need to restart ngrok or reconfigure BotFather unless the ngrok URL changes. > **Note:** Free ngrok generates a new URL every time you restart it. To keep a stable URL during development, keep ngrok running or use a paid plan with a fixed domain. > **Production:** Deploy to any static host (Vercel, Netlify, Cloudflare Pages) and set that URL in BotFather instead. *** ## Project Structure [#project-structure] ``` ton-appkit-starter/ ├── index.html # Entry point — includes Telegram WebApp script ├── vite.config.ts # Vite config with Buffer polyfill and @ alias ├── tsconfig.json # Root TypeScript config with project references ├── tsconfig.app.json # TypeScript config for src/ ├── package.json # Dependencies and scripts ├── .env.example # Environment variable template ├── .gitignore # Ignored files — node_modules, .env, dist ├── eslint.config.js # ESLint config ├── README.md # Project documentation │ └── src/ ├── main.tsx # React entry — mounts app ├── App.tsx # Root — AppKit, QueryClient, and provider setup ├── index.css # Telegram design tokens, Tailwind, global styles ├── polyfills.ts # Buffer polyfill required by @ton/core │ ├── components/ │ ├── shared/ # Reusable UI primitives │ │ ├── Card.tsx # Rounded surface container │ │ ├── CardRow.tsx # Label/value row with optional divider │ │ ├── FormField.tsx # Input with error message │ │ └── SectionTitle.tsx # Section label above cards │ │ │ ├── telegram/ # Telegram-specific components │ │ └── TelegramProvider.tsx # SDK init, theme sync, user/colorScheme context │ │ │ ├── transfer/ # Send flow │ │ ├── SendTon.tsx # Transfer form using SendTonButton │ │ └── TransactionStatus.tsx # Success/error toast with Tonscan link │ │ │ └── wallet/ # Wallet state and display │ ├── Balance.tsx # TON balance with polling │ ├── WalletConnect.tsx # Connect/disconnect button │ └── WalletInfo.tsx # Address, network badge, explorer link │ ├── hooks/ │ └── useIsConnected.ts # Returns true if a wallet is connected │ ├── types/ │ ├── index.ts # Shared TypeScript interfaces │ └── telegram.d.ts # Global type declarations for window.Telegram.WebApp │ └── utils/ ├── constants.ts # Global constants — network, URLs, intervals └── ton.ts # Helper functions — formatting, validation, API ``` *** ## Components [#components] ### `TelegramProvider` [#telegramprovider] Initialises the Telegram Mini App SDK and syncs Telegram's theme to CSS variables. Wraps the entire app so any component can access the Telegram context via `useTelegram()`. * Calls `tg.expand()` to make the app full screen * Calls `tg.ready()` to hide the native loading indicator * Listens to `themeChanged` events and updates CSS variables in real time * Exposes `isTMA`, `colorScheme`, `isReady`, and `user` via context ```tsx import { useTelegram } from '@/components/TelegramProvider'; const { isTMA, colorScheme, isReady, user } = useTelegram(); // Show Telegram username

Welcome, {user?.first_name ?? 'anon'}

``` *** ### `WalletConnect` [#walletconnect] Connect/disconnect button. Shows a connect button when no wallet is connected, and a connected state with a shortened address and disconnect option when a wallet is connected. Uses `useTonConnectUI` from `@tonconnect/ui-react` to open the TON Connect modal. *** ### `WalletInfo` [#walletinfo] Displays wallet details after connection: * Wallet app name (e.g. Tonkeeper, MyTonWallet) * Network badge — **Testnet** (yellow) or **Mainnet** (green), read from `wallet.account.chain` * Full address with tap-to-copy * Link to the wallet on Tonscan Only rendered when a wallet is connected. *** ### `Balance` [#balance] Displays the connected wallet's TON balance. Polls every `BALANCE_POLL_INTERVAL_MS` (10 seconds by default) to keep the value fresh. * Shows a skeleton loader while fetching * Shows the balance formatted to 2–4 decimal places * Shows a retry button on error Uses `useBalance()` from `@ton/appkit-react`. *** ### `SendTon` [#sendton] A transfer form with three fields: recipient address, amount (TON), and an optional comment. Uses `SendTonButton` from `@ton/appkit-react` which handles the wallet interaction internally. * Validates the recipient address format and amount before sending * Disables the button while a transaction is pending * Passes success/error results to `TransactionStatus` Only rendered when a wallet is connected. *** ### `TransactionStatus` [#transactionstatus] A toast notification shown after a send attempt. * **Success**: shows "Transaction sent" and polls the TonCenter API every 2 seconds (up to 10 attempts / 20 seconds) until it finds the transaction hash, then shows a direct Tonscan link * **Error**: shows a human-readable error message (e.g. "Transaction cancelled" instead of the raw SDK error) * Auto-dismisses after 12 seconds on success, 8 seconds on error * Can be manually dismissed with the ✕ button *** ## Switching to Mainnet [#switching-to-mainnet] Change the following values in `src/utils/constants.ts`: ```ts export const NETWORK = Network.mainnet(); export const TONCENTER_BASE_URL = 'https://toncenter.com'; export const TONSCAN_BASE_URL = 'https://tonscan.org'; ``` And update your `.env`: ```bash TONCENTER_API_KEY= ``` *** ## Tech Stack [#tech-stack] | Package | Purpose | | ----------------------- | --------------------------------------- | | `@ton/appkit-react` | AppKit React hooks and components | | `@tonconnect/ui-react` | TON Connect wallet hooks | | `@tanstack/react-query` | Data fetching and caching | | `tailwindcss` | Utility-first CSS | | `buffer` | Node.js Buffer polyfill for the browser | *** ## Resources [#resources] * [TON AppKit docs](https://docs.ton.org/ecosystem/appkit/overview) * [TON Connect manifest](https://docs.ton.org/ecosystem/ton-connect/manifest) * [TonCenter API](https://docs.ton.org/ecosystem/api/toncenter/introduction) * [Telegram Mini Apps](https://docs.ton.org/ecosystem/tma) * [Get a TonCenter API key](https://t.me/toncenter) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # TON CLI Typescript (/ton/ton-cli-typescript) [TON CLI Typescript](https://github.com/thisonedev/vault/tree/master/ton-cli-typescript) is an unofficial TypeScript CLI that demonstrates key TON use cases, including wallet creation, balance tracking, asset transfers, and more. ## Prerequisites [#prerequisites] * Node.js version 22 or later ## Setup [#setup] ### 1. Clone the repository [#1-clone-the-repository] ``` https://github.com/thisonedev/vault.git ``` ### 2. Enter ton-cli-typescript directory [#2-enter-ton-cli-typescript-directory] ``` cd ton-cli-typescript ``` ### 3. Install dependencies [#3-install-dependencies] ``` npm install ``` ### 4. Link CLI globally [#4-link-cli-globally] ``` npm link ``` ### 5. Provide environment variables [#5-provide-environment-variables] This project uses the [@chainlink/env-enc](https://www.npmjs.com/package/@chainlink/env-enc) package to encrypt `.env` variables. First, set a password for encrypting and decrypting the environment variable file: ```bash npx env-enc set-pw ``` > Note: you'll need to set a password for each terminal session, but this will not affect or remove your existing variables. Next, set the required environment variables: ``` TESTNET_API_KEY= MAINNET_API_KEY= WALLET_MNEMONIC= TONAPI_KEY= ``` | Variable | Required | Description | | ----------------- | -------- | ------------------------------------------------------------------------------------------- | | `TESTNET_API_KEY` | Yes | Toncenter testnet API key. [Register here](https://testnet.toncenter.com/) | | `MAINNET_API_KEY` | Yes | Toncenter mainnet API key. [Register here](https://toncenter.com/) | | `WALLET_MNEMONIC` | No | 24-word wallet mnemonic. Used as default for commands that require signing | | `TONAPI_KEY` | No | TON API key for enriched data (events, jettons, NFTs). Requests are rate-limited without it | To set these variables, run: ```bash npx env-enc set ``` The `.env.enc` file will be generated automatically. To validate your inputs: ```bash npx env-enc view ``` *** ## Usage [#usage] ```bash ton-cli [args] ``` *** ## Commands [#commands] * [create-wallet](#create-wallet) * [initialize-wallet](#initialize-wallet) * [send-ton](#send-ton) * [get-wallet-info](#get-wallet-info) * [get-wallet-assets](#get-wallet-assets) * [get-transaction](#get-transaction) * [get-tx-history](#get-tx-history) * [get-jetton-info](#get-jetton-info) *** ## create-wallet [#create-wallet] Generates a new TON wallet keypair and mnemonic. Does not deploy anything on-chain. ```bash ton-cli create-wallet --network ``` | Flag | Type | Required | Default | Description | | --------- | ---------------------- | -------- | --------- | ------------------------------------------ | | `network` | `testnet` \| `mainnet` | No | `testnet` | Network to generate the wallet address for | After your wallet is created, store the mnemonic in a safe place and add it to `.env.enc` using `npx env-enc set`.
Example output ``` Generating new TON wallet on testnet... === NEW TON WALLET CREATED === ──────────────────────────────────────────────────────────── Network : testnet Address : 0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX Bounceable : kQDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnViS Public Key : 392e498f5864de36c821b8881045bd583d2cb749cf69da2429e1cffa5d738e95 Private Key : dd812567ea642b7ba7bc438ba136bd3f5f2160965a7df805f87d3d4c13f4eb76392e498f5864de36c821b8881045bd583d2cb749cf69da2429e1cffa5d738e95 Mnemonic : hope roof wagon ability sell force cruel valley dizzy spider impulse fame another wheat menu dinner armed because labor mask fly bike mutual book ⚠️ Save your mnemonic — it cannot be recovered! Explorer : https://testnet.tonviewer.com/0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX ```
*** ## initialize-wallet [#initialize-wallet] Initializes the wallet by deploying the wallet smart contract on-chain and making a self-transfer with `stateInit`. > TON is an account-based blockchain, but unlike Ethereum, accounts do not exist on-chain until a smart contract is deployed to that address. ```bash ton-cli initialize-wallet --network --mnemonic "" ``` | Flag | Type | Required | Default | Description | | ---------- | ---------------------- | -------- | ------------------------- | ---------------------------------------------------------------------------------------------------------- | | `network` | `testnet` \| `mainnet` | No | `testnet` | Network to initialize the wallet on | | `mnemonic` | `string` | No | `WALLET_MNEMONIC` env var | 24-word wallet mnemonic. Prefer the env var — passing this flag exposes the mnemonic in your shell history | To fund your testnet wallet before initializing, use one of these faucets: * [Test Giver bot](https://t.me/testgiver_ton_bot) * [Chainstack faucet](https://faucet.chainstack.com/ton-testnet-faucet)
Example output ``` Network : testnet Address : 0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX Bounceable : kQDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnViS Explorer : https://testnet.tonviewer.com/0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX Balance : 2.0000 TON Initializing... Confirming. ✅ Wallet initialized! Seqno: 1 ```
*** ## send-ton [#send-ton] Sends TON coins to any address with an optional text comment. ```bash ton-cli send-ton --to
--amount --network --comment --mnemonic "" ``` | Flag | Type | Required | Default | Description | | ---------- | ---------------------- | -------- | ------------------------- | ------------------------------------------------------------------------------------------------------------- | | `to` | `string` | Yes | — | Destination TON address | | `amount` | `number` | Yes | — | Amount to send in TON, e.g. `0.5` | | `network` | `testnet` \| `mainnet` | No | `testnet` | Network to broadcast the transaction on | | `comment` | `string` | No | — | Optional text memo attached to the transfer | | `mnemonic` | `string` | No | `WALLET_MNEMONIC` env var | 24-word wallet mnemonic. ⚠️ Prefer the env var — passing this flag exposes the mnemonic in your shell history |
Example output ``` Sending TON on testnet... ──────────────────────────────────────────────────────────── From : 0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX To : 0QARNjsmX66SBIdYS6_z7tyS1xkam-h1BLr7GtRlO6RkKMF7 Amount : 0.0011 TON ──────────────────────────────────────────────────────────── Waiting for confirmation. ✅ Sent 0.0011 TON to 0QARNjsmX66SBIdYS6_z7tyS1xkam-h1BLr7GtRlO6RkKMF7 Explorer : https://testnet.tonviewer.com/transaction/052700fd67cd972d53b1bf39e4033cae0023241e89a46c248c9564d15c7e806a ```
*** ## get-wallet-info [#get-wallet-info] Displays balance, status, and last transaction details for any TON address. ```bash ton-cli get-wallet-info --address
--network ``` | Flag | Type | Required | Default | Description | | --------- | ---------------------- | -------- | --------- | ---------------------- | | `address` | `string` | Yes | — | TON address to look up | | `network` | `testnet` \| `mainnet` | No | `testnet` | Network to query |
Example output ``` Wallet Info ──────────────────────────────────────────────────────────── Network : testnet Status : active Balance : 1.9897 TON Address : 0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX Bounceable : kQDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnViS Last Tx Hash: BScA/WfNly1Tsb855AM8rgAjJB6JpGwkjJVk0Vx+gGo= Last Tx Lt : 54367726000001 Explorer : https://testnet.tonviewer.com/0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX ──────────────────────────────────────────────────────────── ```
*** ## get-wallet-assets [#get-wallet-assets] Lists all jettons and NFTs held by a TON address. ```bash ton-cli get-wallet-assets --address
--network --limit --jettons-limit --nft-limit ``` | Flag | Type | Required | Default | Description | | --------------- | ---------------------- | -------- | ------------------ | ------------------------------------------------------ | | `address` | `string` | Yes | — | TON address to look up | | `network` | `testnet` \| `mainnet` | No | `testnet` | Network to query | | `limit` | `number` | No | `10` | Max results for both jettons and NFTs. Capped at `100` | | `jettons-limit` | `number` | No | value of `--limit` | Override max number of jettons to display | | `nft-limit` | `number` | No | value of `--limit` | Override max number of NFTs to display |
Example output ``` Wallet Assets — UQBmzW4wYlFW0tiBgj5sP1CgSlLdYs-VpjPWM7oPYPYWQBqW Network: mainnet ── Jettons ───────────────────────────────────────────────── DONT 12345.00 DONKEY TON Minter : EQBh0GTe1QrRDfBb3zF_5131ykR64T0y9aIy2LygDt0iWUNx Link : https://tonviewer.com/EQBh0GTe1QrRDfBb3zF_5131ykR64T0y9aIy2LygDt0iWUNx ATF 30.00 AI Trading Forex Minter : EQANcW45W0Tp91bzvHayaPO6-6hf1Lm4XlWZ4rN6L5ofPWdb Link : https://tonviewer.com/EQANcW45W0Tp91bzvHayaPO6-6hf1Lm4XlWZ4rN6L5ofPWdb ... and 107 more ── NFTs ──────────────────────────────────────────────────── BTC Monkey #0095 Collection : Mining $VWS Address : EQClp9ttASdPf_Sg0VruuEVLZXJTkwbmcUDxZOyiEa8Ezz9a ... and 88 more ──────────────────────────────────────────────────────────── ```
*** ## get-transaction [#get-transaction] Fetches full details for a single transaction by its hash, including inbound and outbound messages. ```bash ton-cli get-transaction --hash --network ``` | Flag | Type | Required | Default | Description | | --------- | ---------------------- | -------- | --------- | --------------------- | | `hash` | `string` | Yes | — | Full transaction hash | | `network` | `testnet` \| `mainnet` | No | `testnet` | Network to query |
Example output ``` Transaction 052700fd67cd972d53b1bf39e4033cae0023241e89a46c248c9564d15c7e806a ──────────────────────────────────────────────────────────── Time : 2026-03-10 04:56:02 Status : ✅ Success Account : 0QDklMt_wtJATm1lc5e2ro0vFalpcodx_0NCKcIovjFsnQVX Fees : 0.002808 TON ← In : from external op=1936287598 Body : {"wallet_id":2147483645,"valid_until":1773118622,"seqno":1,...} → Out : -0.0011 TON to 0QARNjsmX66SBIdYS6_z7tyS1xkam-h1BLr7GtRlO6RkKMF7 ──────────────────────────────────────────────────────────── Link : https://testnet.tonviewer.com/transaction/052700fd67cd972d53b1bf39e4033cae0023241e89a46c248c9564d15c7e806a ```
*** ## get-tx-history [#get-tx-history] Shows recent transactions for any TON address, with action-level breakdown for each event. ```bash ton-cli get-tx-history --address
--limit --network ``` | Flag | Type | Required | Default | Description | | --------- | ---------------------- | -------- | --------- | ------------------------------------------------ | | `address` | `string` | Yes | — | TON address to look up | | `network` | `testnet` \| `mainnet` | No | `testnet` | Network to query | | `limit` | `number` | No | `10` | Number of transactions to fetch. Capped at `100` |
Example output ``` Transactions for 0QARNjsmX66SBIdYS6_z7tyS1xkam-h1BLr7GtRlO6RkKMF7 Network: testnet | Showing last 5 ──────────────────────────────────────────────────────────── 🕐 2026-03-08 02:31:59 Status : ✅ Success Event : d1f62514b12fd5b88e537e60b2089a2c9af63a9b1a86ce421eda2f675a46bba8 ✅ TON Transfer 4.4000 TON From : 0QAnWvFxPJpl4k_4VSmsGYCTZqP1IcQC547UYsNorrq8OToZ To : 0QARNjsmX66SBIdYS6_z7tyS1xkam-h1BLr7GtRlO6RkKMF7 Net : 0.000310278 TON spent Link : https://testnet.tonviewer.com/transaction/d1f62514b12fd5b88e537e60b2089a2c9af63a9b1a86ce421eda2f675a46bba8 ──────────────────────────────────────────────────────────── 🕐 2026-03-07 14:26:25 Status : ❌ Failed Event : 52172c31c32c5a0b1b87542b549f30894993fc47ed9328c8e9a87e48dcfc5edb ❌ Failed Contract Call op=0x00000003 0.0500 TON From : 0QARNjsmX66SBIdYS6_z7tyS1xkam-h1BLr7GtRlO6RkKMF7 To : 0QDIns5_fS6-WFWL4G5N_7UX8bI1e_hWcA3pSDjhuUYYHPP- Net : 0.052636402 TON spent Link : https://testnet.tonviewer.com/transaction/52172c31c32c5a0b1b87542b549f30894993fc47ed9328c8e9a87e48dcfc5edb ──────────────────────────────────────────────────────────── ```
*** ## get-jetton-info [#get-jetton-info] Returns jetton metadata and supply, or all jettons owned by a given address. ```bash ton-cli get-jetton-info --address
--network ``` | Flag | Type | Required | Default | Description | | --------- | ---------------------- | -------- | --------- | --------------------------------------------------------------------------------- | | `address` | `string` | Yes | — | Jetton minter address for token info, or any wallet address to list owned jettons | | `network` | `testnet` \| `mainnet` | No | `testnet` | Network to query |
Example output — jetton info by minter address ``` Jetton Info ──────────────────────────────────────────────────────────── Name : Notcoin Symbol : NOT Decimals : 9 Supply : 102,452,755,868.521 NOT Mintable : Yes Admin : renounced Minter : EQAvlWFDxGF2lXm67y4yzC17wYKD9A0guwPkMs1gOsM__NOT Image : https://cdn.joincommunity.xyz/clicker/not_logo.png Holders : 2,846,667 ──────────────────────────────────────────────────────────── Explorer : https://tonviewer.com/EQAvlWFDxGF2lXm67y4yzC17wYKD9A0guwPkMs1gOsM__NOT ```
Example output — jettons owned by wallet address ``` Jettons owned by UQBmzW4wYlFW0tiBgj5sP1CgSlLdYs-VpjPWM7oPYPYWQBqW ──────────────────────────────────────────────────────────── DONT 12,345 DONKEY TON Minter : EQBh0GTe1QrRDfBb3zF_5131ykR64T0y9aIy2LygDt0iWUNx Link : https://tonviewer.com/EQBh0GTe1QrRDfBb3zF_5131ykR64T0y9aIy2LygDt0iWUNx ATF 30 AI Trading Forex Minter : EQANcW45W0Tp91bzvHayaPO6-6hf1Lm4XlWZ4rN6L5ofPWdb Link : https://tonviewer.com/EQANcW45W0Tp91bzvHayaPO6-6hf1Lm4XlWZ4rN6L5ofPWdb ──────────────────────────────────────────────────────────── ```
--- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve mids for all coins (/api/retrieveMidsForAllCoins) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a user's open orders (/api/retrieveUsersOpenOrders) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a user's open orders with additional frontend info (/api/retrieveUsersOpenOrdersWithFrontendInfo) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a user's fills (/api/retrieveUsersFills) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a user's fills by time (/api/retrieveUsersFillsByTime) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query user rate limits (/api/queryUserRateLimits) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query order status by oid or cloid (/api/queryOrderStatusByOidOrCloid) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # L2 book snapshot (/api/l2BookSnapshot) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Candle snapshot (/api/candleSnapshot) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Check builder fee approval (/api/checkBuilderFeeApproval) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a user's historical orders (/api/retrieveUsersHistoricalOrders) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a user's TWAP slice fills (/api/retrieveUsersTwapSliceFills) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a user's subaccounts (/api/retrieveUsersSubaccounts) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve details for a vault (/api/retrieveDetailsForAVault) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a user's vault deposits (/api/retrieveUsersVaultDeposits) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's role (/api/queryUsersRole) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's portfolio (/api/queryUsersPortfolio) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's referral information (/api/queryUsersReferralInformation) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's fees (/api/queryUsersFees) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's staking delegations (/api/queryUsersStakingDelegations) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's staking summary (/api/queryUsersStakingSummary) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's staking history (/api/queryUsersStakingHistory) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's staking rewards (/api/queryUsersStakingRewards) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's HIP-3 DEX abstraction state (/api/queryUsersHip3DexAbstractionState) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query a user's abstraction state (/api/queryUsersAbstractionState) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query aligned quote token status (/api/queryAlignedQuoteTokenStatus) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query borrow/lend user state (/api/queryBorrowLendUserState) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query borrow/lend reserve state (/api/queryBorrowLendReserveState) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query all borrow/lend reserve states (/api/queryAllBorrowLendReserveStates) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Query approved builders for user (/api/queryApprovedBuildersForUser) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve spot metadata (/api/retrieveSpotMetadata) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve spot asset contexts (/api/retrieveSpotAssetContexts) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a user's token balances (/api/retrieveUserTokenBalances) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve information about the Spot Deploy Auction (/api/retrieveSpotDeployAuction) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve information about the Spot Pair Deploy Auction (/api/retrieveSpotPairDeployAuction) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve information about a token (/api/retrieveTokenDetails) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve outcome metadata (testnet-only) (/api/retrieveOutcomeMeta) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Place an order (/api/placeOrder) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Cancel order(s) (/api/cancelOrders) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Cancel order(s) by cloid (/api/cancelOrdersByCloid) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Schedule cancel (dead man's switch) (/api/scheduleCancel) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Modify an order (/api/modifyOrder) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Modify multiple orders (/api/modifyMultipleOrders) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Place a TWAP order (/api/placeTwapOrder) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Cancel a TWAP order (/api/cancelTwapOrder) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Update leverage (/api/updateLeverage) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Update isolated margin (/api/updateIsolatedMargin) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Core USDC transfer (/api/coreUsdcTransfer) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Core spot transfer (/api/coreSpotTransfer) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Initiate a withdrawal request (/api/initiateWithdrawal) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Transfer from Spot account to Perp account (and vice versa) (/api/transferSpotToPerp) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Send Asset (/api/sendAsset) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Send to EVM with data (/api/sendToEvmWithData) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Deposit into staking (/api/depositIntoStaking) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Withdraw from staking (/api/withdrawFromStaking) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Delegate or undelegate stake from validator (/api/delegateStake) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Claim rewards (/api/claimRewards) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Deposit or withdraw from a vault (/api/vaultTransfer) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Approve an API wallet (/api/approveApiWallet) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Approve a builder fee (/api/approveBuilderFee) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Reserve Additional Actions (/api/reserveRequestWeight) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Invalidate Pending Nonce (noop) (/api/invalidatePendingNonce) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Set User Abstraction (/api/setUserAbstraction) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Set User Abstraction (agent) (/api/setAgentAbstraction) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Enable HIP-3 DEX abstraction (/api/enableUserDexAbstraction) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Enable HIP-3 DEX abstraction (agent) (/api/enableAgentDexAbstraction) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Validator vote on risk-free rate for aligned quote asset (/api/validatorVoteRiskFreeRate) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Provide alarms related to system memory, CPU, and storage usage, as well as application-specific alarms (/api/alarm_get) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Provide configuration values (/api/configuration_get) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Return the balance of each currency for the given account address (/api/account_get_balance) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get all utxos belonging to the given address (/api/account_get_utxos) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get a list of transactions for the given account address (/api/account_get_transactions) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve a specific block from the child chain using the hash that was published on the root chain (/api/block_get) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get all blocks (can be limited with various filters) (/api/block_all) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get a paginated list of deposits for the given address (/api/deposit_all) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get all transactions (can be limited with various filters) (/api/transactions_all) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Find an optimal way to construct a transaction that spends a specific amount (/api/createTransaction) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get a transaction with the given ID (/api/transaction_get) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Send an EIP-712-formatted transaction to the child chain (/api/submit_typed) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve the list of fee tokens currently supported by the child chain, along with the current amount needed to perform a transaction (/api/fees_all) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Retrieve network statistics (/api/stats_get) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Send a transaction to the child chain (/api/submit) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Return information about the current state of the child chain and the watcher (/api/status_get) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get all utxos belonging to the given address (/api/account_get_exitable_utxos) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get challenge data for a given utxo exit (/api/utxo_get_challenge_data) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get exit data for a given utxo (/api/utxo_get_exit_data) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get exit data for an in-flight exit (/api/in_flight_exit_get_data) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Return a competitor to an in-flight exit (/api/in_flight_exit_get_competitor) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Prove that a transaction is canonical (/api/in_flight_exit_prove_canonical) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get the data to challenge an invalid input piggybacked on an in-flight exit (/api/in_flight_exit_get_input_challenge_data) --- > For the complete documentation index, see [llms.txt](/llms.txt). A full-text snapshot is also available at [llms-full.txt](/llms-full.txt). # Get the data to challenge an invalid output piggybacked on an in-flight exit (/api/in_flight_exit_get_output_challenge_data)