# Read Me

Welcome to OWY, where the meme meets financial sense for the first time.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FBxEkk4NMmOOXL2N229lw%2Fcooking.jpeg?alt=media&amp;token=f862069b-9399-438f-94de-91c1304ff5ff" alt=""><figcaption><p>Something is being cooked.</p></figcaption></figure>

Owy is a decentralized meme coin project on the Ethereum blockchain, aiming to integrate memes with economic functionalities to achieve sustainable growth in its economic value. The entire system is designed to maximize the token's potential value while promoting practicality in transactions.

> *<mark style="color:orange;">"We believe that meme coins can be functional. Besides being humorous, they can serve practical purposes in storing values and facilitating financial services."</mark>* - Owy Team.

The following pages in this section contain the reasons why the Owy project was created, the tasks it aims to solve, and the conceptual principles it follows to develop solutions. If you want to understand how Owy applies this knowledge and see the exact solutions with details, visit [Tokenomics](/tokenomics) and [Features ](/features)sections. However, we do not encourage skipping any pages in this section, as it is easy to get lost.

#### The project is open-source under the MIT license. Enjoy.


# Motivation

Below are the root causes that led to this project creation.

## Pain points

### *1 Destructive Monetary Policy*

Money is divided into two main categories: circulating (spending) and reserved (saving) supply. Governments often focus on increasing circulating supply to stimulate growth and increase tax revenue. During downturns, people save more and spend less. To combat stagnation, governments may use Quantitative Easing (QE) to inject money into the market.

