# Introduction DAGS was originally founded in 2016 with the primary vision of creating a cryptocurrency focused on usability and serving as a reliable medium of exchange. The objective was to develop a highly scalable and efficient system that could facilitate seamless transactions without the inefficiencies that plagued traditional blockchain networks. For years, the focus remained on building and refining a technology that would enable fast and cost-effective transactions, making it a practical solution for everyday financial interactions. However, as the project evolved and the token was listed on exchanges in 2023, new challenges emerged. The volatility of the market made it increasingly difficult to maintain the original emphasis on usability. Fluctuations in token price discouraged users from relying on it as a stable means of transaction, as the unpredictable nature of its valuation made it impractical for real-world commercial use. The project had always been driven by the ambition of widespread adoption, but the reality of market dynamics made it evident that an alternative approach was necessary. Recognizing the need for a more balanced and sustainable system, the team took a step back to reevaluate how to best move forward while maintaining the integrity of the project's founding principles. This reflection led to the realization that separating usability and price increase aspects would be the best way to ensure both the long-term growth of the ecosystem and the practical adoption of the technology. # DAGS + SDAG ### **The Transition to a Two-Token Model: DAGS and SDAG** At the beginning of 2025, a strategic decision was made to transition towards a dual-token model. This approach was designed to accommodate the interests of both holders looking for price appreciation and users who were committed to the original vision of DAGS as a medium of exchange. The introduction of a two-coin system allows the project to align with the needs of both these groups without compromising the core technological advancements that had been developed over the years. Under this new model, the existing token has now transitioned into a deflationary asset, designed to reward early adopters and long-term holders through mechanisms that systematically reduce the supply, thereby increasing scarcity and fostering price appreciation. Various burning mechanisms, including transaction-based burns, scheduled supply reductions, and utility-based burns, ensure that the tokenomics support long-term value growth, making it an attractive store of value. This deflationary structure ensures that every transaction contributes to decreasing the circulating supply, strengthening the incentive for holders to keep their tokens rather than spend them. At the same time, to uphold the original mission of creating a cryptocurrency that is practical for daily transactions, the team is launching SDAG, a stablecoin that is built on the same advanced DAG technology. This new stablecoin provides the same benefits of scalability, fast transaction speeds, and low-cost transfers, but with the crucial advantage of price stability. The introduction of SDAG allows the project to refocus efforts on usability and merchant adoption, ensuring that those who initially joined the ecosystem for its vision of practical cryptocurrency applications now have an optimized solution. Unlike the deflationary coin, SDAG is specifically designed for seamless everyday use, making it an ideal choice for merchants and consumers alike who need consistency in pricing for transactions. The stability of SDAG ensures that businesses and individuals can transact with confidence, eliminating the risks associated with fluctuating asset prices. This dual-token approach offers a win-win solution by enabling long-term investors and early adopters to benefit from price appreciation through the deflationary token while allowing merchants and everyday users to engage with a stable, scalable, and efficient digital currency. Both tokens leverage the same underlying DAG technology, maintaining efficiency and transaction speed while allowing the ecosystem to expand in two different directions. Usability-focused adoption becomes significantly easier with the introduction of SDAG, as stablecoins are the dominant form of cryptocurrency used in real-world transactions. By implementing this model, the project ensures that it remains adaptable to market conditions while staying true to its founding principles. The transition to a two-coin system strengthens the ecosystem by making it more inclusive, providing something of value for both speculative investors and practical users alike. Moving forward, the project is fully committed to developing and promoting both assets. The deflationary coin continues to be in circulation, benefiting from ongoing burn mechanisms that enhance its scarcity and value proposition. Meanwhile, SDAG is set to launch soon, paving the way for broader adoption through strategic partnerships and integrations with merchants, businesses, and DeFi platforms. This new phase marks a significant milestone in the evolution of DAGS, solidifying its position as both a store of value and a practical means of exchange in the cryptocurrency space. By addressing the shortcomings of volatility while maintaining technological superiority, the two-coin system ensures that the ecosystem remains robust, scalable, and future-proof. This is not just an adjustment to tokenomics, but a fundamental shift in how the project approaches usability, adoption, and long-term sustainability and value creation. # Roadmap 2025-2026 The key milestones for DAGS deflationary token. ### **2025 Q1** **✅** Early Adopters' Burn Incentive\ **✅** TAG Markets Usability Partnership\ **✅** DAGS move to deflationary model\ **✅** SDAG introduction\ **✅** Excess Burn 500m\ **✅** Excess Burn 500m\ 🟡 Integration to web3 (metaverse) ### **2025 Q2** **✅** Excess Burn 500m\ 🟡 Transaction fee burn model ### **2025 Q3** **✅** Final excess burn 4b\ **✅** Webpage updates incl. burn monitoring\ 🟡 Additional exchange listing\ 🟡 Travel platform Usability Partnership ### **2025 Q4+** Swap across chains\ Decentralized exchange listing\ Staking pools\ Collateral fund (timeline subject to license approval)\ Tier 1 exchange (subject to approval)\ New Usability Partnerships (TBA) # Burn milestones Our focus for the coming years is clear: consistently reduce the supply by burning as many tokens as possible. Each milestone reflects the cumulative tokens removed from the 3.5B supply through various incentive mechanisms.\
* [x] 25 000 000 * [x] 50 000 000 * [x] 75 000 000 * [x] 100 000 000 * [ ] 125 000 000 * [ ] 150 000 000 * [ ] 175 000 000 * [ ] 200 000 000 * [ ] 225 000 000 * [ ] 250 000 000 * [ ] 275 000 000 * [ ] 300 000 000 * [ ] 325 000 000 * [ ] 350 000 000 * [ ] 375 000 000 * [ ] 400 000 000 * [ ] 425 000 000 * [ ] 450 000 000 * [ ] 475 000 000 * [ ] 500 000 000\ ... * [ ] 1 000 000 000\ ... * [ ] 1 500 000 000\ ... * [ ] 2 000 000 000\ ... * [ ] 2 500 000 000\ ... * [ ] 3 000 000 000 # Deflationary model ### **Understanding the Deflationary Model in Cryptocurrency** In early 2025, DAGS adopted a deflationary model, a monetary approach that systematically reduces token supply over time. Unlike inflationary cryptocurrencies, which have mechanisms that increase supply (such as continuous mining or staking rewards), deflationary cryptocurrencies are designed to become scarcer over time. ### **Inflation vs. Deflation in Economics and Cryptocurrencies** To understand deflationary cryptocurrencies, it’s important to first grasp the broader economic principles of inflation and deflation: Inflation occurs when the total supply of money or assets increases, reducing purchasing power over time. This often leads to higher prices, as seen with traditional fiat currencies when central banks print more money. Deflation is the opposite — it happens when supply decreases, leading to increased purchasing power and potential price appreciation due to scarcity. In traditional finance, controlled inflation (e.g., 2% per year) is often seen as beneficial for economic growth. However, excessive inflation devalues savings and wages. In contrast, assets with fixed supply, such as Bitcoin with its supply of 21 million coins, are valued for their scarcity, making them attractive as long-term stores of value. Deflationary cryptocurrencies take this principle further by actively reducing supply over time through mechanisms like token burns, which permanently remove tokens from circulation. ### **Advantages of Deflationary Models** Value Appreciation\ By design, deflationary tokens increase in value as supply decreases, assuming demand remains stable or grows. This makes them attractive speculative investments. Scarcity Factor\ Similar to Bitcoin’s capped supply, deflationary models rely on digital scarcity to attract investors looking for long-term gains. Incentivized Holding\ As supply reduces, users are encouraged to HODL rather than sell, decreasing sell pressure and potentially leading to price stability. ### **Challenges of Deflationary Models** Volatility Risks\ While deflation reduces supply, market demand remains unpredictable, which can lead to significant price swings. This is a common challenge across all non-stable cryptocurrencies. Sustainability Issues\ Some deflationary models rely solely on transaction-based burns, which may not be sustainable if transaction volume declines. A robust deflationary model should include additional incentives for users to hold and participate in the ecosystem. Reduced Economic Activity\ If token holders prioritize long-term price appreciation over spending, it could slow usability growth. However, in projects where store of value is the priority, this is a feature, not a flaw. Limited Utility for Usability\ Deflationary models do not work well for stablecoins or payment-focused cryptocurrencies, as they conflict with the goal of maintaining a stable price. ### **Best Applications for Deflationary Cryptos - Store of Value** Similarly to gold or Bitcoin, deflationary cryptocurrencies perform best as stores of value rather than day-to-day payment methods. Deflationary cryptocurrencies present a compelling alternative to traditional financial models, leveraging scarcity to drive value. However, they require careful economic design, sustainability planning, and strategic implementation to succeed. When well-executed, deflationary models can create long-term value and attract a dedicated community of users and investors. # Contracts ### **BNB SMART CHAIN** BEP20 contract: \ 0x96fD3F8D5689C0C1691D93e7A1E8C892a2A79D73\ \ BSC Scan link:\ \
# Tokenomics Total Supply: 9,000,000,000 • Excess Supply Burn: 5,500,000,000 (61.1% burned) 🔥 Remaining Supply After Burn: 3,500,000,000 • 85.7% Distributed to Early Adopters: 3,000,000,000 • 14.3% Undistributed Supply: 500,000,000 \ Allocation for the Remaining 14.3% (500M Tokens, 5.55% from initial supply) | Category | Allocation % | Token Amount | Purpose | | ----------------------------- | ------------ | ------------ | ------------------------------------------------------------------------------- | | Ecosystem & Partnerships | 2.22% | 200M | Used for ecosystem growth, partnerships, integrations, and incentivizing burns. | | Development & Innovation Fund | 1.39% | 125M | Supports continuous development, feature upgrades, and research. | | Liquidity & Market Making | 0.83% | 75M | Provides liquidity on exchanges, reducing price volatility. | | Operational Reserve | 1.11% | 100M | Covers operational costs, unforeseen expenses, and strategic growth needs. |
✅ Ecosystem & Partnerships (2.22%) Allocated for onboarding projects, DeFi integrations, or incentivizing holders to burn the token. Helps to increase the burning and expand the utility of the token. ✅ Development & Innovation Fund (1.39%) Funds new features, protocol upgrades, and technological improvements. ✅ Liquidity & Market Making (0.83%) Ensures enough liquidity in both centralized and decentralized exchanges (CEX/DEX). Helps maintain healthy price stability and reduces major price fluctuations. ✅ Operational Reserve (1.11%) Covers unexpected project costs, team expansion, and strategic partnerships.\ Acts as a security cushion to sustain operations over time. # Burn schedule Schedule for excess supply burn: **✅** February 2025 - 500 000 000 DAGS **✅** March 2025 - 500 000 000 DAGS **✅** April 2025 - 500 000 000 DAGS **✅** May 2025 - 500 000 000 DAGS **✅** June 2025 - 500 000 000 DAGS **✅** July 2025 - 500 000 000 DAGS **✅** August 2025 - 500 000 000 DAGS **✅** September 2025 - 500 000 000 DAGS **✅** October 2025 - 500 000 000 DAGS **✅** November 2025 - 500 000 000 DAGS **✅** December 2025 - 500 000 000 DAGS # Proof of Burn ### **DAGCHAIN** The DAGS native token on DAGChain is designed without burn or mint functions, meaning the only way to permanently remove tokens from circulation is by sending them to a burn wallet — an address that is inaccessible and cannot be used to recover tokens. However, regular wallets have built-in security checks that prevent users from sending tokens to invalid addresses. This makes it impossible to transfer DAGS directly to the burn wallet address we would like to use, using a standard wallet application, as the desired address does not exist and the wallets are not allowing users to send a transfer to an invalid address. To solve this, we aim to utilize a headless wallet — a specialized system that can execute transactions without a graphical interface. This allows developers to bypass the security checks in regular wallet applications and send a transfer to an address that is invalid. The burning process follows these steps:\ 1️⃣ Tokens are first sent to a “pre-burn” address (a temporary holding address).\ 2️⃣ From the pre-burn address, the tokens are then sent to the burn address, which is an invalid and inaccessible address, ensuring they are permanently removed from circulation. This process guarantees that burned DAGS are truly gone forever, reducing supply and reinforcing the token’s value through scarcity. **NB: We are still testing to be sure the invalid address does not cause any unexpected issues to the network. Once these tests are completed we will notify you and commence the burn from the pre-burn address.**\ \ Pre-burn wallet: EQ47EQTJVY4DTKAKHIETQQYPOW37GEPI\ Dagchain explorer link to pre-burn address: \ \ Burn address: OOOOOOOOOOOOOOOOOOOOOOOOBURN (Desired and in testing)\ Dagchain explorer link to burn address: *Added shortly..* ### **BEP20** The DAGS BEP20 contract includes a built-in burn function, allowing tokens to be burned. However, since the contract also has a mint function, any burned tokens could technically be brought back into circulation. This means that the standard burn mechanism does not permanently remove tokens from the supply. To ensure a definitive and irreversible reduction in circulating supply, we utilize a burn wallet (a wallet with no private key, making it impossible to retrieve tokens). By sending tokens to this burn wallet, they are permanently removed from circulation, effectively reducing supply and supporting the token’s price through scarcity. This method guarantees that burned tokens can never be minted back, ensuring a true deflationary effect. BEP20 widely known burn address: 0x000000000000000000000000000000000000dEaD\ BSC Scan link to burned DAGS:\ # Burn mechanisms ### What is a token burn? Token burning is the process of permanently removing tokens from circulation to reduce supply. This is done by sending tokens to an unrecoverable wallet (burn address), ensuring they can never be accessed or spent again. ### **What is a burn wallet?** A burn wallet (or burn address) is a special crypto wallet address where tokens are sent permanently to remove them from circulation. Once tokens are sent to a burn address, they cannot be recovered because no one has the private keys to access them. **Deflationary mechanisms enable unique economic incentives. For example:** • Transaction-based burns reduce supply with each transaction\ • Burn incentives that reward early adopters and reduce circulating supply benefitting all holders\ • Community burns that incentivize buying and burning for additional benefits # Excess supply burn ### **Excess Supply Burning: Strengthening Token Value** Excess supply burning is a strategic mechanism used to reduce the total token supply by eliminating unused or surplus tokens. This process is designed to prevent inflation, enhance scarcity, and maintain price stability, ensuring long-term sustainability of the token economy. Unlike transaction-based burns (which occur on every transaction) or utility-based burns (linked to spending), excess supply burn is a macroeconomic tool used to target large, unused, or over-allocated token reserves at regular intervals or based on specific triggers. ### When do Projects Burn Excess Supply If a project has an excess reserve of tokens (e.g., unused or not allocated tokens or ecosystem funds), it can burn them to prevent unnecessary future inflation The initial token supply is large, and not all tokens are needed for active circulation The project wants to systematically reduce inflation and increase scarcity over time ### Key Benefits of Excess Supply Burning Deflationary Impact: Increases token scarcity and long-term value Prevents Market Oversupply: Avoids inflationary dilution Improves Long-Term Stability: Reduces price volatility and inflation risks Boosts Investor Confidence: Builds trust and enhances demand Attracts Long-Term Holders: Holders benefit from reduced supply over time # Transaction fee burn ### What is Transaction Fee Burning? Transaction fee burning is a mechanism where a portion of the transaction fees collected from network activity is permanently removed from circulation. Instead of rewarding miners, validators, or the protocol treasury with the full fee, a percentage is “burned” to reduce the total token supply over time. This method is commonly used in deflationary tokenomics to counterbalance inflation, increase scarcity, and drive long-term token value. ### Why Implement Transaction Fee Burning? 1\. Maintains Continuous Deflation\ Unlike scheduled supply burns, transaction fee burning occurs dynamically with every network transaction.\ The more activity on the network, the more tokens are burned, ensuring a continuous deflationary effect. 2\. Creates a Self-Sustaining Economy\ High demand for network usage (transactions) leads to more burns.\ This means that as adoption grows, token scarcity naturally increases, benefiting long-term holders. 3\. Aligns Incentives Between Users and Holders\ Users pay fees as part of using the network.\ Long-term holders benefit because the supply decreases with every transaction, potentially increasing token value over time. 4\. Combats Inflationary Pressures\ If a token has staking or emissions-based rewards, fee burning helps offset inflation by removing excess supply.\ *Example: Ethereum burns a portion of gas fees to balance issuance from staking rewards.* ### How Does Transaction Fee Burning Work? 1\. A transaction occurs on the network (e.g., payment, smart contract execution).\ 2\. Users pay a transaction fee to process the transaction.\ 3\. A portion of the fee is burned, permanently removing tokens from circulation.\ 4\. The remaining fee is distributed to validators, miners, or the protocol treasury.
Exact model for DAGS transaction fee burning is yet to be decided. Here is an example breakdown: Total Transaction Fee:\ • Burn Percentage: 30% of the fee is burned\ • Remaining 70% goes to witnesses (validators) as rewards. As more transactions occur, the burning effect compounds, reducing total supply over time. ### Benefits of Transaction Fee Burning Sustainable Deflation → Continuous supply reduction without relying on periodic burns. Increased Token Scarcity → The more network usage, the scarcer the token becomes. Supports Long-Term Price Appreciation → Less supply often leads to increased value. Encourages High Network Activity → More transactions = more burning = better ecosystem value. Transaction Flow → User pays a fee → Portion is burned → Supply decreases. # Early Adopters Burn Incentive To further reward our early adopters and provide a strong incentive to participate in the deflationary ecosystem, we have introduced the Early Adopters Burn Incentive. This program is exclusively available to whitelisted early adopters, allowing them to burn their DAGS in exchange for marketplace credits that can be redeemed for products and services. By offering this mechanism, we ensure that our early supporters are not only able to benefit from the long-term price appreciation of DAGS but also gain immediate, tangible value from their holdings. The key advantage of this program lies in the market value multiplier, which enhances the benefits of participating in the burn process. This multiplier ensures that early adopters receive more value in marketplace credits than the equivalent value of the DAGS tokens they burn. For example, burning a specific amount of DAGS could grant significantly higher purchasing power within the marketplace, making it a compelling and rewarding incentive to participate in the deflationary model. This approach creates a dynamic ecosystem where early adopters are actively encouraged to contribute to reducing the overall supply of DAGS while simultaneously enjoying enhanced value through the marketplace. By balancing long-term appreciation with short-term usability incentives, we ensure that our community benefits at multiple levels. This mechanism also strengthens the overall sustainability of the ecosystem, reinforcing both the deflationary nature of DAGS and the usability-driven adoption of SDAG. By integrating the Early Adopters Burn Incentive, we have provided an innovative and balanced approach to rewarding loyalty, reducing circulating supply, and ensuring that our community remains engaged and incentivized for the long run. This initiative further underscores our commitment to a dual-token model that serves both long-term investors and practical users, fostering a robust and sustainable ecosystem for years to come. # Early Adopters Community Burn In addition to the marketplace burn incentive, we have introduced the **Community Burn**, another exclusive opportunity for our early supporters. This program allows whitelisted users to **use their DAGS to deposit into a brokerage account** with a brokerage firm we have partnered with. The user gets value multiplier and the DAGS get burned - another win-win solution. This unique incentive provides direct financial benefits, giving early adopters access to investment opportunities through traditional and digital financial instruments. Through this initiative, burning DAGS allows participants to invest in stocks, forex, commodities, or other assets. This provides early adopters with additional flexibility and choice in how they benefit from their participation in the project. Furthermore, by offering access to a diversified range of investment products, we ensure that our early community members have multiple paths to grow their financial standing beyond just cryptocurrency holdings. This incentive further aligns with our goal of rewarding those who believed in DAGS from the beginning while strengthening the deflationary mechanics that drive long-term value. By reducing the circulating supply while providing users with investment access, the Early Adopters Community Burn has created a strategic win-win, fostering financial growth and further reinforcing the deflationary model. # Utility burns We will be exploring additional partnerships to integrate utility burns into their business models that could contribute to the long-term deflationary nature of DAGS. Whether through merchant integrations, service providers, or digital platforms, we believe that utility-driven burns will play a supporting role in reinforcing the value and longevity of DAGS while making it a more attractive asset. Through these partnerships, a portion of the transaction cost associated with products and services will be directed toward supporting token burns. This ensures that every interaction within the ecosystem not only provides great tangible value to users but also strengthens the tokenomics of DAGS by continuously reducing the circulating supply. # Stablecoin ## Benefits of Stablecoins Over Regular Cryptocurrencies ### **Stability** Price Stability: Stablecoins are pegged to a stable asset like fiat currency or commodities, avoiding the high volatility seen in cryptocurrencies like Bitcoin or Ethereum. Predictability: Individuals and merchants can plan transactions and budgeting without worrying about drastic price changes. ### **Usability** Everyday Transactions: Stablecoins are more practical for daily use, such as paying for goods and services, due to their stable value. Savings and Remittances: Users can store value without exposure to the risk of devaluation, making them ideal for savings and international remittances. ### Merchant Specific Benefits: Hedging Against Volatility: Merchants accepting stablecoins don’t need to immediately convert to fiat to protect against value loss. ### Financial Inclusion: Access to Stable Assets: In countries with hyperinflation or unstable currencies, stablecoins provide a reliable alternative to safeguard value. Decentralized Finance (DeFi): Stablecoins can be used in DeFi applications, offering users earning opportunities without risking their principal against price fluctuations.
## Additional Advantages with DAG-Based Stablecoin: \ No Gas Fees with Other Tokens: Eliminating the need for additional tokens for gas fees simplifies usage and adoption. Efficiency and Scalability: DAG technology ensures fast and scalable transactions, enhancing the user experience for both individuals and merchants. Low cost transactions: The transaction fee on DAG technology is significantly lower than on other popular chains. # Preliminary milestones While the comprehensive roadmap, action plan, documentation and launch strategy are being worked at, the major steps (subject to change) can be seen here: ### Legal framework for SDAG\ Development of SDAG infrastructure\ Wallet development to include SDAG\ Launch of SDAG # Whitepaper Read [here](https://prismic-io.s3.amazonaws.com/dagcoin/f4e531e1-a5db-43b6-930c-14bf705e65ee_Dagcoin_White_Paper.pdf) # Whitepaper # Introduction # Ideoloy # The Problem # Technical # Database structure When a user wants to add data to the database, he creates a new storage unit and broadcasts it to his peers. The storage unit includes (among other things): • The data to be stored. A unit may include more than one data package called a message. There are many different types of messages, each with its own structure. One of the message types is payment, which is used to send bytes or other assets to peers. • Signature(s) of one or more users who created the unit. Users are identified by their addresses. Individual users may (and are encouraged to) have multiple addresses, like in Bitcoin. In the simplest case, the address is derived from a public key, again similar to Bitcoin. • References to one or more previous units (parents) identified by their hashes. References to parents is what establishes the order (only partial order so far) of units and generalizes the blockchain structure. Since we are not confined to one-parent–one-child relationships between consecutive blocks, we do not have to strive for near-synchrony and can safely tolerate large latencies and high throughputs: we’ll just have more parents per unit and more children per unit. If we go forward in history along parent-child links, we’ll observe many forks when the same unit is referenced by multiple later units, and many merges when the same unit references multiple earlier units (developers are already used to seeing this in git). This structure is known in graph theory as directed acyclic graph (DAG). Units are vertices, and parent-child links are the edges of the graph. Figure 1. Storage units connected into a DAG. Arrows are from child to parent, G is the genesis unit. 17 In the special case when new units arrive rarely, the DAG will look almost like a chain, with only occasional forks and quick merges. Like in blockchains where each new block confirms all previous blocks (and transactions therein), every new child unit in the DAG confirms its parents, all parents of parents, parents of parents of parents, etc. If one tries to edit a unit, he will also have to change its hash. Inevitably, this would break all child units who reference this unit by its hash as both signatures and hashes of children depend on parent hashes. Therefore, it is impossible to revise a unit without cooperating with all its children or stealing their private keys. The children, in turn, cannot revise their units without cooperating with their children (grandchildren of the original unit), and so on. Once a unit is broadcast into the network, and other users start building their units on top of it (referencing it as parent), the number of secondary revisions required to edit this unit hence grows like a snowball. That’s why we call this design Byteball (our snowflakes are bytes of data). Unlike blockchains where issuing a block is a rare event and only a privileged caste of users is in practice engaged in this activity, in a new Byteball unit starts accumulating confirmations immediately after it is released and confirmations can come from anyone, every time another new unit is issued. There is no two-tier system of ordinary users and miners. Instead, users help each other: by adding a new unit its author also confirms all previous units. Unlike Bitcoin, where an attempt to revise a past transaction requires a large computational effort, an attempt to revise a past record in Byteball requires coordination with a large and growing number of other users, most of whom are anonymous strangers. The immutability of past records is therefore based on the sheer complexity of coordinating with such a large number of strangers, who are difficult to reach, have no interest in cooperation, and where every single one of them can veto the revision. By referencing its parents, a unit includes the parent. It doesn’t include the full content of the parent; rather, it depends on its information through the parent’s hash. In the same way, the unit indirectly depends on and therefore includes the parents of the parent, their parents, and so on, and every unit ultimately includes the genesis unit. There is a protocol rule that a unit cannot reference redundant parents – that is such parents that one parent includes another. For example, if unit B references unit A, then unit C cannot reference both units A and B at the same time. A is already, in a way, contained within B. This rule removes unnecessary links that don’t add any new useful connectivity to the graph. # Native currency Next, we need to introduce some friction to protect against spamming the database with useless messages. The barrier to entry should roughly reflect the utility of storage for the user and the cost of storage for the network. The simplest measure for both of these is the size of the storage unit. Thus, to store your data in the global decentralized database you 18 have to pay a fee in internal currency called bytes, and the amount you pay is equal to the size of data you are going to store (including all headers, signatures, etc). Similar to pound sterling, which was equal to one pound of silver when it was first introduced, the name of the currency reflects its value. To keep the incentives aligned with the interests of the network, there is one exception in size calculation rules. For the purposes of calculating unit size, it is assumed that the unit has exactly two parents, no matter the real number. Therefore, the size of two hashes of parent units is always included in the unit size. This exception ensures that users will not try to include just one parent in an effort to minimize cost. The cost is the same no matter how many parents are included. To keep the DAG as narrow as possible, we incentivize users to include as many parents as possible (as mentioned before, this does not negatively affect payable size), and as recent parents as possible, by paying part of the unit’s fees to those who are first to include it as a parent. We’ll define later what exactly is ‘first’. Bytes can be used not only for payment of storage fees (also called commissions), but also can be sent to other users to pay for goods or services or in exchange for other assets. To send a payment, the user creates a new unit that includes a payment message such as the following (from now on, we use JSON to describe data structures): { inputs: \[ { unit: "hash of input unit", message\_index: 2, // index of message where this utxo was created output\_index: 0 // index of output where this utxo was created }, … ], outputs: \[ { address: "RECEIVER ADDRESS", amount: 15000 // in bytes }, 19 … ] } The message contains: • An array of outputs: one or more addresses that receive the bytes and the amounts they receive. • An array of inputs: one or more references to previous outputs that are used to fund the transfer. These are outputs that were sent to the author address(es) in the past and are not yet spent. The sum of inputs should be equal to the sum of outputs plus commissions (input amounts are read from previous outputs and are not explicitly indicated when spending). The unit is signed with the author’s private keys. The total number of bytes in circulation is 1015, and this number is constant. All bytes are issued in the genesis unit, then transferred from user to user. Fees are collected by other users who help to keep the network healthy (more details about that later), so they stay in circulation. The number 1015 was selected as the largest round integer that can be represented in JavaScript. Amounts can only be only integers. Larger units of the currency are derived by applying standard prefixes: 1 kilobyte (Kb) is 1,000 bytes, 1 megabyte (Mb) is 1 million bytes, etc. # Double-spends If a user tries to spend the same output twice, there are two possible situations: 1. There is partial order between the two units that try to spend the same output, i.e. one of the units (directly or indirectly) includes the other unit, and therefore comes after it. In this case, it is obvious that we can safely reject the later unit. 2. There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid. There is one more protocol rule that simplifies the definition of total order. 20 We require, that if the same address posts more than one unit, it should include (directly or indirectly) all its previous units in every subsequent unit, i.e. there should be partial order between consecutive units from the same address. In other words, all units from the same author should be serial. If someone breaks this rule and posts two units such that there is no partial order between them (nonserial units), the two units are treated like double-spends even if they don’t try to spend the same output. Such nonserials are handled as described in situation 2 above. Figure 2. Double-spends. There is no partial order between them. If a user follows this rule but still tries to spend the same output twice, the double-spends become unambiguously ordered and we can safely reject the later one as in situation 1 above. The double-spends that are not nonserials at the same time are hence easily filtered out. This rule is in fact quite natural. When a user composes a new unit, he selects the most recent other units as parents of his unit. By putting them on his parents list, he declares his picture of the world, which implies that he has seen these units. He has therefore seen all parents of parents, parents of parents of parents, etc up until the genesis unit. This huge set should obviously include everything that he himself has produced, and therefore has seen. By not including a unit (even indirectly, through parents) the user denies that he has seen it. If we see that by not including his own previous unit a user denies having seen it, we’d say it’s odd, something fishy is going on. We discourage such behavior. # Dagcoin Dagcoin is a blockless Direct Acyclic Graph cryptocurrency. The advantage of leveraging such technology is that dags are not mined and therefore the whole process of transaction validating is lighter and scalable. 9 billion dagcoins have been defined. The definition though actually created 9015 base units, called microdags (μdags). One dag is equivalent to one thousand millidags (mdags) and one mdag is equivalent to one thousand μdags. Dagcoin was defined with the following technical specifications: | | | | ------------------------- | ---------------- | | cap | 9000000000000000 | | is\_private | FALSE | | is\_transferrable | TRUE | | auto\_destroy | FALSE | | fixed \_denominations | FALSE | | issued\_by\_definer\_only | TRUE | | cosigned\_by\_definer | FALSE | | spender\_attested | FALSE | # Codebase The Dagcoin codebase is for the moment made of 3 distinct projects: the client, an explorer and a faucet. The client is available for the following platforms: Windows, Mac, Linux and Android. Some additional features were required, as initially Dagcoin was created as an asset on the Byteball network. These features were developed specifically for this asset, such as a faucet. An additional feature, exchange hub, aimed to address the problem of transferring the asset from one end-user to another without them having to pre fund their wallet with bytes to cover the fee needed to be paid for the units to be validated and processed by witnesses. # Tokenomics # The exchange hub network # Current Situation We wanted to allow our end users to transfer assets without having to deal with the underlying Byteball network. This is not easily achievable given the fact that for any transfer a new byteball unit is required, whose creation requires in its turn an expense of bytes. What we need is therefore a way to provide our customers with the bytes they need transparently # Exchange Hubs and their functionalities An exchange hub is an entity available on the asset's (and therefore byteball) network whose responsibility is to provide bytes (necessary for creating new transactions) to asset's clients who need or require them. Funding hubs: • Hubs work as an exchange office: they propose to exchange assets for bytes at a certain rate •They work, similarly to witnesses, independently from each other in a way that anyone can has the possibility to become a hub. Potentially any client has this possibility. • Their service can't be centralized or controller completely by anyone • Offer exchange rates: client may choose the best offer. # Shared Address Solution Technical Assumptions to be Verified • It is possible to share an address among wallets • It is possible for the owner of the address to authorize or deny transactions. If the address is shared among many clients, a transaction can be denied or authorized only by the address owner (the hub). A hub shares a richly funded address with clients who are interested in its service. The client can use such address a fee payer for an asset transaction upon approval from the hub owning the address.
Each customer wallet would contain one address per hub it is subscribed to. When it needs funds to create a new transaction, it uses this address as fee payer. The hub will then sign the transaction. Technical Assumptions to be Verified • Even in a shared wallet it is still possible to keep addresses separated and distinguish between the owners of the shared wallet • One owner can hold his or her belongings in an address inside the wallet which no one else can manipulate. • Using funds from an address requires the authorization of the real owner.
Upon client creation, a new wallet is created and shared with a hub. In this wallet there is an address private to the customer where the customer holds his valuables (assets) and a shared address where the hub holds some funds (bytes). In this image it is shown that a solution based on shared wallet would in effect create a network of shared wallets between hubs and end users. In such wallets, the end user address would be private to the end user and the shared address public to both. Creating a transaction using funds (bytes) from the hub shared address would require the hub to cosign. # Hub funding protocol Whatever is the underlying implementation (shared address or wallet or something else), the funding protocol will work more or less in the same way.
Imagine a scenario where one client wants to send some assets to another client without possessing the required bytes for creating the transaction. We have the following actors: 1. Client A with a private address (#A) where some assets are stored. 2. Client B with a private address (#B) used for asset exchanges 3. Exchange Hub 1 with a public address (#1). Client A has one only choice: using an exchange hub to fuel its transaction. A must find a hub, whose list can be possibly included in the code or through a discovery service. From each hub A receives an address richly endowed with bytes to include in its wallet. 1. When A wants to send some assets to B, it creates a transaction setting as paying address the one received from the hub and asks the hub for a quote (an exchange rate to estimate the final price). The fee at this point is not final yet. 16 Client Hub Final acceptance and signature Accepts the fee (adds an output) and signs Preliminary acceptance and fee proposal Proposes a transaction 2. The hub 1 proposes a quote which the client may accept of refuse (in that case it must find a different hub to proceed) 3. A adds an output to the transaction containing a transfer of assets to the hub address equivalent to the amount of bytes required by the transaction if they were converted using the hub proposed exchange rate. Then it signs it. The fee in bytes in this moment is final. 4. The hub verifies that the transaction is correct (size, fee, exchange rate) and, if everything is as it should be, cosigns it, validating the transaction # Extracts from Byteball Whitepaper # Database structure When a user wants to add data to the database, he creates a new storage unit and broadcasts it to his peers. The storage unit includes (among other things): • The data to be stored. A unit may include more than one data package called a message. There are many different types of messages, each with its own structure. One of the message types is payment, which is used to send bytes or other assets to peers. • Signature(s) of one or more users who created the unit. Users are identified by their addresses. Individual users may (and are encouraged to) have multiple addresses, like in Bitcoin. In the simplest case, the address is derived from a public key, again similar to Bitcoin. • References to one or more previous units (parents) identified by their hashes. References to parents is what establishes the order (only partial order so far) of units and generalizes the blockchain structure. Since we are not confined to one-parent– one-child relationships between consecutive blocks, we do not have to strive for near-synchrony and can safely tolerate large latencies and high throughputs: we’ll just have more parents per unit and more children per unit. If we go forward in history along parent-child links, we’ll observe many forks when the same unit is referenced by multiple later units, and many merges when the same unit references multiple earlier units (developers are already used to seeing this in git). This structure is known in graph theory as directed acyclic graph (DAG). Units are vertices, and parent-child links are the edges of the graph.

Figure 1

Figure 1. Storage units connected into a DAG. Arrows are from child to parent, G is the genesis unit. In the special case when new units arrive rarely, the DAG will look almost like a chain, with only occasional forks and quick merges. Like in blockchains where each new block confirms all previous blocks (and transactions therein), every new child unit in the DAG confirms its parents, all parents of parents, parents of parents of parents, etc. If one tries to edit a unit, he will also have to change its hash. Inevitably, this would break all child units who reference this unit by its hash as both signatures and hashes of children depend on parent hashes. Therefore, it is impossible to revise a unit without cooperating with all its children or stealing their private keys. The children, in turn, cannot revise their units without cooperating with their children (grandchildren of the original unit), and so on. Once a unit is broadcast into the network, and other users start building their units on top of it (referencing it as parent), the number of secondary revisions required to edit this unit hence grows like a snowball. That’s why we call this design Byteball (our snowflakes are bytes of data). Unlike blockchains where issuing a block is a rare event and only a privileged caste of users is in practice engaged in this activity, in a new Byteball unit starts accumulating confirmations immediately after it is released and confirmations can come from anyone, every time another new unit is issued. There is no two-tier system of ordinary users and miners. Instead, users help each other: by adding a new unit its author also confirms all previous units. Unlike Bitcoin, where an attempt to revise a past transaction requires a large computational effort, an attempt to revise a past record in Byteball requires coordination with a large and growing number of other users, most of whom are anonymous strangers. The immutability of past records is therefore based on the sheer complexity of coordinating with such a large number of strangers, who are difficult to reach, have no interest in cooperation, and where every single one of them can veto the revision. By referencing its parents, a unit includes the parent. It doesn’t include the full content of the parent; rather, it depends on its information through the parent’s hash. In the same way, the unit indirectly depends on and therefore includes the parents of the parent, their parents, and so on, and every unit ultimately includes the genesis unit. There is a protocol rule that a unit cannot reference redundant parents – that is such parents that one parent includes another. For example, if unit B references unit A, then unit C cannot reference both units A and B at the same time. A is already, in a way, contained within B. This rule removes unnecessary links that don’t add any new useful connectivity to the graph. # Native currency: bytes Next, we need to introduce some friction to protect against spamming the database with useless messages. The barrier to entry should roughly reflect the utility of storage for the user and the cost of storage for the network. The simplest measure for both of these is the size of the storage unit. Thus, to store your data in the global decentralized database you have to pay a fee in internal currency called bytes, and the amount you pay is equal to the size of data you are going to store (including all headers, signatures, etc). Similar to pound sterling, which was equal to one pound of silver when it was first introduced, the name of the currency reflects its value. To keep the incentives aligned with the interests of the network, there is one exception in size calculation rules. For the purposes of calculating unit size, it is assumed that the unit has exactly two parents, no matter the real number. Therefore, the size of two hashes of parent units is always included in the unit size. This exception ensures that users will not try to include just one parent in an effort to minimize cost. The cost is the same no matter how many parents are included. To keep the DAG as narrow as possible, we incentivize users to include as many parents as possible (as mentioned before, this does not negatively affect payable size), and as recent parents as possible, by paying part of the unit’s fees to those who are first to include it as a parent. We’ll define later what exactly is ‘first’. Bytes can be used not only for payment of storage fees (also called commissions), but also can be sent to other users to pay for goods or services or in exchange for other assets. To send a payment, the user creates a new unit that includes a payment message such as the following (from now on, we use JSON to describe data structures): ``` { inputs: [ { unit: "hash of input unit", message_index: 2, // index of message where this utxo was created output_index: 0 // index of output where this utxo was created }, … ], outputs: [ { address: "RECEIVER ADDRESS", amount: 15000 // in bytes }, … ] } ``` The message contains: • An array of outputs: one or more addresses that receive the bytes and the amounts they receive. • An array of inputs: one or more references to previous outputs that are used to fund the transfer. These are outputs that were sent to the author address(es) in the past and are not yet spent. The sum of inputs should be equal to the sum of outputs plus commissions (input amounts are read from previous outputs and are not explicitly indicated when spending). The unit is signed with the author’s private keys.The total number of bytes in circulation is 1015, and this number is constant. All bytes are issued in the genesis unit, then transferred from user to user. Fees are collected by other users who help to keep the network healthy (more details about that later), so they stay in circulation. The number 1015 was selected as the largest round integer that can be represented in JavaScript. Amounts can only be only integers. Larger units of the currency are derived by applying standard prefixes: 1 kilobyte (Kb) is 1,000 bytes, 1 megabyte (Mb) is 1 million bytes, etc. # Double-spends If a user tries to spend the same output twice, there are two possible situations: 1. There is partial order between the two units that try to spend the same output, i.e. one of the units (directly or indirectly) includes the other unit, and

Figure 2

therefore comes after it. In this case, it is obvious that we can safely reject the later unit. 2. There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid There is one more protocol rule that simplifies the definition of total order. We require, that if the same address posts more than one unit, it should include (directly or indirectly) all its previous units in every subsequent unit, i.e. there should be partial order between consecutive units from the same address. In other words, all units from the same author should be serial. If someone breaks this rule and posts two units such that there is no partial order between them (nonserial units), the two units are treated like double-spends even if they don’t try to spend the same output. Such nonserials are handled as described in situation 2 above. Figure 2. Double-spends. There is no partial order between them. If a user follows this rule but still tries to spend the same output twice, the double-spends become unambiguously ordered and we can safely reject the later one as in situation 1 above. The double-spends that are not nonserials at the same time are hence easily filtered out. This rule is in fact quite natural. When a user composes a new unit, he selects the most recent other units as parents of his unit. By putting them on his parents list, he declares his picture of the world, which implies that he has seen these units. He has therefore seen all parents of parents, parents of parents of parents, etc up until the genesis unit. This huge set should obviously include everything that he himself has produced, and therefore has seen. By not including a unit (even indirectly, through parents) the user denies that he has seen it. If we see that by not including his own previous unit a user denies having seen it, we’d say it’s odd, something fishy is going on. We discourage such behavior # The main chain Our DAG is a special DAG. In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction. One can picture it as a thick cord with many interlaced wires inside. This property suggests that we could choose a single chain along child-parent links within the DAG, and then relate all units to this chain. All the units will either lie directly on this chain, which we’ll call the main chain, or be reachable from it by a relatively small number of hops along the edges of the graph. It’s like a highway with connecting side roads. One way to build a main chain is to develop an algorithm that, given all parents of a unit, selects one of them as the “best parent”. The selection algorithm should be based only on knowledge available to the unit in question, i.e. on data contained in the unit itself and all its ancestors. Starting from any tip (a childless unit) of the DAG, we then travel backwards in history along the best parent links.

Figure 3

Traveling this way, we build a main chain and eventually arrive at the genesis unit. Note that the main chain built starting from a specific unit will never change as new units are added. This is because on each step we are traveling from child to parent, and an existing unit can never acquire new parents. If we start from another tip, we’ll build another main chain. Of note here is that if those two main chains ever intersect while they go back in history, they will both go along the same path after the intersection point. In the worst case, the main chains will intersect only in genesis. Given that the process of unit production is not coordinated among users, however, one might expect to find a class of main chains that do converge not too far from the tips. Figure 3. Main chains built from different childless units intersect and then go along the same path. Of the two double-spends, the one with the lower main chain index (5) wins, while the other (with CI=6) is deemed invalid. Once we have a main chain (MC), we can establish a total order between two conflicting nonserial units. Let’s first index the units that lie directly on the main chain. The genesis unit has index 0, the next MC unit that is a child of genesis has index 1, and so on traveling forward along the MC we assign indexes to units that lie on the MC. For units that do not lie on the MC, we can find an MC index where this unit is first included (directly or indirectly). In such a way, we can assign an MC index (MCI) to every unit. Then, of the two nonserials, the one that has a lower MCI is considered to come earlier and deemed valid, while the other is invalid. If both nonserials happen to have the same MCI, there is tiebreaker rule that the unit with the lower hash value (as represented in base64 encoding) is valid. Note that we keep all versions of the double-spend, including those that eventually lose. DagCoin \[3] was the first published work that suggested storing all conflicting transactions and deciding which one to treat as valid. The MC built from a specific unit tells us what this unit’s author thinks about the order of past events, i.e. his point of view about the history. The order then implies which nonserial unit to consider valid, as described above. Note that by choosing the best parent among all parents of a given unit, we are simultaneously making a choice among their MCs: the MC of the unit in question will be the MC of its best parent extended forward by one link. Recognizing that many (or even all) parent units might be created by an attacker, and remembering that the choice of best parent is essentially the choice among versions of history, we should require from our best parent selection algorithm that it favors histories that are “real” from the point of view of the child unit. We hence need to devise a “reality test” that our algorithm would run against all candidate MCs to select the one that scores best. # Yearly reports # 2025 Uploaded soon.. # 2024 Uploaded soon.. # 2023 Uploaded soon.. # 2022 Uploaded soon.. # 2021 Uploaded soon.. # 2020 Uploaded soon.. # 2019 Uploaded soon.. # 2018 Uploaded soon.. # 2017 Uploaded soon.. # Pricing Models