However,[ Milton Friedman's quantity theory of money](https://miltonfriedman.hoover.org/internal/media/dispatcher/214346/full) suggests this approach devalues the wealth of average individuals, leading to compounding debt that eventually exceeds the government's ability to repay. This flawed system creates opportunities for exploitation, as exemplified in  [George Soros's Black Wednesday event with the Bank of England](https://en.wikipedia.org/wiki/Black_Wednesday).  When designing immutable monetary policies, it is crucial to ensure neutrality. Instead of focusing on quantity, strategies to boost economic activity should prioritize <mark style="color:orange;">enhancing the value within each unit of store of value</mark> to prevent devaluation and negative sum effects.

We believe that the choice to save or spend should remain private and entirely personal. Forcing spending by devaluing savings infringes on financial rights. An economic system should encourage spending through incentives and favorable conditions, not coercion.

***

### *2 Budget Deficit Fiscal Policy*

Fiscal policy involves using government spending and tax policies to influence the economy. A budget deficit occurs when government expenses exceed revenues, often prompting measures like Quantitative Easing (QE) and interest rate adjustments through government bonds. These actions link fiscal and monetary policy, addressing budget deficits but potentially devaluing the currency and increasing national debt.

The critical question is: why does the government need to spend more than it has? While there are various reasons, the Owy project highlights one key issue: <mark style="color:orange;">the government's spending and investment strategy is often suboptimal</mark>. Ideally, tax revenues should be invested with a non-negative return on investment (ROI) to foster growth. However, achieving a 100% success rate is unrealistic, leading to two essential questions/tasks to be addressed:

1. *Decentralizing Tax Spending Decisions:* Since taxes come from all economic participants, could tax spending decisions be decentralized to involve all taxpayers instead of leaving them solely to the government? This could result in a more comprehensive and thoughtful investment.
2. *Proportional Distribution of Investment Values:* How can we guarantee that the returns from these investments are distributed fairly among all participants?
3. *Budget Balanced Fiscal Policy:* It is mandatory to spend within the balance, and not initiate any debt to prevent inability to repay.

***

### *3 Inefficient Incentivization*

We have seen[ the US government](https://fred.stlouisfed.org/series/M2SL) force spending by inflating the supply. Bitcoin (BTC) is another example of incentivizing miners through subsidy (token emission). This approach resembles government monetary policy, as it creates a new money supply.&#x20;

Additionally, since Bitcoin blocks vary in transaction volume, using a fixed amount of subsidy per block to reward miners is inefficient due to <mark style="color:orange;">inconsistent workloads</mark>. BTC’s purchasing power can sometimes struggle against inflationary pressures, making <mark style="color:orange;">the value of savings heavily reliant on speculation</mark> without support from a stable economic incentivization program.

In essence, we need to design an incentive algorithm that promotes economic activities without devaluing individuals' savings and focuses on increasing the value of reserve supply (savings).&#x20;

{% hint style="success" %}
The first three pain points above are solved by structing a new economic model, which we call [Inverse Economics](/read-me/inverse-economics).
{% endhint %}

***

### *4 Unscalable Taxation system/Transaction Cost*

Comparing the costs of transferring digital cash to physical gold reveals differences in transportation costs. Transaction costs were made cheaper when the internet came. Then, Bitcoin introduced a dynamic transaction cost structure for digital transfers. However, the <mark style="color:orange;">scalability in terms of practical improvement</mark> of this dynamic structure remains debatable, as the transaction costs may not decrease proportionally with Bitcoin's price or supply increases.

In traditional economies, taxes are often a percentage of income or product prices, but rates of 20%-30% or more can hinder long-term economic growth. Paying taxes means giving up personal resources, and it’s difficult to gauge how much people are willing to sacrifice. This is why many are moving from high-tax regions like Europe and the U.S. to countries with lower or no taxes. Thus, it’s crucial to consider <mark style="color:orange;">taxation based on value</mark> rather than fixed percentages.

{% hint style="info" %}
Transaction costs can be categorized as a tax if we define "tax" as any portion of value deducted from the transaction amount by the sender that is not transferred to the recipient. This deducted value may be transferred to third parties or simply disappear, but it is ultimately an amount taken away from the transaction value.
{% endhint %}

<mark style="color:orange;">As an economy matures,</mark> [transaction costs](#id-4-unscalable-taxes-transaction-costs) <mark style="color:orange;">or individual tax amounts should ideally decrease</mark>. As the value within circulation grows, the revenue becomes sufficient to sustain economic growth and support public services, similar to the [economies of scale](https://en.wikipedia.org/wiki/Economies_of_scale) in large companies like[ AWS cloud services](https://aws.amazon.com/). If implemented effectively, reducing the tax burden can encourage spending, stimulate economic activity and potentially increase overall tax revenue.&#x20;

However, ensuring a fair and practical tax calculation methodology can be challenging, as demonstrated by Bitcoin's transaction costs. Additionally, if certain groups benefit from higher taxation and would be disadvantaged by cost reduction, we must balance the value flow to maintain fairness for all participants.&#x20;

{% hint style="success" %}
These challenges and our proposed solutions will be addressed in the [Scalability](/read-me/scalability) section.
{% endhint %}

***

### *5 Lack of Value Control*

This enhancement, enabled by programmable money, focuses on addressing future potential rather than current issues. While it is an uncommon question yet, it is crucial: "How do we extract value from our current stores of value (e.g., money)?" The Owy project tackles this <mark style="color:orange;">principle of value extraction</mark>.&#x20;

> To illustrate, imagine two people holding the same amount of OWY tokens. <mark style="color:orange;">Even with identical quantities, one person's tokens hold more value than the other's</mark>. This concept is similar to USD bills: despite being made from the same material, their value varies based on their denominations—1, 5, 10, 20, 50, and 100 USD. The difference in value lies not in the paper or printing but in what the denominations represent.

Similarly, with OWY tokens, we aim to integrate a mechanism where tokens can carry varying levels of value. The challenge is that <mark style="color:orange;">OWY is a fungible token</mark>, meaning there are no distinct denominations like USD bills. Our goal is to embed a value differential within each OWY token itself to enhance the value they represent beyond just their quantity.

Another improvement is to allow individuals full <mark style="color:orange;">control over their values</mark>, enabling them to separate these values from their actual stores of value for personal purposes. This must be done <mark style="color:orange;">while preserving the fungibility property</mark> of the ERC-20 token, ensuring seamless integration with existing decentralized markets and protocols.&#x20;

{% hint style="success" %}
We will explore how this in the [Value Control](/read-me/value-control) section.
{% endhint %}

***

## Goals

Our goals are centered around creating a new economic model that maximizes the value of each unit of capital. We develop an <mark style="color:orange;">efficient taxation system and equitable value distribution</mark> that can evolve over time. Economic activities are accelerated through a <mark style="color:orange;">sustainable incentivization</mark> system rather than inflation-driven methods. Additionally, we seek to empower each owner with <mark style="color:orange;">full control over their values</mark>, independent of their stores.&#x20;

We aim for this project to be a living experiment, producing outcomes distinct from existing economies and asset types. Its influence and impact will be driven entirely by its participants. By engaging with this dynamic economic model, participants will actively shape its evolution and showcase its potential for developing more equitable and efficient economic structures.

Lastly, to elevate the meme coin space from mere humor to something creative and functional, we present this development through <mark style="color:orange;">Owy, a fat owl of freedom</mark>.

Can a meme coin be functional? We'll see :)


# Inverse Economics

#### The economic model proposed by the Owy team aims to create a system focused solely on increasing the value of money, effectively making saving great again. It serves as a mirrored version of traditional economics, naturally encouraging individuals to save and invest more wisely by enhancing the intrinsic value of money.

{% hint style="info" %}
Inverse Economics consists of open principles that can be tailored and applied by an individual who desires to design an economic system. This page only contains a concise explanation. If you need more explanation, visit [Whitepaper.](/whitepaper)  If you want to know how Owy applies these principles, read [Tokenomics ](/tokenomics)section.
{% endhint %}

In inverse Economics, we proposed that value is represented as the product of two factors: time and productivity.

$$
\displaystyle value = time \times productivity
$$

*<mark style="color:orange;">Time</mark>*, in this model, represents the duration an individual has saved their store of values, while *<mark style="color:orange;">productivity</mark>* refers to their contribution to economic growth through paying taxes.

Incorporating the factor of time into the formula allows individuals who save for extended periods to surpass those who primarily contribute financially through productivity. This approach provides dedicated lower-class individuals <mark style="color:orange;">the opportunity to elevate their economic status through saving</mark> alone, leveling the playing field and enabling them to compete more effectively with those from higher classes—something <mark style="color:orange;">that traditional economic models have not facilitated throughout history</mark>. See [Basic Value Flow](/resources/basic-value-flow) as an illustration.

There are four main topics revisited and revised in Inverse Economics, as stated below.

***

### *1 Supply Distribution and Management*

In Inverse Economics, we <mark style="color:orange;">begin with a fixed maximum supply</mark> of tokens and guarantee <mark style="color:orange;">no new tokens are created after deployment</mark>. Unlike inflationary economies (e.g. USD, Gold, Bitcoin) where supply is continuously emitted until a maximum limit is reached (if one exists), Inverse Economics ensures that the <mark style="color:orange;">supply decreases with each transaction</mark>.

> Participants in the ecosystem influence token deflation and scarcity through their spending and saving activities.

With a supply contraction mechanism, each transaction burns a small fraction of the transfer value as a tax, permanently reducing the total supply. As the supply diminishes, the value of the remaining tokens increases, resulting in a higher percentage share for each holder.

***

### *2 Tax and Incentivization*&#x20;

Taxation is determined proportionally to transaction values. When participants make a transaction, <mark style="color:orange;">a fraction of the transfer value is deducted and permanently burnt from the system</mark>. This approach efficiently redistributes value to all holders while ensuring that the funds do not re-enter circulation, avoiding any resemblance to a[ Ponzi scheme](https://en.wikipedia.org/wiki/Ponzi_scheme).

When tax is burnt, value is redistributed to holders (savers), who benefit from others' spending. Now, let’s shift our focus to the spenders. In this economic model, productivity is tied to tax payment, and as money becomes more valuable, it is crucial to design effective incentives to encourage spending. People will not save indefinitely due to basic consumption needs. However, a well-designed incentivization system can motivate more frequent spending (if the investment is worthwhile). The system aims to reward efficient spenders with meaningful incentives that generate future value, such as tax discounts, exclusive access to investment products, or other financial privileges. If these <mark style="color:orange;">incentives scale with the overall economy</mark>, they will make long-term investments more attractive and beneficial.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FnGcqTbCdZ2lXQH5JeECG%2Fflow.png?alt=media&amp;token=2dc1c6cf-346d-4724-8db8-f0d0bc919174" alt=""><figcaption><p>Incentivization Overview</p></figcaption></figure>

The purpose is to redefine <mark style="color:orange;">spending as an investment opportunity and tax payment as a privilege engagement</mark> rather than a penalty. By aligning returns with economic growth and agreed-upon conditions, we transform spending from a mere opportunity loss into a strategic advantage. This approach ensures that both saving and spending are incentivized, to balance a thriving economic environment.

{% hint style="success" %}
As incentives become more valuable and spending, along with paying taxes, becomes the primary way to earn rewards, individuals are motivated to make more strategic spending decisions. Poor decisions may lead to significant opportunity losses, while careful planning and wise expenditures can result in favorable outcomes.
{% endhint %}

***

### *3 Dependency and Decentralization*

The system fosters open competition among participants. <mark style="color:orange;">Spenders compete through strategic spending to maximize their returns, while savers aim to increase their share of value from burnt tokens</mark>. This mutualistic relationship benefits both groups: savers gain value from tax payments, and spenders utilize savers' liquidity provided by savers. This interconnected dynamic ensures that neither savers nor spenders can thrive without the other, creating a balanced and interdependent economic environment.

An individual’s status and privileges should be determined exclusively by <mark style="color:orange;">metrics within the economic system</mark>. For example, in a saving time competition, incentives are awarded based on how much an individual’s saving time <mark style="color:orange;">exceeds the average</mark> of all participants, rather than the absolute time saved. This ensures fair, challenging, and dynamic competition, adapting to the performance of all participants.

Decentralization of economic power is based on <mark style="color:orange;">value-weighted contributions</mark>. Individuals can gain significant influence by making substantial contributions to the overall economic value through savings and tax payments. Therefore, besides the amount of tokens an individual holds, <mark style="color:orange;">the value associated with their tokens also matters</mark>.&#x20;

In Inverse Economics, both saving and tax paying operate similarly to Bitcoin mining, but with a different focus. While Bitcoin miners compete for <mark style="color:orange;">amount shares</mark> of newly minted tokens until a supply limit is reached, participants in Inverse Economics save to gain <mark style="color:orange;">value shares</mark> from newly burnt tokens until a lower supply limit is reached. This model shifts economic competition from mining to saving, lowering entry costs and making participation more accessible, though it remains competitive to secure a position within the final supply.

***

### *4 Final Supply*&#x20;

Bitcoin established the concept of a final supply limit with its 21 million cap, setting both the maximum quantity of tokens and the <mark style="color:orange;">endpoint for additional incentivization</mark> (subsidy) to kickstart the economy. This finite supply serves as a crucial psychological anchor, giving participants a clear understanding of total availability and aligning individual goals with predictable profitability.

Inverse Economics adopts a similar approach by establishing a final supply, but with a deflationary twist. <mark style="color:orange;">The token supply decreases until it reaches a predetermined lower limit</mark>, at which point deflation halts, stabilizing the remaining tokens. Participants compete to save and retain value, striving for a larger share of the increasingly valuable supply until no more tokens can be burnt.

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td></td><td>Official Whitepaper</td><td></td><td><a href="/whitepaper">Whitepaper</a></td><td><a href="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FgXieELNxILKmJThYZlRR%2FIMG_6716.webp?alt=media&amp;token=345972c4-7da3-4b9f-8d42-284f318cec8c">IMG_6716.webp</a></td></tr></tbody></table>


# Scalability

This discussion focuses on scaling the inverse economy. When addressing sustainability, we emphasize methods that foster fair value distribution and sustainable growth without compromising efficiency.

## 1 Value Distribution

Consider ten different economies. What makes an individual choose one over others? It is similar to why you might choose one café over another. There is always an incentive behind the choice. However, if an economy gives more than it takes, how does it remain positive-sum? This leads us to the topic of value distribution. Proposed in[ Piketty’s theory](https://en.wikipedia.org/wiki/Capital_in_the_Twenty-First_Century), for sustainable economic activities and fair distribution, the economy’s growth rate (g) must equal or outpace the return on capital (r) <mark style="color:orange;">(g >= r)</mark>.

Incentives or contribution rewards help the economy mature. As values change hands through transactions, the tax on each transaction increases the value per unit of store. These rewards, funded by participants' taxes, are then used to incentivize others. However, this raises a concern: when the overall economic value is high, the tax burden for spenders can become too significant.

We aim to create <mark style="color:orange;">certain opportunities where individual return on capital (r) can temporarily exceed the economy's growth rate (g)</mark>, within a manageable and attractive range, before gradually decreasing. These incentives should attract participants while ensuring that <mark style="color:orange;">overall growth (g) remains greater than or equal to the average return (r) still holds.</mark>

> Imagine paying a tax and receiving an investment product as a reward—one that has a supply limit and becomes increasingly scarce over time. Each unit of the reward can generate yield at the same rate as others, but the rewards themselves do not generate income automatically. Users must actively participate in an economic game,  competing against each other. Since returns are limited and distributed over specific timeframes, those who perform better may receive returns above the average.
>
> These rewards are infinitely reusable, but as more rewards are minted, the utility of each unit decreases proportionally. As multiple participants mint rewards, the competition intensifies and becomes more decentralized. For those uninterested in participating, the rewards can be sold for a one-time earning or lent out for interest. This also means the rewards could be priced and traded in open markets, adding another layer of value and utility.

***

## 2 Measurement

Next, we discuss how to measure and time these opportunities to ensure they provide attractive returns for competition. While the economy’s value is used as a metric, it does not produce a linear graph. Linear calculations, though straightforward and fair, might not be compelling enough for robust competition. A stepping approach, with an appropriate timeframe, can make competition more enticing. We refer to these steps as <mark style="color:orange;">“maturity stages,”</mark> with the time to progress depending on the economy's growth rate.

In Inverse Economics, The burned tax value is distributed proportionately to all participants, contributing to economic growth (g). Taxpayers receive utility rewards for these contributions, which can be used independently to generate value. The returns generated from these rewards are considered the capital return (r).

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FPcScJLomztVlD3Msn6aE%2Fstages.png?alt=media&amp;token=31182ffc-1253-4b9e-ab4c-5ca384f802f9" alt=""><figcaption><p>Relationships between Reward Utility Level and Economy's Growth.</p></figcaption></figure>

The stable utility level within each maturity stage is where competition occurs, and it intensifies as the economy approaches the next stage. If the total returns for each stage decrease in line with the economy's growth, each subsequent stage will take longer to complete than the previous one. This extended duration further intensifies competition, as participants have more time to maximize their returns before the utility levels decline.

> Imagine that the duration Y in the image is longer than duration X, with each subsequent stage taking increasingly longer as utility levels decrease. This extension over stages can lead to a more prolonged and potentially more decentralized process as new participants enter the fray.  However, is it possible that duration Y becomes shorter than X, the answer is yes, the speed of growth in each maturity can be variable, depending on tax volume.

Although spending incentives may diminish as the economy grows, their value remains intact. In Inverse Economics, <mark style="color:orange;">the economy's growth (g) directly reflects the value of these incentives</mark>. This concept is similar to Bitcoin halving but is more flexible and dynamically responsive to market efficiency.&#x20;

{% hint style="success" %}
Overall, this dynamic prioritizes economic growth (g) over average return on capital (r), scaling down the incentive effect based on the economy's growth.
{% endhint %}

***

## 3 Competition

competition is divided into two parts:

### *3.1 Acquiring Reward*

Earning rewards is competitive, as they are gained solely through tax payments, making them a valuable investment. Timing transactions well can lead to higher rewards, especially in the early stages when token values are low. As the economy matures and rewards become scarcer, their value naturally increases

### *3.2 Utilizing Reward*

As demonstrated in [Measurement](#id-2-measurement), the utility of these rewards can be maintained within a specific maturity stage, creating a window for optimal use and intensifying competition. If rewards are reusable, some participants may achieve a return on capital (r) greater than the economy's growth rate (g). However, those who do not frequently utilize their rewards may see their r fall below g.

***

## 4 Utility token

With dynamic time constraints, users may need to develop strategies to maximize ROI from their rewards, potentially involving third-party management. To facilitate this, rewards should remain flexible and not be confined to in-system use, allowing for broader integration and independent utilization. By tokenizing rewards as fungible tokens, opportunities for arbitrage trading, lending, and more become accessible. DeFi protocols, organizations, and developers can harness this flexibility by integrating their services, offering new functionalities to this utility token, which gains value and becomes increasingly scarce as the economy matures. This concept ties into [Value Control](/read-me/value-control).

{% hint style="success" %}
As the economy matures, Inverse Economics employs quantitative deductions as a scaling solution to maximize the value of each incentive, prioritizing growth over average capital returns. This approach, driven by open competition across maturity stages, promotes the system’s appeal for onboarding a larger number of users. In this economy of value, individuals benefit from improved outcomes as the value of their holdings increases.
{% endhint %}


# Value Control

In [Inverse Economics](/read-me/inverse-economics), two key types of value are emphasized: time and productivity.

* **Time** refers to the duration an individual has held their store of value (saving time), reflecting their contribution to <mark style="color:orange;">stabilizing the economy's value</mark>.
* **Productivity** is measured through tax payments. As more tax is collected, the token supply decreases, which in turn increases <mark style="color:orange;">increasing the intrinsic value</mark> of each remaining token.

The image below illustrates that each unit of store contains a certain quantity of these values.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2Fr1BUA9a9sracJBz5nlll%2Fstores.png?alt=media&amp;token=7d17f26e-8ea4-4a08-9a58-e91a0d81524e" alt=""><figcaption><p>Stores of Value Overview</p></figcaption></figure>

When money (as a store of value) is traded, the underlying values are exchanged between hands. Some stores may hold more value than others—like a $10 bill containing more value than a $5 bill. While denominations help in transferring and utilizing values, they don't offer complete control over values. At Owy, this limitation is addressed, allowing for more optimal control over values.

With smart contracts, value extraction becomes feasible, opening up various use case possibilities. For simplicity and ease of integration, these values are extracted and tokenized as [ERC-20](https://docs.openzeppelin.com/contracts/4.x/erc20).

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FV1jDMlA8WA7SkuE0u0p0%2Fsubtokens.png?alt=media&amp;token=dc0659b2-9fb1-4287-b38d-2117ec417f6b" alt=""><figcaption><p>Token and Subtokens</p></figcaption></figure>

Once the main token's values are extracted, the token can still be used or traded as usual, but it no longer retains the economic benefits or privileges associated with those values. The value of these extracted components can be assessed separately from the main token, as their worth is tied to the specific economic privileges they offer. For instance, these values might provide a 10% tax discount on transfers of the main token, but after extraction, transactions may incur the full tax rate.

This can be achieved while preserving the fungibility of the main token, ensuring the system remains easy to build upon. The design allows these values to be priced and arbitraged in trading, leveraging the valuable economic privileges they represent. This, in turn, enables the economy to scale to a new level.&#x20;

{% hint style="success" %}
Congratulations! You've now grasped the principles underlying this project. It's time to see these concepts in action with Owy. Let’s dive into the implementation with a closer look at its [Tokenomics](/tokenomics).
{% endhint %}


# Tokenomics

{% hint style="info" %}
This section demonstrates how the OWY project applies the principles outlined in the [Read Me](/) section, to create its innovative tokenomics.
{% endhint %}

OWY is the token representing the store of value in Owy's inverse economy. It powers the system and drives value growth. Each OWY token held by an individual signifies ownership and economic status within the economy.

## General Info

* Token name: <mark style="color:orange;">Owy</mark>
* Token symbol: <mark style="color:orange;">OWY</mark>
* Token decimals : <mark style="color:orange;">18 decimals</mark>
* Token Type: <mark style="color:orange;">ERC-20</mark> (with enhancements)
* Network: <mark style="color:orange;">Ethereum</mark>

***

## 1 Launch Phase

Owy initiates the inverse economy by launching the maximum supply right from the start.

* Max supply: <mark style="color:orange;">69,000,000 tokens</mark> (69 million tokens)

During the launch phase, OWY tokens are distributed to three different sectors. Each sector has its own timeline, speed, and criteria for distribution, which are independent of each other.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FApKAFU5JuF9EXXxqhB8y%2FTokenomics.webp?alt=media&amp;token=616b336b-a4a1-49c6-b666-aee204a5d322" alt=""><figcaption><p>Owy Token Allocation</p></figcaption></figure>

## Public&#x20;

### 60% - Initial Liquidity Offering

Given that OWY’s initial supply is set to its maximum and this sector holds the majority of the allocation, it is crucial to implement a strategic distribution plan to prevent power centralization. This may involve using multiple launchpads, IEOs, and other liquidity supply portals, with the bulk of tokens distributed through Owy's native ILO.

The vesting criteria vary by allocation platforms, but they all have to align with the launch timeline.

{% hint style="info" %}
&#x20;Stay informed for the announcements of ILO, there will be a dedicated section to clarify the event.
{% endhint %}

### 10% - Airdrops

This allocated fund is distributed to Owy community as airdrops, which consist of multiple rounds across the development stages of the project to incentivize activities, reward loyal users, and for marketing purposes to increase project awareness.

### 5% - Kickstarter fund

Owy project offers one funding round to the public to kickstart the production. The fund is used for smart contract security audit, legal compliance, expanding team size, exchange listing, and marketing.

***

## DAO

### 15% - R\&D

After launch, Owy will be transformed from a project created and managed by the development team into a Decentralized Autonomous Organization (DAO). This means that control over the project's direction, the use of the R\&D treasury, and ownership of the Owy project will be distributed proportionally to all OWY holders. The community will be able to vote on development proposals aimed at adding more value to the ecosystem. The founding team will remain fully committed, contributing full-time to the project's development and maintenance.

***

## Private

### 10% - Core Team

This allocation is distributed to the founding team and key contributors who played a significant role in developing Owy, serving as compensation for their efforts. Each member's allocation is not fixed and will be vested over 1,000 days from the token launch day. While this fund can be used to cover maintenance costs and additional project expenses, such decisions are at the individual discretion of the team members.

***

## 2 Contraction Phase

This is the longest phase of all. After the launch, the system employs the principle of [Inverse Economics](/read-me/inverse-economics) to reduce supply by deducting a fraction of each transaction for permanent burn.

Transaction owner pays this deducted fraction as tax, contributing to supply contraction. Since the tax amounts collected are entirely burnt, increased transaction activity leads to a decreased supply of OWY tokens.

We provide a dedicated page for detailed tax calculation in [Supply Contraction](/tokenomics/supply-contraction).

***

## 3 Final Phase

Supply contraction does not continue indefinitely. To transition from the Contraction phase to the Final phase, certain criteria must be met.

### 3.1 Final supply

The final supply marks the end point of Owy’s supply contraction. Once the supply decreases <mark style="color:orange;">to 69 or fewer OWY tokens</mark>, the supply contraction mechanism permanently ceases, and OWY transitions to a supply-stable token.

### 3.2 Max Block Limit

This is a second objective that can cause the deflation mechanism to permanently stop, but it serves more as a system limit than a practical criterion. When calculating a tax discount for an individual, <mark style="color:orange;">the block number</mark><mark style="color:orange;">`118,834,697,888,524,300`</mark>indicates the last value before the calculation overflows, which leads to errors. However, this block number is unlikely to be reached in practice. Even if Ethereum blocks were processed at 1 microsecond per block, it would still take over 1 billion days to reach this block number. Therefore, focusing on the lower supply limit of 69 tokens is more realistic.

Once <mark style="color:orange;">either of the two limits</mark> is reached, the contraction algorithm will no longer apply, and the deflation system will permanently stop. This marks the endgame of competition among economic participants. All remaining OWY tokens represent the rewards to those who have competed and secured their position within the final supply.

{% hint style="warning" %}
**After the deflation mechanism concludes, the OWY token will transition to a regular ERC20 with no tax. Following the end of deflation, the value tokens and the systems for extraction and insertion are permanently halted. Users who desire to permanently burn additional OWY can still send their funds to the zero address. This manual burn process does not have a limit.**
{% endhint %}


# Supply Contraction

When OWY holders make a transaction, they pay a fraction of their OWY as a tax, contributing to the reduction of the circulating supply.

{% hint style="info" %}
This page involves detailed calculations designed to manage and control supply reduction in a manner that upholds principles of fairness and operational efficiency.
{% endhint %}

## Taxation  formula

$$
\displaystyle TaxValue = \[Transfer Value \times Deflation Rate] \times \[\frac {BlockIn^3}{VWAB^3}] \times \[\frac{TaxAccumulation\_{individual}}{TaxAccumulation\_{total}}] \times 1.69
$$

The formula can be broken down into three main components for clarity: the base value, discounts (based on time and tax accumulation), and a magic number. Additionally, there is a hidden element known as the maximum tax.

### 1 Base Value

$$
\[TransferValue \times Deflation Rate]
$$

* *Transfer Value* = initial or intended amount of OWY tokens to be transferred.
* *Deflation Rate* = the current rate of supply contraction, which varies according to different supply stages as outlined in the [Deflation Schedule](#deflation-schedule) below.

#### Deflation Schedule

Applying the [stepping approach with maturity stages](/read-me/scalability#id-2-measurement), the current deflation rate correlates to the stage of OWY total supply.

<table><thead><tr><th width="100" align="center">Stage</th><th align="center">Total Current Supply</th><th align="center">Deflation Rate</th></tr></thead><tbody><tr><td align="center">1</td><td align="center">&#x3C;= 69,000,000.00</td><td align="center"><mark style="color:orange;">6.900%</mark></td></tr><tr><td align="center">2</td><td align="center">&#x3C;= 47,610,000.00</td><td align="center"><mark style="color:orange;">4.761%</mark></td></tr><tr><td align="center">3</td><td align="center">&#x3C;= 32,850,900.00</td><td align="center"><mark style="color:orange;">3.285%</mark></td></tr><tr><td align="center">4</td><td align="center">&#x3C;= 22,667,121.00</td><td align="center"><mark style="color:orange;">2.267%</mark></td></tr><tr><td align="center">5</td><td align="center">&#x3C;= 15,640,313.49</td><td align="center"><mark style="color:orange;">1.564%</mark></td></tr><tr><td align="center">6</td><td align="center">&#x3C;= 10,791,816.31</td><td align="center"><mark style="color:orange;">1.079%</mark></td></tr><tr><td align="center">7</td><td align="center">&#x3C;= 7,446,353.25</td><td align="center"><mark style="color:orange;">0.745%</mark></td></tr><tr><td align="center">8</td><td align="center">&#x3C;= 5,137,983.74</td><td align="center"><mark style="color:orange;">0.514%</mark></td></tr><tr><td align="center">9</td><td align="center">&#x3C;= 3,545,208.78</td><td align="center"><mark style="color:orange;">0.355%</mark></td></tr><tr><td align="center">10</td><td align="center">&#x3C;= 2,446,194.06</td><td align="center"><mark style="color:orange;">0.245%</mark></td></tr><tr><td align="center">11</td><td align="center">&#x3C;= 1,687,873.90</td><td align="center"><mark style="color:orange;">0.169%</mark></td></tr><tr><td align="center">12</td><td align="center">&#x3C;= 1,164,632.99</td><td align="center"><mark style="color:orange;">0.116%</mark></td></tr><tr><td align="center">13</td><td align="center">&#x3C;= 803,596.76</td><td align="center"><mark style="color:orange;">0.080%</mark></td></tr><tr><td align="center">14</td><td align="center">&#x3C;=554,481.77</td><td align="center"><mark style="color:orange;">0.069%</mark></td></tr><tr><td align="center">15</td><td align="center">&#x3C;= 69</td><td align="center"><mark style="color:orange;">0.000%</mark></td></tr></tbody></table>

{% hint style="info" %}
The deflation rate starts at 6.9% and gradually decreases to 69% of the previous rate as the total supply moves to the next stage, which is also 69% of the previous stage's supply.
{% endhint %}

***

### 2 Discounts

#### 2.1 Time Accumulation Discount

$$
\[\frac {BlockIn^3}{VWAB^3}]
$$

* *BlockIn* = the average Ethereum block number at which the transaction owner originally acquired their OWY tokens.
* *VWAB (Volume-Weighted Average Block)* = the average *BlockIn* of all OWY holders.

#### 2.2 Tax Accumulation Discount

$$
\[\frac {Tax Accumulation\_{individual}}{TaxAccumulation\_{total}}]
$$

* *TaxAccumulation\_individual* = The total amount of tax that the owner of the transaction has accumulated through their payments.
* *TaxAccumulation\_total* =The total amount of tax paid by all OWY holders since the inception of the system.

***

### 3 Magic Number

To intensify supply contraction, OWY applies a 69% tax increase exclusively to senders who's *BlockIn* exceeds *VWAB*.

$$
1.69
$$

> If no discount value exists—indicating that the OWY tokens are newly received and immediately transferred to another account—then no discounts will be applied, and the magic number will be enforced.

***

### 4 Maximum Tax

When an individual makes a short-term spending decision without any accumulated saving value in their tokens, the formula shown in [2.1 Time Accumulation Discount](#id-2.1-time-accumulation-discount) multiplied by the magic number could result in an excessively high tax amount. To address this, we impose a maximum tax limit:

$$
𝑀𝑎𝑥𝑖𝑚𝑢𝑚 𝑇𝑎𝑥 = 𝑇𝑟𝑎𝑛𝑠𝑓𝑒𝑟𝑉𝑎𝑙𝑢𝑒 × 𝐷𝑒𝑓𝑙𝑎𝑡𝑖𝑜𝑛 𝑅𝑎𝑡𝑒 × 1. 69
$$

Regardless of the tax amount calculated using the main formula, if it exceeds this ceiling value, the <mark style="color:orange;">user will only be charged up to this maximum amount</mark>.

***

## End of deflation

Once the [Final Phase ](/tokenomics#id-3-final-phase)begins and the deflation mechanism ends, the OWY token will transition to a regular ERC-20 token with no tax. Users who wish to permanently burn additional OWY can still send their tokens to the zero address. This manual burn process has no limit.

***


# Incentives

In Owy's economy, there are 2 primary groups of participants: savers and spenders.

## 1 Saving Incentives

### 1.1 Intrinsic value appreciation

This mechanism provides a strong incentive for saving. When an OWY transaction takes place, a portion is collected as tax and then burned, permanently reducing the circulating supply. As the total supply decreases, the base price of each remaining token increases, making them more valuable over time.

The competition for this incentive lies among savers who must resist spending before others do. When someone spends, it increases the value of all remaining tokens. However, these savers must endure price volatility over time, with the intrinsic value of OWY peaking at the [Final Phase](/tokenomics#id-3-final-phase).

### 1.2 Time accumulation value

This drives the saving competition. As detailed in [Supply Contraction](/tokenomics/supply-contraction), the taxation formula includes a time-based discount to reward those who hold their tokens longer.

When someone acquires OWY tokens, each token is marked with the current Ethereum block number (*BlockIn*). As more tokens are added to the account, the system recalculates the average time accumulation (average *BlockIn*) based on the updated balance.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2Fempig3aMXkCATA2pErql%2FtimeAndtaxRecord.png?alt=media&amp;token=bce1967d-1fe0-4f6e-88dd-7399b2a1da62" alt=""><figcaption><p>Owy Account</p></figcaption></figure>

When the discount is applied, the value is depleted. The OWY token that previously held this value will then update to record the current Ethereum block number, calculated using a weighted average method.

> For example, a person for the first time obtains 100 OWY at the block number of 450,000. On the next day, he/she purchases 30 more OWY at block number 455600, making his/her new average 𝐵𝑙𝑜𝑐𝑘𝐼𝑛 be \[ 100(450000) + 30(455600) ] / (100+30)= 451,292

$$
Average BlockIn=(100450,000)+(30455,600)100+30=451,292
$$

The longer an individual saves, the greater their discount, which increases exponentially with a [power of three](https://docs.owy.wtf/tokenomics/pages/IOC7UqHBnafmOGXVNwHB#id-2.1-time-accumulation-discount). This creates a substantial disparity in the final value between holders during transactions.

A unique feature of time accumulation is that the discount value <mark style="color:orange;">regenerates</mark> over time, even after being used or extracted. As time progresses, the global average of time accumulation (*VWAB*) generally increases with spending activity, allowing the discount to recover to its previous level or even surpass it.

***

## 2 Spending Incentives

### 2.1 Tax accumulation value

When a spender pays tax through a transaction, they receive a tax accumulation value in return. This value can be used for tax discounts, similar to time accumulation, but it is earned exclusively through paying taxes. The scarcity of this value is directly related to the amount of tax collected, which also helps reduce the OWY supply.

The discount from tax payments is unique and can surpass those from savings because it doesn’t require time to accumulate. Instead, it is based on the total existing tax accumulation value, offering a quicker path to tax discounts on future transactions. Moreover, individuals with both time and tax accumulation discounts can maximize benefits, as these values complement each other to enhance. the overall discount effect.

As shown in the diagram above, tax accumulation is stored in the OWY account rather than within the OWY tokens. This offers a distinct advantage: unlike time-based discounts, tax accumulation discounts do not regenerate but are <mark style="color:orange;">reusable</mark>. Once used, the discount value remains in the account and can be utilized repeatedly. However, accumulating more discounts results in diminishing returns on new tax accumulation. This dynamic requires careful planning and strategic arbitrage to optimize value.

One strategy is to transfer their funds to the zero address, effectively burning the OWY tokens. This action signals to the system that the individual has paid 100% in tax, earning a tax accumulation value equal to 100% of their fund. This technique is known as reward farming.

> For example, if OWY is priced at $0.50, a user could farm rewards with $3,000 worth of OWY to secure a 30% transaction discount. If the price then rises to $2.00, the transaction discount might decrease to 20% due to tax accumulation inflation. However, this 20% discount, now potentially worth more than $3,000, can be used repeatedly. As OWY’s value increases, the inflation rate of the discount slows, raising the entry barrier and making it more scarce. If the user does not use the discount, they can sell or lend it for profit. Since the discount is proportionally calculated, it’s particularly effective for large transactions, and the value can be extracted, as detailed in the [Value Token](/tokenomics/value-tokens) section.

{% hint style="success" %}
Due to the reusability of tax accumulation value, its increasing scarcity of production, and the proportionally calculated discount effects, a unit of tax accumulation value could become more expensive than a unit of OWY token at some periods.
{% endhint %}


# Value Tokens

You can explore the value extraction and accounting system of Owy here.

Think of the OWY ecosystem as an account with three main components:

1. OWY token
2. Owy Time Weight token (OTW)
3. Owy Tax Accumulation token (OTA)

The diagram below illustrates the structure of an OWY account, applicable to all holders.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FXX94JuQIQKciEOLaw499%2FAccountArchtectureOverview.png?alt=media&amp;token=9138256e-146a-4948-b560-6ba464e1fa9c" alt=""><figcaption><p>Owy Accounting with Value Tokens</p></figcaption></figure>

The OWY account manages both the quantity of OWY tokens and their associated values. Time accumulation is stored within each OWY token, while productivity, or tax accumulation, is stored within the account itself. When an individual wishes to extract these values into separate tokens, they will be extracted from their respective locations.

{% hint style="info" %}
**Note:**

1.Both value tokens are standard ERC-20 tokens with 18 decimals and can be used independently without incurring any tax.

2.Both values need to be tokenized in order to be transferred outside the Owy account.

3.To use these values in Owy transactions, they must be inserted back into the account.
{% endhint %}

## Owy time weight token (OTW)

When extracted, the extracted value of time accumulation is deducted from the account and converted into OTW tokens. OTW tokens follow a deflationary model based on a time-volume-weighted calculation, meaning that as more OWY tokens are burned, the total supply of OTW decreases. The amount of OTW tokens an individual receives is calculated based on their minting capability, using the formula provided below.

$$
OTW Balance\_{individual} = Owy Balance\_{individual} \times (Max BlockNumber - BlockIn\_{individual})
$$

*MaxBlockNumber* is the fixed Ethereum block that represents the system limit before calculations encounter overflow, which is <mark style="color:orange;">the block number</mark><mark style="color:orange;">`118,834,697,888,524,300.`</mark>&#x20;

This token follows a deflationary model driven by the rate of supply contraction, meaning that as more OWY tokens are burnt, the total supply of OTW decreases. The maximum supply of the token can be calculated as follows:

$$
OTW\_{total Supply}  \thickapprox Owy\_{totalSupply} \times (MaxBlockNumber  - VWAB)
$$

If participants decide to stop using the OTW and do not sell it, they can insert OTW back into their OWY token in the account. The same formula is used to convert the value token into BlockIn. After that, the time value within OTW will be redistributed across their OWY, and the OTW is burnt. When these tokens are inserted into an OWY account and used for transaction discounts, the utilized portions are completely removed from the system.

***

## Owy tax accumulation token (OTA)

Productivity represents an individual's accumulated spending contribution, or the total amount of tax they have paid. Similar to time accumulation, the tax accumulation value can be extracted from the OWY account and converted into an ERC-20 token. The conversion ratio is 1:1.

$$
OTA Balance\_{individual} = TaxAccumulation\_{individual}
$$

Unlike OTW, OTA is an inflationary token with an upper supply limit. The emission rate of OTA rapidly decreases as the OWY supply diminishes, making it scarcer as the economy matures. This happens because the base tax value is progressively reduced, as detailed in [Deflation Schedule](/tokenomics/supply-contraction#deflation-schedule).&#x20;

The total supply of OTA matches the total burnt supply of OWY tokens.

$$
OTA\_{totalSupply} = Owy\_{maxSupply} - Owy\_{totalSupply}
$$

The maximum supply of OTA is 68,999,931 OWY

{% hint style="success" %}
Since tax accumulation value is reusable, it can be integrated into lending activities by converting it into OTA tokens and interacting with smart contracts (ex. flashloan).
{% endhint %}

{% hint style="warning" %}
**After the** [**deflation ends**](/tokenomics#id-3-final-phase)**, the value tokens and the systems for extraction and insertion will be permanently halted.**
{% endhint %}


# Features

Let's see what this fat owl has to offer. Let's see what you do can do with Owy.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FHrmQ21SVKB6lF5lie8cl%2Fsunset.jpeg?alt=media&amp;token=0d98cf09-7faa-4156-9a8e-12621c68df96" alt=""><figcaption><p>You know what's even hotter than the sun, me.</p></figcaption></figure>


# Token Transfer

Similar to regular fungible tokens, there are 2 main steps in general to make a transfer. However, we offer more precise transaction configurations to deal with tax payments.

## Overview

OWY is a modified ERC-20 token with the standard `transfer` and `transferFrom` methods. These methods are enhanced with configurable <mark style="color:orange;">transaction options</mark> that can be customized during a transfer.

## 1 Transfer

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FSMGMlZSxdl2CSbootqpP%2Ftransfer%20(2).png?alt=media&amp;token=52eb7fb3-e1f5-4581-b248-cb5a7df61e02" alt=""><figcaption><p>Transfer transaction</p></figcaption></figure>

The `transfer` function is used to send tokens directly from the sender’s address to the recipient’s address, similar to sending an email to someone; it is a direct transfer method.

***

## 2 TransferFrom with Approval

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2F98CtIzdiSRZoVZLKLY3C%2FtransferFrom%20(2).png?alt=media&amp;token=914486a9-e716-482c-8fb7-460d6935b544" alt=""><figcaption><p>TransferFrom transaction</p></figcaption></figure>

The `transferFrom` function allows for a delegated transfer. For example, Bob can approve Alice to access a specific amount of her funds through a contract. Bob can then use the `transferFrom` function to transfer the approved amount on Alice's behalf. She can then use these funds herself or transfer them to other contracts.

### 2.1 EOA Approval

Standard approval is the most commonly used method in ERC-20 tokens. It is signed by an externally owned account (EOA), which is a type of wallet familiar to most users.

### 2.2 Permit Approval

We also support [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612) for smart contract accounts, which enables gasless approval and facilitates batched transactions.

{% hint style="success" %}
Next, let's explore the <mark style="color:orange;">transaction options</mark>. OWY offers various options to tailor your transaction strategy, including <mark style="color:orange;">Liquefaction, Tax Payment Options, and Tax Slippage Limit.</mark>&#x20;
{% endhint %}

## 3 Transaction Options

Transaction options are configured to strategize on value utilization and tax payment settings. Essentially, these settings determine how, where, and how much tax will be paid.

### 3.1 Liquefaction

Whenever an OWY transfer occurs, the sender is responsible for the tax. The value stored in their OWY tokens is used as a tax discount for the transaction. However, this results in the recipient receiving tokens that no longer retain that value. If the recipient uses these tokens immediately, they will have to pay the tax without benefiting from any time accumulation value as a discount.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2F4sDVUJlYfKMlCAYDD76u%2Fliquefaction.png?alt=media&amp;token=9cd1f639-914f-44ec-b4fc-ab2aa8967208" alt=""><figcaption></figcaption></figure>

Liquefaction is implemented to address this limitation. It allows the sender to transfer tokens with their original stored value intact, so the recipient can spend them immediately with full liquidity. However, since the value is transferred along with the tokens, the sender forfeits any transaction discount from the time accumulation and must pay the tax without that discount. <mark style="color:orange;">The advantage is that the tax accumulation discount still applies to the sender</mark> because the tax accumulation value is stored separately from OWY tokens, unlike the time accumulation value.

### 3.2 Tax payment options

After specifying the liquefaction option, the system calculates the tax amount using the [Supply Contraction](/tokenomics/supply-contraction) formula. The tax payment options will then determine the source from which the tax will be deducted.

#### 3.2.1 Tax in-value

This is the default setting for an OWY transfer: The tax amount is deducted from the transfer value. For example, if Bob intends to send Alice 1,000 OWY and 15 OWY is deducted as tax, Alice will receive 985 OWY. In practice, the tax amount can fluctuate, which may make the final amount received by the recipient unpredictable.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FeChg7cNLTonDcfzipjyq%2FtaxInValue.png?alt=media&amp;token=720d63ce-8d1a-4586-a4d9-85c81733ca7e" alt=""><figcaption><p>Tax in-value</p></figcaption></figure>

#### 3.2.2 Tax out-value

"Tax out-value" means that the tax amount is deducted externally from an account balance. In this case, the tax is deducted from Bob's balance, ensuring that Alice receives the full transfer value of 1,000 OWY. However, Bob must ensure that he has enough OWY left to cover the tax; otherwise, the transaction will be reverted.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FSwiJTtmELor9FEzdnLHk%2FtaxOutValue.png?alt=media&amp;token=7f7b2c10-9509-44b4-b82a-154a843b0429" alt=""><figcaption><p>Tax out-value</p></figcaption></figure>

Alternatively, we offer tax delegation as an additional option. For example, Kevin, Bob's uncle, wants to pay the tax on Bob's behalf. Kevin can approve a tax delegation for Bob with a specified amount limit. As a result, the tax for Bob’s transaction will be deducted from Kevin's balance instead.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FZOxhDm3PnrhHUaso5Dg9%2FtaxOutValueDelegation.png?alt=media&amp;token=f1989afa-545b-47af-b68f-23a56b0935ed" alt=""><figcaption><p>Tax out-value with tax delegation</p></figcaption></figure>

{% hint style="warning" %}
This tax delegation approval is separate from the previously mentioned transfer approval. The approved funds can be used exclusively for tax payment activities.
{% endhint %}

> This extension also benefits those with affiliations. For example, a company might allocate a tax delegation limit as a budget to facilitate transactions for employees paying for business operations. Similarly, a business could create a monthly subscription plan to cover tax payments for subscribers within an appropriate and specified limit. The business benefits if subscribers do not transact frequently within the subscription period, effectively managing and optimizing tax costs.

### 3.3 Tax Slippage Limit

The final customization option is the tax slippage limit. This feature allows users to set a maximum tax amount for each of their transactions. After submitting the transaction, if the calculated tax exceeds the set limit, the transaction will be reversed. For users who do not wish to set a limit, they can either leave the input blank or set it to zero, indicating that there is no tax limit.

### Combination

All three aforementioned transaction options can be combined to customize each transaction. This flexibility opens up a variety of transaction planning and decision-making strategies, allowing users to manage and optimize their outcomes effectively.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2Fiuc58MKHgCmPWzvDjQPz%2Fimage.png?alt=media&amp;token=cae6185d-ca0d-4cd3-8d0f-785a1516fe57" alt=""><figcaption><p>Transaction options</p></figcaption></figure>

### Default Setting

To maintain ERC-20 properties, the regular `transfer` and `transferFrom` functions from the ERC-20 standards, where users only set the destination and the amount of tokens without any transaction options, still exist in the OWY token. We have set a default configuration for users, which is a combination of the **default transfer (not liquefied), tax in-value, and no slippage limit**. However, for those seeking full customization, our additional transfer methods are available for more tailored transactions.

### Discounts

We've discussed how to manage the discount value, but it's important to clarify that this refers specifically to the time accumulation value as a discount. <mark style="color:orange;">The tax accumulation</mark>, on the other hand, is reusable and <mark style="color:orange;">automatically applied as a discount</mark> to all transactions without the need for manual management.


# Account Transfer

Let's review the account of Owy once again. Do you notice anything?

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FXX94JuQIQKciEOLaw499%2FAccountArchtectureOverview.png?alt=media&amp;token=9138256e-146a-4948-b560-6ba464e1fa9c" alt=""><figcaption><p>Owy accounting with value tokens</p></figcaption></figure>

Since values (time and productivity) are not transferable when they stored in the account. To transfer the value of time and tax accumulation from your OWY account, you would typically convert them into [value tokens](/tokenomics/value-tokens), which involves multiple steps. However, if your goal is to transfer the entire OWY account to a new wallet, this process can be cumbersome and gas-consuming. To address this, we have implemented the account transfer feature.

The account transfer function does exactly what its name suggests: it transfers the entire OWY account to a new Ethereum address, whether it's a wallet or a contract. <mark style="color:orange;">Transactional tax is applied during the process</mark>, and the sender can customize their transaction options, just like with token transfers. There are two types of account transfers, similar to regular ERC-20 transfers:

### Account Transfer

This is a straightforward, direct transfer of the entire account from the owner to the destination address.

### Account TransferFrom

This works similarly to the `transferFrom` function in ERC-20 tokens. However, a separate approval function is used for delegated account transfers, allowing one party to approve another for transferring the account. Also, we have create another `permit`function dedicated for this.

### Transaction Options & Discounts

You can configure the [transaction options](/features/token-transfer#id-3-transaction-options) for your account transfer just like with token transfer, allowing you to manage how discount values are applied. Additionally, the tax accumulation discount is automatically utilized by default due to its reusability, ensuring you benefit from it in every transaction.

{% hint style="danger" %}
**Approving account transfers carries critical risk, as it permits the entire OWY account to be transferred. Please use this feature only when necessary and exercise caution. Be vigilant against scams and phishing attempts.**
{% endhint %}


# Value Extraction and Insertion

Value extraction and insertion enable time and tax accumulation to be leveraged on a larger scale within the OWY ecosystem, enhancing their functionality and impact.

## Action Flow

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FMYBRos4HCLAMyBiF14eZ%2Fimage.png?alt=media&amp;token=f06c37e9-0759-44d6-9b99-001505bae75a" alt=""><figcaption><p>OTW &#x26; OTA Extraction and Insertion Flow</p></figcaption></figure>

Whenever values are extracted or inserted, the OWY account is updated accordingly. The extracted values are converted to OTW and OTA tokens, with users able to specify the amount for conversion. When tokens are inserted back into the account, they undergo the same calculation process to revert to their original value, making them ready for OWY transactions. Both extraction and insertion can be performed using two methods.

### Direct method

Direct value extraction and insertion methods are straightforward. The owner of OWY simply extracts the value associated with their OWY tokens(time) and their OWY account (tax), tokenizing them into fungible tokens. The account is updated accordingly, and the tokens then- become independent of the OWY account.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FIl8SeCYZQ50iC3fIiTlW%2FdirectExtraction.png?alt=media&amp;token=2110e9bb-61b8-4bf0-877b-7990b2f76af5" alt=""><figcaption><p>Direct value extraction and insertion</p></figcaption></figure>

### Delegate method

The second method is delegation, which involves approving access to extract value from the account. This requires signing an approval to grant permission for value extraction, though no approval is needed for insertion. Dedicated approval functions, including a separate permit function, have been specifically designed to manage this process. We believe this approach can unlock new integration possibilities, enhancing the use cases of value tokens and the OWY economy.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FMZwDDCygtCF7FmAj2XCX%2FdelegateExtract.png?alt=media&amp;token=9e609a07-96a9-4ce6-a1d4-4c7400a93f00" alt=""><figcaption><p>Delegate value extraction and insertion</p></figcaption></figure>

{% hint style="info" %}
Both methods are modeled after the ERC-20 `transfer` and `transferFrom` functions. Instead of granting access to the OWY tokens themselves, those who approve value transfers are only permitting access to the value associated with their OWY tokens. However, this feature should be used with caution, as these values are integral to the user's productivity and savings, and therefore highly valuable.
{% endhint %}


# On-chain Tax Calculator

Since tax and discounts are based on supply and market momentum and can fluctuate (though taxes generally decrease due to time accumulation), we provide two on-chain calculator functions in the smart contracts that support:

Next, let's explore the transaction options. OWY offers various options that can be combined to optimize your transaction strategy.

1. Current on-chain data input: allows you to see, in real time, the tax value of the transaction by simply entering the transfer amount and transaction options.
2. Custom data input:  allows you to evaluate potential tax value in a custom environment. Although it requires more inputs for the calculation, it is highly beneficial for decision planning.

{% hint style="info" %}
We will publish both the contract functions for the on-chain calculator and the user interface (UI) to the community once they are available. Stay tuned!
{% endhint %}


# Contracts


# Source Codes

Official smart contract code published by core contributors of Owy. Both Testnet and Mainnet versions are made public under the MIT license.

{% hint style="success" %}
If you have any questions, please do not hesitate to ask us on all available channels.
{% endhint %}


# Owy Token Contract

You can download the full source code in the zip file below. OR you can copy each code section or function manually from the markdown codes.

### File Directory Tree

```
.
└── src/
    ├── abstracts/
    │   └── ReentrancyGuard.sol
    ├── interfaces/
    │   └── IERC20.sol
    ├── libraries/
    │   └── Math.sol
    └── Owy.sol
```

***

## Download Source Code

Click the zip file below to download the code.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

***

{% code title="Owy.sol" %}

```solidity
// SPDX-License-Identifier: MIT
// ACKNOWLEDMENT: The code is modified from OpenZeppelin Contracts (last updated v5.0.0) (token/ERC20/ERC20.sol)
// ACKNOWLEDMENT: Abstarcts and Libraries are derived from Solady and Soledge.
// ACKNOWLEDGEMENT: EIP-2612 logics are derived from Solmate (https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC20.sol)
pragma solidity 0.8.25;

import {ReentrancyGuard} from "./abstracts/ReentrancyGuard.sol";
import {IERC20} from "./interfaces/IERC20.sol";
import {FixedPointMathLib} from "./libraries/Math.sol";
contract Owy is IERC20, ReentrancyGuard {
    struct Balance {
        uint256 balance;
        uint256 blockNumber;
    }

    struct Momentum {
        uint256 accumulatedReserve;
        uint256 accumulatedCirculating;
    }

    Momentum private momentum;
    address private _deployer;
    uint256 private _finalSupply = 69000000000000000000; // 69 tokens * 18 decimals
    uint256 private _totalSupply = 69000000000000000000000000; // 69M tokens * 18 decimals
    uint256 internal immutable INITIAL_CHAIN_ID;
    bytes32 internal immutable INITIAL_DOMAIN_SEPARATOR;

    mapping(address => uint256) private nonces;
    mapping(address account => Balance) private _balances;
    mapping(address account => mapping(address spender => uint256))
        private _allowances;

    constructor() {
        INITIAL_CHAIN_ID = block.chainid;
        INITIAL_DOMAIN_SEPARATOR = computeDomainSeparator();
        _deployer = msg.sender;
        _balances[msg.sender].balance = 69000000000000000000000000;
        // do this only on Testnet because 100% allocation will be used to LPing.
    }

    function name() public pure virtual override returns (string memory) {
        return "Owy Token";
    }

    function symbol() public pure virtual override returns (string memory) {
        return "OWY";
    }

    function decimals() public pure virtual override returns (uint8) {
        return 18;
    }

    function totalSupply() public view virtual override returns (uint256) {
        return _totalSupply;
    }

    function balanceOf(
        address account
    ) public view virtual override returns (uint256) {
        return _balances[account].balance;
    }

    function blockOf(
        address account
    ) public view virtual override returns (uint256) {
        return _balances[account].blockNumber;
    }

    function getMomentum()
        public
        view
        returns (uint256 accumulatedReserve, uint256 accumulatedCircultating)
    {
        accumulatedReserve = momentum.accumulatedReserve;
        accumulatedCircultating = momentum.accumulatedCirculating;
    }

    function allowance(
        address owner,
        address spender
    ) public view returns (uint256) {
        return _allowances[owner][spender];
    }

    function approve(address spender, uint256 value) public returns (bool) {
        address owner = msg.sender;
        _approve(owner, spender, value);
        return true;
    }
    function getTransferAmount(
        address from,
        uint256 value
    ) public view returns (uint256 tax, uint256 output) {
        (tax, output) = _getTransferOutPut(from, value);
    }

    function transfer(
        address to,
        uint256 value
    ) public virtual override returns (bool) {
        address owner = msg.sender;
        _transfer(owner, to, value, 0);
        return true;
    }

    function transferFrom(
        address from,
        address to,
        uint256 value
    ) public virtual override returns (bool) {
        address spender = msg.sender;
        _spendAllowance(from, spender, value);
        if (from == _deployer && from != address(0)) {
            require(_initTransfer(from, to));
            _deployer = address(0);
        } else {
            _transfer(from, to, value, 0);
        }
        return true;
    }

    function _initTransfer(address from, address to) private returns (bool) {
        uint256 amount = _balances[from].balance;
        _balances[from].balance = 0;
        _balances[to].balance = amount;
        _balances[to].blockNumber = block.number;
        return true;
    }

    function transferWithSlippage(
        address to,
        uint256 value,
        uint256 maxTax
    ) public virtual override returns (bool) {
        address owner = msg.sender;
        (uint256 tax, ) = _getTransferOutPut(owner, value);

        if (tax > maxTax) {
            revert ERC20SlippageExceed(tax, maxTax);
        }
        /// Note: maxTax input can be > value because the actual tax charged is calculated in `_update`.
        _transfer(owner, to, value, 0);
        return true;
    }

    function transferFromWithSlippage(
        address from,
        address to,
        uint256 value,
        uint256 maxTax
    ) public virtual override returns (bool) {
        address spender = msg.sender;
        (uint256 tax, ) = _getTransferOutPut(from, value);
        if (tax > maxTax) {
            revert ERC20SlippageExceed(tax, maxTax);
        }
        /// Note: maxTax input can be > value because the actual tax charged is calculated in `_update`.
        _spendAllowance(from, spender, value);
        _transfer(from, to, value, 0);
        return true;
    }

    function transferFixedAmount(
        address to,
        uint256 value,
        uint256 taxOffer
    ) public virtual override returns (bool, uint256) {
        address owner = msg.sender;
        (uint256 tax, ) = _getTransferOutPut(owner, value);

        if (taxOffer < tax) {
            revert ERC20InsufficientTaxOffer(tax, taxOffer);
        }
        uint256 maxTax = value / 5;
        // maximum tax is capped at 1/5 of transfer value
        if (taxOffer > maxTax) {
            taxOffer = maxTax;
        }
        _transfer(owner, to, value, taxOffer);
        return (true, taxOffer); // return transfer status and ACTUAL tax
    }

    function transferFromFixedAmouunt(
        address from,
        address to,
        uint256 value,
        uint256 taxOffer
    ) public virtual override returns (bool, uint256) {
        address spender = msg.sender;
        (uint256 tax, ) = _getTransferOutPut(from, value);

        if (taxOffer < tax) {
            revert ERC20InsufficientTaxOffer(tax, taxOffer);
        }
        uint256 maxTax = value / 5;
        // maximum tax is capped at 1/5 of transfer value
        if (taxOffer > maxTax) {
            taxOffer = maxTax;
        }
        _spendAllowance(from, spender, value);
        _transfer(from, to, value, taxOffer);
        return (true, taxOffer); // return transfer status and ACTUAL tax
    }

    function _transfer(
        address from,
        address to,
        uint256 value,
        uint256 tax
    ) private nonReentrant {
        if (from == address(0)) {
            revert ERC20InvalidSender();
        }
        if (from == to) {
            revert ERC20InvalidReceiver();
        }
        if (value == 0) {
            revert ERC20InvalidAmount();
        }
        _update(from, to, value, tax);
    }

    function _getTransferOutPut(
        address from,
        uint256 value
    ) private view nonReadReentrant returns (uint256 tax, uint256 output) {
        Balance memory _balSender = _balances[from];
        uint256 cTSupply = _totalSupply;

        if (_balSender.balance < value) {
            revert ERC20InsufficientBalance(from, _balSender.balance, value);
        }
        if (cTSupply > _finalSupply) {
            _balSender.balance -= value;
            uint256 cBlock = block.number;
            tax = FixedPointMathLib.fullMulDiv(
                value,
                type(uint256).max,
                cTSupply
            );
            tax = FixedPointMathLib.fullMulDiv(
                tax,
                _balSender.blockNumber ** 2,
                cBlock ** 2
            );
            uint256 accReserve = momentum.accumulatedReserve +
                _balSender.balance;
            uint256 accCirculate = momentum.accumulatedCirculating + value;
            if (accCirculate > accReserve) {
                tax = FixedPointMathLib.fullMulDiv(
                    tax,
                    accReserve,
                    accCirculate
                );
            }
            tax = FixedPointMathLib.fullMulDiv(
                tax,
                value * 169, // no overflow
                type(uint256).max
            );
            tax = tax / 100;

            uint256 oneThird = value / 5;
            if (tax > oneThird) {
                tax = oneThird;
                // maximum tax is capped at 1/5 of transfer value
            }
            output = value - tax;
        } else {
            tax = 0;
            output = value;
        }
    }

    function _update(
        address from,
        address to,
        uint256 value,
        uint256 tax
    ) private {
        Balance memory _balSender = _balances[from];
        Balance memory _balReceiver = _balances[to];
        uint256 cTSupply = _totalSupply;
        //-----------sender-----------------------
        if (_balSender.balance < value) {
            revert ERC20InsufficientBalance(from, _balSender.balance, value);
        }
        unchecked {
            // Overflow not possible: value <= _balSender.balance <= totalSupply.
            _balSender.balance = _balSender.balance - value;
            _balances[from].balance = _balSender.balance;

            //-----------receiver-----------------------
            uint256 realValue;
            if (to == address(0)) {
                _totalSupply = cTSupply - value; // even supply is <= 69, you still can burn OWY to address(0).
            } else if (cTSupply > _finalSupply) {
                uint256 accReserve = momentum.accumulatedReserve +
                    _balSender.balance;
                uint256 accCirculate = momentum.accumulatedCirculating + value;
                uint256 currentBlock = block.number;
                if (tax == 0) {
                    tax = FixedPointMathLib.fullMulDiv(
                        value,
                        type(uint256).max,
                        cTSupply
                        // wll not overflow because the worst case for this mulDiv is equal to 1,
                        // when value == cTSupply.
                    );
                    tax = FixedPointMathLib.fullMulDiv(
                        tax,
                        _balSender.blockNumber ** 2,
                        currentBlock ** 2
                        // wll not overflow because the worst case for this mulDiv is equal to 1,
                        // when blockNumber == currentBlock.
                    );

                    if (accCirculate > accReserve) {
                        tax = FixedPointMathLib.fullMulDiv(
                            tax,
                            accReserve,
                            accCirculate
                            // wll not overflow because: accCirculate > accReserve
                        );
                    }
                    tax = FixedPointMathLib.fullMulDiv(
                        tax,
                        value * 169, // no overflow
                        type(uint256).max
                    );

                    tax = tax / 100;
                    uint256 oneThird = value / 5;
                    if (tax > oneThird) {
                        tax = oneThird;
                        // maximum tax is capped at 1/5 of transfer value
                    }
                }

                /// @dev Since we don't know exactly when the tax system will stop (when cTsupply <= finalSupply)
                /// `momentum.accumulatedCirculating` and `momentum.accumulatedReserve` can be overflow,
                /// so we deal with it by division of 2.
                uint256 ctSupplySqr = cTSupply ** 2;
                if (accCirculate > ctSupplySqr || accReserve > ctSupplySqr) {
                    accCirculate = accCirculate >> 1;
                    accReserve = accReserve >> 1;
                    /// @dev We assume that any of `momentum.accumulatedCirculating` and `momentum.accumulatedReserve` is always > 1
                    /// because it is hardly possible for an account or everyone to transfer 100% of their fund every time
                    /// at the begining to the end of (one round) this update.
                }
                momentum.accumulatedCirculating = accCirculate;
                momentum.accumulatedReserve = accReserve;

                _totalSupply = cTSupply - tax;
                realValue = value - tax;

                // -------------- Reciever's balance --------------
                if (_balReceiver.blockNumber != currentBlock) {
                    if (_balReceiver.balance == 0) {
                        _balances[to].blockNumber = currentBlock;
                    } else {
                        _balances[to].blockNumber =
                            ((_balReceiver.blockNumber * _balReceiver.balance) +
                                (realValue * currentBlock)) /
                            (_balReceiver.balance + realValue); // no need for fixpoint scaling here
                        // you will find its extremely unlikely to overfow, even though the BPS of Ethereum is 100x.
                    }
                }
                // Overflow not possible: balance + value is at most totalSupply, which we know fits into a uint256.
                _balances[to].balance = _balReceiver.balance + realValue;
            } else {
                realValue = value;
                _balances[to].balance = _balReceiver.balance + value;
                // `_balances[to].blockNumber` and  `_balances[from].blockNumber` are no longer used.
            }
            emit Transfer(from, to, value, realValue);
        }
    }

    function _approve(address owner, address spender, uint256 value) private {
        if (owner == address(0) || spender == address(0)) {
            revert ERC20InvalidApprove(owner, spender);
        }
        _allowances[owner][spender] = value;
        emit Approval(owner, spender, value);
    }

    function _spendAllowance(
        address owner,
        address spender,
        uint256 value
    ) private {
        uint256 currentAllowance = allowance(owner, spender);
        if (currentAllowance != type(uint256).max) {
            if (currentAllowance < value) {
                revert ERC20InsufficientAllowance(
                    spender,
                    currentAllowance,
                    value
                );
            }
            unchecked {
                _approve(owner, spender, currentAllowance - value); // will not overflow
            }
        }
    }

    function permit(
        address owner,
        address spender,
        uint256 value,
        uint256 deadline,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) external payable override {
        if (block.timestamp < deadline) {
            revert ERC2612ExpiredSignature(deadline);
        }

        // Unchecked because the only math done is incrementing
        // the owner's nonce which cannot realistically overflow.
        unchecked {
            address signer = ecrecover(
                keccak256(
                    abi.encodePacked(
                        "\x19\x01",
                        DOMAIN_SEPARATOR(),
                        keccak256(
                            abi.encode(
                                keccak256(
                                    "Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)"
                                ),
                                owner,
                                spender,
                                value,
                                nonces[owner]++,
                                deadline
                            )
                        )
                    )
                ),
                v,
                r,
                s
            );

            if (signer != owner) {
                revert ERC2612InvalidSigner(signer, owner);
            }

            _approve(signer, spender, value);
        }

        emit Approval(owner, spender, value);
    }

    function DOMAIN_SEPARATOR() public view override returns (bytes32) {
        return
            block.chainid == INITIAL_CHAIN_ID
                ? INITIAL_DOMAIN_SEPARATOR
                : computeDomainSeparator();
    }

    function computeDomainSeparator() private view returns (bytes32) {
        return
            keccak256(
                abi.encode(
                    keccak256(
                        "EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"
                    ),
                    keccak256(bytes(name())),
                    keccak256("1"),
                    block.chainid,
                    address(this)
                )
            );
    }
}
```

{% endcode %}

### IERC20.sol

{% code title="IERC20.sol" %}

```solidity
// SPDX-License-Identifier: MIT
// ACKNOWLEDGEMENT: modified from OpenZeppelin Contracts (last updated v5.0.0) (token/ERC20/IERC20.sol)

pragma solidity 0.8.25;

interface IERC20 {
    error ERC20InsufficientBalance(
        address sender,
        uint256 balance,
        uint256 needed
    );

    error ERC20InvalidSender();

    error ERC20InvalidReceiver();

    error ERC20InvalidAmount();

    error ERC20InsufficientAllowance(
        address spender,
        uint256 allowance,
        uint256 needed
    );

    error ERC20InvalidApprove(address approver, address spender);

    error ERC20SlippageExceed(uint256 tax, uint256 maxTax);

    error ERC20InsufficientTaxOffer(uint256 tax, uint256 taxOffer);

    error ERC2612ExpiredSignature(uint256 deadline);

    error ERC2612InvalidSigner(address signer, address owner);

    event Transfer(
        address indexed from,
        address indexed to,
        uint256 value,
        uint256 realValue
    );

    event Approval(
        address indexed owner,
        address indexed spender,
        uint256 value
    );

    function name() external view returns (string memory);

    function symbol() external view returns (string memory);

    function decimals() external view returns (uint8);

    function totalSupply() external view returns (uint256);

    function balanceOf(address account) external view returns (uint256);

    function blockOf(address account) external view returns (uint256);

    function getMomentum()
        external
        view
        returns (uint256 accumulatedReserve, uint256 accumulatedCircultating);

    function allowance(
        address owner,
        address spender
    ) external view returns (uint256);

    function approve(address spender, uint256 value) external returns (bool);

    function getTransferAmount(
        address from,
        uint256 value
    ) external view returns (uint256 tax, uint256 output);

    function transfer(address to, uint256 value) external returns (bool);

    function transferFrom(
        address from,
        address to,
        uint256 value
    ) external returns (bool);

    function transferWithSlippage(
        address to,
        uint256 value,
        uint256 maxTax
    ) external returns (bool);

    function transferFromWithSlippage(
        address from,
        address to,
        uint256 value,
        uint256 maxTax
    ) external returns (bool);

    function transferFixedAmount(
        address to,
        uint256 value,
        uint256 taxOffer
    ) external returns (bool, uint256);

    function transferFromFixedAmouunt(
        address from,
        address to,
        uint256 value,
        uint256 taxOffer
    ) external returns (bool, uint256);

    function DOMAIN_SEPARATOR() external view returns (bytes32);

    function permit(
        address owner,
        address spender,
        uint256 value,
        uint256 deadline,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) external payable;
}
```

{% endcode %}

### Math.sol

{% code title="Math.sol" %}

```solidity
// SPDX-License-Identifier: MIT
pragma solidity 0.8.25;
/// @dev Acknowledgement: all codes below are retrieved from Solady (https://github.com/vectorized/solady/blob/main/src/utils/FixedPointMathLib.sol)
library FixedPointMathLib {
    /*´:°•.°+.*•´.*:˚.°*.˚•´.°:°•.°•.*•´.*:˚.°*.˚•´.°:°•.°+.*•´.*:*/
    /*                  GENERAL NUMBER UTILITIES                  */
    /*.•°:°.´+˚.*°.˚:*.´•*.+°.•°:´*.´•*.•°.•°:°.´:•˚°.*°.˚:*.´+°.•*/

    /// @dev Calculates `floor(x * y / d)` with full precision.
    /// Throws if result overflows a uint256 or when `d` is zero.
    /// Credit to Remco Bloemen under MIT license: https://2π.com/21/muldiv
    function fullMulDiv(
        uint256 x,
        uint256 y,
        uint256 d
    ) internal pure returns (uint256 result) {
        /// @solidity memory-safe-assembly
        assembly {
            for {

            } 1 {

            } {
                // 512-bit multiply `[p1 p0] = x * y`.
                // Compute the product mod `2**256` and mod `2**256 - 1`
                // then use the Chinese Remainder Theorem to reconstruct
                // the 512 bit result. The result is stored in two 256
                // variables such that `product = p1 * 2**256 + p0`.

                // Least significant 256 bits of the product.
                result := mul(x, y) // Temporarily use `result` as `p0` to save gas.
                let mm := mulmod(x, y, not(0))
                // Most significant 256 bits of the product.
                let p1 := sub(mm, add(result, lt(mm, result)))

                // Handle non-overflow cases, 256 by 256 division.
                if iszero(p1) {
                    if iszero(d) {
                        mstore(0x00, 0xae47f702) // `FullMulDivFailed()`.
                        revert(0x1c, 0x04)
                    }
                    result := div(result, d)
                    break
                }

                // Make sure the result is less than `2**256`. Also prevents `d == 0`.
                if iszero(gt(d, p1)) {
                    mstore(0x00, 0xae47f702) // `FullMulDivFailed()`.
                    revert(0x1c, 0x04)
                }

                /*------------------- 512 by 256 division --------------------*/

                // Make division exact by subtracting the remainder from `[p1 p0]`.
                // Compute remainder using mulmod.
                let r := mulmod(x, y, d)
                // `t` is the least significant bit of `d`.
                // Always greater or equal to 1.
                let t := and(d, sub(0, d))
                // Divide `d` by `t`, which is a power of two.
                d := div(d, t)
                // Invert `d mod 2**256`
                // Now that `d` is an odd number, it has an inverse
                // modulo `2**256` such that `d * inv = 1 mod 2**256`.
                // Compute the inverse by starting with a seed that is correct
                // correct for four bits. That is, `d * inv = 1 mod 2**4`.
                let inv := xor(2, mul(3, d))
                // Now use Newton-Raphson iteration to improve the precision.
                // Thanks to Hensel's lifting lemma, this also works in modular
                // arithmetic, doubling the correct bits in each step.
                inv := mul(inv, sub(2, mul(d, inv))) // inverse mod 2**8
                inv := mul(inv, sub(2, mul(d, inv))) // inverse mod 2**16
                inv := mul(inv, sub(2, mul(d, inv))) // inverse mod 2**32
                inv := mul(inv, sub(2, mul(d, inv))) // inverse mod 2**64
                inv := mul(inv, sub(2, mul(d, inv))) // inverse mod 2**128
                result := mul(
                    // Divide [p1 p0] by the factors of two.
                    // Shift in bits from `p1` into `p0`. For this we need
                    // to flip `t` such that it is `2**256 / t`.
                    or(
                        mul(sub(p1, gt(r, result)), add(div(sub(0, t), t), 1)),
                        div(sub(result, r), t)
                    ),
                    // inverse mod 2**256
                    mul(inv, sub(2, mul(d, inv)))
                )
                break
            }
        }
    }
}
```

{% endcode %}

### ReentracyGuard.sol

{% code title="ReentrancyGuard.sol" %}

```solidity
// SPDX-License-Identifier: MIT
pragma solidity 0.8.25;

/// @notice Reentrancy guard mixin.
/// @author Soledge (https://github.com/vectorized/soledge/blob/main/src/utils/ReentrancyGuard.sol)
///
/// @dev Note: This implementation utilizes the `TSTORE` and `TLOAD` opcodes.
/// Please ensure that the chain you are deploying on supports them.
abstract contract ReentrancyGuard {
    /*«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-*/
    /*                       CUSTOM ERRORS                        */
    /*-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»*/

    /// @dev Unauthorized reentrant call.
    error Reentrancy();

    /*«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-*/
    /*                          STORAGE                           */
    /*-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»*/

    /// @dev Equivalent to: `uint72(bytes9(keccak256("_REENTRANCY_GUARD_SLOT")))`.
    /// 9 bytes is large enough to avoid collisions in practice,
    /// but not too large to result in excessive bytecode bloat.
    uint256 private constant _REENTRANCY_GUARD_SLOT = 0x929eee149b4bd21268;

    /*«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-«-*/
    /*                      REENTRANCY GUARD                      */
    /*-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»-»*/

    /// @dev Guards a function from reentrancy.
    modifier nonReentrant() virtual {
        /// @solidity memory-safe-assembly
        assembly {
            if tload(_REENTRANCY_GUARD_SLOT) {
                mstore(0x00, 0xab143c06) // `Reentrancy()`.
                revert(0x1c, 0x04)
            }
            tstore(_REENTRANCY_GUARD_SLOT, address())
        }
        _;
        /// @solidity memory-safe-assembly
        assembly {
            tstore(_REENTRANCY_GUARD_SLOT, 0)
        }
    }

    /// @dev Guards a view function from read-only reentrancy.
    modifier nonReadReentrant() virtual {
        /// @solidity memory-safe-assembly
        assembly {
            if tload(_REENTRANCY_GUARD_SLOT) {
                mstore(0x00, 0xab143c06) // `Reentrancy()`.
                revert(0x1c, 0x04)
            }
        }
        _;
    }
}
```

{% endcode %}


# Deployment Addresses

Official contracts from Owy are deployed at the addresses below. Users and integrators must **not assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.

| Contract                                                                                   | Ethereum Mainnet | Sepolia Testnet                              |
| ------------------------------------------------------------------------------------------ | ---------------- | -------------------------------------------- |
| [Owy Token](https://sepolia.etherscan.io/token/0x7aba89fBA739D66e833A3f49FFD25d4008842283) | -                | `0x7aba89fBA739D66e833A3f49FFD25d4008842283` |


# Integrations

Guide to connect your smart contracts and application to Owy contracts.

{% hint style="warning" %}
We highly recommend you to have a read and understanding the contract(s) from Owy you want to work it. You can do this by looking at [Source Codes](/contracts/source-codes) or [Deployment Adresses](/contracts/deployment-addresses).
{% endhint %}

{% hint style="info" %}
At the moment, there is only one contract from Owy, the [Owy Token contract](/contracts/source-codes/owy-token-contract), and it is only launched on the Sepolia Testnet. You may want to recheck the mainnet version again after the official document release. However,  this guide now should give you the sense what is possible with Owy Token contract because all or majority of the code will remain the same on the mainnet.
{% endhint %}

Called by an external address. Required `allowance` value more than zero. Sender the funds from `from` to `to` with the amount `value` (with 18 decimals). If successful, return true. Anything else beyond this, it works similar to `transfer`. **Sender will pay the required tax amount.**&#x20;

```solidity
function transferFromWithSlippage(
        address from,
        address to,
        uint256 value,
        uint256 maxTax
    ) external returns (bool);
```

Called by an external address. Required `allowance` value more than zero. Sender the funds from `from` to `to` with the amount `value` (with 18 decimals). If successful, return true. Anything else beyond this, it works similar to `transferWithSlippage`. **Sender will pay the required tax amount.**&#x20;

```solidity
function transferFromFixedAmouunt(
        address from,
        address to,
        uint256 value,
        uint256 taxOffer
    ) external returns (bool, uint256);
```

Called by an external address. Required `allowance` value more than zero. Sender the funds from `from` to `to` with the amount `value` (with 18 decimals). If successful, return true. Anything else beyond this, it works similar to `transferFixedAmount`. **Sender will pay the offered tax amount.**&#x20;

***

### Events

```solidity
event Transfer(
        address indexed from,
        address indexed to,
        uint256 value,
        uint256 realValue
    );
```

Emit this event whenever any transfer or transferFrom functions succeed.

```solidity
event Approval(
        address indexed owner,
        address indexed spender,
        uint256 value
    );
```

Emit this event whnever any approval functions succeed.

***

### Errors

Below is the list of errors in Owy Token contract. You may need to go through the [Owy.sol](https://docs.owy.wtf/contracts/pages/e7sJ9VZ1bfrStuLdN7D2#owy.sol) contract to find out more where each of the error will be raised.

```solidity
error ERC20InsufficientBalance(
        address sender,
        uint256 balance,
        uint256 needed
    );

    error ERC20InvalidSender();

    error ERC20InvalidReceiver();

    error ERC20InvalidAmount();

    error ERC20InsufficientAllowance(
        address spender,
        uint256 allowance,
        uint256 needed
    );

    error ERC20InvalidApprove(address approver, address spender);

    error ERC20SlippageExceed(uint256 tax, uint256 maxTax);

    error ERC20InsufficientTaxOffer(uint256 tax, uint256 taxOffer);

    error ERC2612ExpiredSignature(uint256 deadline);

    error ERC2612InvalidSigner(address signer, address owner);
```


# Initial Liquidity Offering (ILO)

The distribution of Owy ensures a fair and decentralized allocation, with the majority available to the public through Public Seed Funding (PSF).

{% hint style="success" %}
Highly Recommended to Read More on [Public Seed Funding (PSF).](broken://pages/rPIYNpqxSSARJcz4Sfi7)
{% endhint %}

### Allocation

* At launch, Owy will distribute its maximum possible supply of 69 million. The token contract does not include a mint function, ensuring that no additional OWY can be produced.
* 90% of the maximum supply, equivalent to 62,100,000 OWY, will be distributed to the public.
* The remaining 10% of OWY will be allocated to the project's core contributors in recognition of their development efforts and contributions, vested for 1,000 days.

***

### Limitation

As the project lacks initial investors and funds to provide liquidity for OWY, the entire public allocation will be dedicated to Public Seed Funding (PSF) with a limited-time purchase window.

***

### Public Launch

* Apply to 90% of the maximum supply.
* The capital raised during PSF, denominated in ETH, will be fully allocated for OWY liquidity provisioning. Shares purchased by PSF participants, represented by LP tokens, will be subject to a vesting period of 365 days (1 year). Note that there may be slight fluctuations in this vesting period due to the variability in block production on the Ethereum blockchain.

***

### Decentralize the Distribution

To decentralize this distribution, two rules will be applied:

#### 1. LP Token Composition

Each LP token consists of two components: ETH and OWY. ETH is contributed by the PSF participants, while OWY is from the distribution. Technically, participants only contribute 50% or one side of the liquidity. Therefore, they can claim only half of their LP tokens. The other half will be permanently locked on Uniswap, without any individual access or mutability. This means that for PSF participants to realize profits from their purchases, the price of OWY, denominated in ETH, must rise by 100% (or 2x) from the PSF price. The locked LPs ensure perpetual liquidity for public trades in a decentralized manner.

#### 2. Liquidity Dynamics

As a result of rule 1, only 45% of OWY is actually distributed to PSF participants initially. However, this is only true if there are no purchases of OWY during the entire PSF vesting period (1 year). If OWY is bought during this period, the ratio of OWY to ETH for each LP token will decrease. Consequently, each LP token will contain less OWY , reducing the allocation of OWY that PSF participants can claim. This benefits holder decentralization, as more OWY will be distributed to the public. If there is enough buying pressure to drive the price of OWY up by more than 100%, PSF participants will profit from their PSF purchases in two ways: 1) capital gains and 2) trading fees from liquidity provision.


# Rules and Conditions

The strategy to kickstart the Owy economy, a limited window of 69 days.

{% hint style="success" %}

#### Have you read [Distribution](/initial-liquidity-offering-ilo) yet? If not, have a good look.

{% endhint %}

## Participate

By pariticipating PSF, you are to set the initial price of OWY in ETH. The price of OWY  in the Public Seed Funding (PSF) will be set at $0.69/ OWY with the total amount of 90% from the maximum supply, or 62,100,000 tokens.

{% hint style="info" %}
**Participation criteria** are as follows:

1. ONE wallet can only purchase 0.01 OWY minimum and up to 6,900 OWY maximum.
2. ONE wallet  can purchase multiple times until it reaches the maximum amount or the event ends.
3. Once paid, funds cannot be returned.&#x20;
   {% endhint %}

{% hint style="info" %}
**Overview:**&#x20;

<mark style="color:orange;">**THE PSF OFFICIAL DATE IS NOT YET AVAILABLE, PLEASE WAIT FOR THE OFFICIAL ANNOUNCEMENT.**</mark>

By participating in the PSF event, you are to add your ETH to [Uniswap](https://uniswap.org) for liquidity provision with OWY tokens. You will get half of your LP tokens amount and another half will be locked permanently in the Uniswap contract. There is a vesting period of 1 year or 365 days for your LP tokens to be claimed, start counting when the event ends. You can claim it in every block or at the frequency of choice.&#x20;

Since you can claim only half of the LP tokens, for example 200 LP tokens instead of 400 LP tokens, OWY has to gain its value in ETH more than 100% or 2X from your entered price, in order to produce profits for you.&#x20;

However, if OWY is purchased heavily, you will be left with more ETH than OWY in each of your LP tokens, in exchange to capital gains you will realize.<br>

You will also earn all of the trading fees from LP and receive capital gains from OWY if its price in ETH exceeds your entered price.
{% endhint %}

***

## *PSF event ending*

#### if ONE of the two conditions below is met:

1. All allocations are taken.
2. The time limit of 69 days is exceeded.&#x20;

After the event is ended for 24hrs, the smart contract for LPing is unlocked, publicly callable by anyone. When it is called, all the rest of the community allocation (90%) combined with ETH from PSF are matched and LPed in [Uniswap](https://app.uniswap.org/swap), and the vesting period begins counting. OWY is then publicly and permissionlessly tradable. In case when PSF is finished by exceeding the time limit, all unsold OWY will be permanently burnt.

{% hint style="warning" %}
The amount of OWY that remains after the PSF event will be burnt forever!
{% endhint %}

***

## *Claim OWY from PFS*

* The PSF vesting period begins from the moment when the LPing contract is called.
* Since there is no cliff, all  PSF participant can claim their OWY as frequently as one block, the claimable amount is proportional to the total purchases, the number of blocks since the last claim (or the started vesting block if the person has never claimed), and the OWY current total supply at the claim.
* Only half the amount of OWY tokens for each participant will be claimable once it meets or exceeds the vesting period. This means that half of the amount will be returned to users for both in OWY and ETH when users make claims. The other half will always be locked on UniSwap.&#x20;


# Return on Investment


# Resources

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FnS3BxuXJx1t03VWZg9Gw%2Fyatchyyy.jpeg?alt=media&amp;token=60f2a650-b8a3-433f-8c9c-4610901e0fd4" alt=""><figcaption><p>I'm on a yacht.</p></figcaption></figure>


# Basic Value Flow

You will notice that the "value" (qualitative) of the asset is prioritized, not the "amount" (quantitative).

To begin with, we can categorize people into 3 financial statuses; upper class, middle class, and lower class, as you can see in the diagram below.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2F38zpT3SYaFHVp7WgowTG%2FUP.png?alt=media&amp;token=1e6944bc-df2c-4e18-842c-e68c889a5894" alt=""><figcaption><p>Traditional Economics</p></figcaption></figure>

If we are talking about equality in their financial, you will notice that the lower class one (Mr.C) should gain more amount of assets in order to catch up with Mr.B, and hopefully Mr.A in term of wealth. Another case is for Mr.A and Mr.B to get rid of their asset to have as less as Mr.C, but who would do it in reality?&#x20;

The desire to gain their financial status to meet or exceed others, we call this <mark style="color:orange;">"desire state"</mark>.

In traditional economics where inflation occurs, Mr.C must acquire more amount of the asset. In the case of a fair game where all of the newly minted assets are distributed proportionally to everyone, there would be no problems in fighting for the status.&#x20;

However, the denominated currencies/ products/ services are affected. Consider the cost of a slice of pizza in USD. In the past, a slice of pizza cost less than 1 USD, but due to years of inflation, finding a slice for 1 USD is now rare in the US and many developed countries. Consequently, people need to acquire more money to maintain the same standard of living, meaning Mr.C will face that acquiring money to is getting more difficult.

The scenario implies that <mark style="color:orange;">people in traditional economics are</mark> <mark style="color:orange;"></mark>*<mark style="color:orange;">**chasing dividends**</mark>* or gaining in amount to maintain their lives. Whenever no more dividends flowing into your pocket (or less than the inflation rate), you begin losing.

***

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2F8Cj6RAdd4nflbaXAXsup%2FUP%20(2).png?alt=media&amp;token=196c121d-1ff2-4dbb-98f7-7643d268f739" alt=""><figcaption><p>Beginning of OWY's Inverse Economics</p></figcaption></figure>

However, when the same scenario is applied to OWY's Inverse Economics, things get significantly changed. Thanks to [Supply Contraction](/tokenomics/supply-contraction), which is the idea of promoting value in all hands by focusing on a single activity "saving". This means that the longer OWY you hold, the more value it increases and the more mature/liquid your OWY becomes. Furthermore, <mark style="color:orange;">the desire state in OWY's Inverse Economics is all about</mark> <mark style="color:orange;"></mark>*<mark style="color:orange;">**chasing value**</mark>* or capital gains, instead of dividends or amounts.&#x20;

In short,  when you have any amount of OWY in your wallet, you are not actually holding the amount of tokens, but the shares of tokens computed from the total supply, which is reduced over time through spending taxation. It means that even if you do not acquire more OWY, your current amount will work for you by increasing its value.&#x20;

Taking the same scenario, Mr.C now has the hope and possibility to catch up with Mr.B and Mr.A by just saving. This economics gives saving a great choice of investment again.&#x20;

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FcUqMb7L47l5TkG1SMSWC%2FUP%20(3).png?alt=media&amp;token=7999923a-d88b-4a03-8d58-b642671670a8" alt=""><figcaption><p>Changes in OWY's Inverse Economics</p></figcaption></figure>

From the given scenario, it can be seen that the longer you hold, the larger of your pie or share will be (Mr.C %Share changes from 0.5% to 5%).&#x20;

> *<mark style="color:orange;">This economy creates a competition towards long-term management strategies among holders. There is an opportunity to spend, and there is also an opportunity to save. One's opportunity costs are one's benefits gained, and vice versa.</mark>*&#x20;


# OWY vs BTC vs USD

These are comparisons between OWY, BTC, and USD that help everyone understand the differences in their monetary circulation systems.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FGQmd2FI7gfP2k7ztxNYC%2FBTCvsUSD.png?alt=media&amp;token=ea92227d-a9e8-4e90-a7bf-cd419659e22d" alt=""><figcaption><p>BTC and USD economy</p></figcaption></figure>

* On the left side of this diagram, it illustrates the fixed nature of BTC's total supply, which remains capped at 21 million. The release of BTC into the market is determined by miners, who receive BTC as rewards for mining. These miners can choose to either hold their newly mined BTC or sell it in the market to cover mining costs or take profits. This suggests that BTC operates with an inflationary mechanism that has a defined upper limit, rather than being deflationary.
* On the right side, the diagram depicts the continually increasing supply of USD, which is determined solely by the Federal Reserve (FED). This indicates that the value of USD will decrease over time, as the exact amount to be printed and released into the market is unknown. It is also unclear how much of it will be circulated or held in reserve, and who will benefit from this new currency.

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FoLi2Ht7JkMnifJXEmLfU%2F11.png?alt=media&amp;token=8d2e4214-d148-4acf-b084-05d378214141" alt=""><figcaption><p>OWY economy</p></figcaption></figure>

As the total supply of OWY starts at its maximum with no mint function, the supply of OWY will decrease over time, making it deflationary. This ensures that no additional OWY will be added to the ecosystem after launch.

Over time, the quantity of OWY in circulation will decrease due to three key factors:

1. <mark style="color:orange;">**Supply contraction**</mark>**:** A fair deduction mechanism is in place to squeeze economic value, reducing the supply.
2. <mark style="color:orange;">**No supply injection**</mark>: There are no additional mints of OWY, meaning no new tokens will be injected into the ecosystem.
3. <mark style="color:orange;">**Primary source**</mark>: The majority of OWY is initially held in liquidity pools (LPs) on Uniswap V2, making it the primary source for the public to acquire OWY. By utilizing the on-chain DEX, every trade will continuously activate the Supply Contraction Mechanism from the moment of launch.

{% hint style="info" %}
Additionally, it is challenging for other exchanges to become the primary source or market for OWY, as Uniswap V2 is currently the primary market where the majority of OWY tokens can be purchased, and it supports all price ranges. However, while this scenario is likely, it is not impossible for other exchanges to emerge as major markets. As the first exchange, Uniswap V2 offers buyers the benefit of minimal tax deductions due to the time factor in [Supply Contraction](/tokenomics/supply-contraction). However, in the future, other exchanges may provide advantages such as greater liquidity and better quotes, potentially offering the best prices.
{% endhint %}

In Owy's economic model, saving with strong belief, knowledge, and patience can shift one's fortune. *Such hope and possibilities only exist in a deflationary economy.*


# Official Links

As more channels of Owy are created, the page will be updated.

## Social

* Twitter/X : <https://x.com/owy_eth>
* Discord : <https://discord.com/invite/9PNT8h5VsF>
* Telegram : <https://t.me/owydiscussion>
* Telegram(Post Only): <https://t.me/owyofficial>
* Youtube: <https://www.youtube.com/channel/UC3vzghb5CutpGy8fqcJHn_A>
* Tiktok: <https://www.tiktok.com/@owy_eth>
* Github: <https://github.com/Owy-wtf>

## Deprecated sites

* Archived docs: <https://owy.gitbook.io/archive.docs>


# Glossary


# FAQ

&#x20;


# Roadmap

Notice that roadmap subjects to change depending on community traffic and public demands, to ensure successful launch.

{% hint style="info" %}
Please note that the roadmap is subject to change based on community engagement and public demand. These adjustments are made to ensure a successful launch. We remain committed to flexibility and responsiveness in our planning process.
{% endhint %}

<figure><img src="https://3979644856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCXASImXnY5wxWmGXML8x%2Fuploads%2FHesOrXBIue7hgNJdGThH%2FRoadmap.jpeg?alt=media&amp;token=8df722bd-47a5-4880-982b-141180da11f4" alt=""><figcaption><p>2024 Owy Roadmap</p></figcaption></figure>


# Whitepaper

The paper is in a PDF format below.

{% file src="/files/h1gz9UFetLz4FZIkZcYc" %}