Dexhune : Marker Foundry
Non-Constitutional
Abstract In the following proposal I discuss a new form of spot orderbook exchange where token creators can freely list their assets and benefit from not needing to provide fixed liquidity pools, instead using the token's volume; connecting buyers and sellers at a price supplied by an oracle or based on the token's demand. The exchange can also be used to create stablecoins of any kind without the need for collateral.
Motivation It is my belief that an exchange like this would greatly reduce the barrier to entry for creating stablecoins and more so speculative tokens, this would overall bring more developers and users to the network and decentralized finance as a whole.
Rationale This app is built / is being built with considerations of decentralization and permissionlessness in mind, from the contracts to the frontend and even the domain name. I believe first and foremost in the ethos of decentralization, and I believe all efforts to enhance or improve decentralized systems; making them more accessible to the average developer world-over is in line with the motives of this foundation.
Specifications
The Ethereum Virtual machine : The first iteration of this exchange (and all future iterations) are built for the EVM using solidity programming language. It is compatible with all chains that make use of the Ethereum virtual machine.
Dexhune-C : Dexhune-C is a sort of proof of concept built on Avalanche C-Chain, and can be accessed at ; https://dexhune.avax.sh, or at the backup link ; https://pengprotocol-ihahxz.dappling.eth.limo/ Dexhune-C uses (2) main pricing schemes; the first is relative pricing via a "base oracle" and the second is pricing via a pairing address which holds DXH and [TOKEN] to determine the price of the token, therefore whoever controls the address can add or subtract tokens to maintain a target price. Whereas the base price is acquired from an NFT based oracle where any 1/1000 NFT items can propose price updates - vote on them and finalize the price update. Each order made within the exchange contract is settled at a price determined by the respective pricing scheme, this allows the creation of price pegged assets that can only depeg if a respective oracle fails. When orders are made; the principal from said orders is stored in the exchange contract under 1/2 "order balances", these are for AVAX and [TOKEN] respectively, once the exchange is invoked to settle orders for a particular token, all stored principal from orders is collectively used to settle them, thereby sending AVAX to addresses who have AVAX pending and vice versa. Every token has its own respective balance and tokens can be "donated" into these balances to permanently add liquidity.
Dexhune-P : after continued tests and insights we made some considerations for a refined version of the exchange called; "Dexhune Marker Foundry". If accepted, this new version would be deployed on Arbitrum and would have the following changes ;
Gas optimization The original contract was not optimized for gas and suffered twice the normal fees of main-stay DEXs on Avalanche, we aim to break the single large contract down into (9) smaller ones which would abstract the system and lessen the gas fees.
Infinite Token Slots The original contract stored listed tokens directly in storage and has a limited number of 1,000,000 token slots which require a listing fee to use, this is because; the more data a smart contract stores the more expensive it is to interact with. Whereas the new contract will have infinite "listing contracts" which would require no storage.
Pricing Schemes The original contract only had (2) pricing schemes as discussed, but the improved contract will have (3), these are; relative price based on a base stablecoin, price from an own oracle and price from a pairing address. This does away with the "base oracle" and allows anyone to specify their own oracle address. The 'pairing addresses' will be optimized to create an experience similar to listing a token on a CFAMM like Uniswap, where the price automatically goes up or down based on demand.
Listing protection + fee structure In the original contract there is a fee structure for listing tokens that begins at 1000 DXH and increases by 0.5% till it reaches 1,000,000 DXH, the intent was to dissuade individuals from listing someone else's token. However, the new implementation will charge a fee in the token being listed, under the assumption that only the token's creator or maintainer should have 1% of the token's supply. This fee is sent to an external contract called 'MarkerDAO' which is an NFT DAO where holders decide on "distributions" of collected fees.
Liquidity Pools In the original contract there was always the fringe possibility of some orders not being fully settled, to address this we implemented "order taking", which allows any address to independently take orders, an incentive to this is "taker rewards" which are paid from a token's reward balance. However, in the improved implementation order taking will be replaced by liquidity pools, which are optionally enabled when a token is created and charge fees on each transaction. These liquidity pools will be pairings of [STABLE] and [TOKEN], the exchange's base token will be called "STABLE" and will be used in all trades. The exchange can be invoked to settle orders from the liquidity balance rather than order balances.
Lastly, our github can be found at; https://github.com/ElixExo/PengProtocol/tree/Dexhune
Steps to Implement Our team comprises of myself, Elix Exo, legal name; "Ibrahim Sherif" and Prince Owen, legal name; "Zion Anthony". I am the protocol designer and Owen is the engineer. What we require is financial support to go about implementing, and marketing this system, if approved; an NFT contract will be deployed and will be the primary funding source. Once the new version is implemented on Arbitrum One along with a number of token concepts we will provide liquidity to said tokens and begin marketing them. As stated previously NFT holders will be in control of MarkerDAO and its fee collection.
Timeline Once the proposal is approved and funded we will begin implementing Dexhune-P which will take between 3 to 9 weeks depending on what hurdles we encounter.
Once implemented we will begin working on token concepts, we have (3) token concepts planned;
Link Dollars (DOHL) A CFAMM based token which will use Uniswap LPs and Chainlink oracles to maintain a fixed price at $1 per DOHL without collateralization or arbitrage, this would work by implementing changes to the ERC-20 standard that would allow the token contract to add or subtract units of the token (DOHL) to or from the liquidity pool based on preset parameters and data supplied by a Chainlink oracle. DOHL would be used as the base token or [STABLE].
Hypermoon (HYMN) A token listed with oracle pricing scheme with a starting price of "1" but the oracle can be invoked to increase the price by 3% for a fee of 1 HYMN, the fee increases by 3% with each price increase and goes to the token's order balances (donated liquidity).
Gold Link (LAU) A token listed with oracle price scheme but the oracle is a Chainlink parser for XAU / USD. The oracle rewards users for invoking a price update.
Each token will take approximately 2 weeks to complete. After which we can focus more on pushing adoption of the exchange as a whole by encouraging developers to list their tokens on the exchange.
Note; the word "Parity" is often if not entirely used in place of "pairing" in the original documents and implementation, this is based on the idea of the token achieving "parity" with its target asset.
Overall Cost This proposal should cost 50,000 ARB in total, however we expect to acquire this in a somewhat unconventional fashion;
The NFT contract will have 1000 items, each with an initial mint cost of 5 ARB, once fully minted this comes out at 5000 ARB, which will cover the first phase of development, after which we will collect royalty fees on the collection at 10% per trade, once the project is sufficiently funded the royalties will be turned off and the contract renounced.
However, we are open to suggestions for other fund raising schemes. With that the proposal is finished. Thank you for reading, any feedback is appreciated.
My contact lines; Telegram - genericmage Twitter - genericmage1127 Email - [email protected]
Dexhune : Marker Foundry
Non-Constitutional
Abstract In the following proposal I discuss a new form of spot orderbook exchange where token creators can freely list their assets and benefit from not needing to provide fixed liquidity pools, instead using the token's volume; connecting buyers and sellers at a price supplied by an oracle or based on the token's demand. The exchange can also be used to create stablecoins of any kind without the need for collateral.
Motivation It is my belief that an exchange like this would greatly reduce the barrier to entry for creating stablecoins and more so speculative tokens, this would overall bring more developers and users to the network and decentralized finance as a whole.
Rationale This app is built / is being built with considerations of decentralization and permissionlessness in mind, from the contracts to the frontend and even the domain name. I believe first and foremost in the ethos of decentralization, and I believe all efforts to enhance or improve decentralized systems; making them more accessible to the average developer world-over is in line with the motives of this foundation.
Specifications
The Ethereum Virtual machine : The first iteration of this exchange (and all future iterations) are built for the EVM using solidity programming language. It is compatible with all chains that make use of the Ethereum virtual machine.
Dexhune-C : Dexhune-C is a sort of proof of concept built on Avalanche C-Chain, and can be accessed at ; https://dexhune.avax.sh, or at the backup link ; https://pengprotocol-ihahxz.dappling.eth.limo/ Dexhune-C uses (2) main pricing schemes; the first is relative pricing via a "base oracle" and the second is pricing via a pairing address which holds DXH and [TOKEN] to determine the price of the token, therefore whoever controls the address can add or subtract tokens to maintain a target price. Whereas the base price is acquired from an NFT based oracle where any 1/1000 NFT items can propose price updates - vote on them and finalize the price update. Each order made within the exchange contract is settled at a price determined by the respective pricing scheme, this allows the creation of price pegged assets that can only depeg if a respective oracle fails. When orders are made; the principal from said orders is stored in the exchange contract under 1/2 "order balances", these are for AVAX and [TOKEN] respectively, once the exchange is invoked to settle orders for a particular token, all stored principal from orders is collectively used to settle them, thereby sending AVAX to addresses who have AVAX pending and vice versa. Every token has its own respective balance and tokens can be "donated" into these balances to permanently add liquidity.
Dexhune-P : after continued tests and insights we made some considerations for a refined version of the exchange called; "Dexhune Marker Foundry". If accepted, this new version would be deployed on Arbitrum and would have the following changes ;
Gas optimization The original contract was not optimized for gas and suffered twice the normal fees of main-stay DEXs on Avalanche, we aim to break the single large contract down into (9) smaller ones which would abstract the system and lessen the gas fees.
Infinite Token Slots The original contract stored listed tokens directly in storage and has a limited number of 1,000,000 token slots which require a listing fee to use, this is because; the more data a smart contract stores the more expensive it is to interact with. Whereas the new contract will have infinite "listing contracts" which would require no storage.
Pricing Schemes The original contract only had (2) pricing schemes as discussed, but the improved contract will have (3), these are; relative price based on a base stablecoin, price from an own oracle and price from a pairing address. This does away with the "base oracle" and allows anyone to specify their own oracle address. The 'pairing addresses' will be optimized to create an experience similar to listing a token on a CFAMM like Uniswap, where the price automatically goes up or down based on demand.
Listing protection + fee structure In the original contract there is a fee structure for listing tokens that begins at 1000 DXH and increases by 0.5% till it reaches 1,000,000 DXH, the intent was to dissuade individuals from listing someone else's token. However, the new implementation will charge a fee in the token being listed, under the assumption that only the token's creator or maintainer should have 1% of the token's supply. This fee is sent to an external contract called 'MarkerDAO' which is an NFT DAO where holders decide on "distributions" of collected fees.
Liquidity Pools In the original contract there was always the fringe possibility of some orders not being fully settled, to address this we implemented "order taking", which allows any address to independently take orders, an incentive to this is "taker rewards" which are paid from a token's reward balance. However, in the improved implementation order taking will be replaced by liquidity pools, which are optionally enabled when a token is created and charge fees on each transaction. These liquidity pools will be pairings of [STABLE] and [TOKEN], the exchange's base token will be called "STABLE" and will be used in all trades. The exchange can be invoked to settle orders from the liquidity balance rather than order balances.
Lastly, our github can be found at; https://github.com/ElixExo/PengProtocol/tree/Dexhune
Steps to Implement Our team comprises of myself, Elix Exo, legal name; "Ibrahim Sherif" and Prince Owen, legal name; "Zion Anthony". I am the protocol designer and Owen is the engineer. What we require is financial support to go about implementing, and marketing this system, if approved; an NFT contract will be deployed and will be the primary funding source. Once the new version is implemented on Arbitrum One along with a number of token concepts we will provide liquidity to said tokens and begin marketing them. As stated previously NFT holders will be in control of MarkerDAO and its fee collection.
Timeline Once the proposal is approved and funded we will begin implementing Dexhune-P which will take between 3 to 9 weeks depending on what hurdles we encounter.
Once implemented we will begin working on token concepts, we have (3) token concepts planned;
Link Dollars (DOHL) A CFAMM based token which will use Uniswap LPs and Chainlink oracles to maintain a fixed price at $1 per DOHL without collateralization or arbitrage, this would work by implementing changes to the ERC-20 standard that would allow the token contract to add or subtract units of the token (DOHL) to or from the liquidity pool based on preset parameters and data supplied by a Chainlink oracle. DOHL would be used as the base token or [STABLE].
Hypermoon (HYMN) A token listed with oracle pricing scheme with a starting price of "1" but the oracle can be invoked to increase the price by 3% for a fee of 1 HYMN, the fee increases by 3% with each price increase and goes to the token's order balances (donated liquidity).
Gold Link (LAU) A token listed with oracle price scheme but the oracle is a Chainlink parser for XAU / USD. The oracle rewards users for invoking a price update.
Each token will take approximately 2 weeks to complete. After which we can focus more on pushing adoption of the exchange as a whole by encouraging developers to list their tokens on the exchange.
Note; the word "Parity" is often if not entirely used in place of "pairing" in the original documents and implementation, this is based on the idea of the token achieving "parity" with its target asset.
Overall Cost This proposal should cost 50,000 ARB in total, however we expect to acquire this in a somewhat unconventional fashion;
The NFT contract will have 1000 items, each with an initial mint cost of 5 ARB, once fully minted this comes out at 5000 ARB, which will cover the first phase of development, after which we will collect royalty fees on the collection at 10% per trade, once the project is sufficiently funded the royalties will be turned off and the contract renounced.
However, we are open to suggestions for other fund raising schemes. With that the proposal is finished. Thank you for reading, any feedback is appreciated.
My contact lines; Telegram - genericmage Twitter - genericmage1127 Email - [email protected]
Hi, thanks for taking time to read my documents, I appreciate it and value your time.
1 ) There are specialized order balances in the exchange, these store ETH and [TOKEN], each listed token has such individual balances.
Hi, thanks for taking time to read my documents, I appreciate it and value your time.
1 ) There are specialized order balances in the exchange, these store ETH and [TOKEN], each listed token has such individual balances.
If User-A creates an order to buy 1ETH worth of a token; this action deducts ETH from User-A's address and sends it to the exchange, there-by updating the ETH balance of the token User-A wanted to buy, thus the order balance is 1ETH.
For User-A's order to be settled there must be [TOKEN] in the order balance, so if User-A was buying 500 units of the token and 400 exist in the order balance; the exchange can be invoked to settle User-A 400 [TOKEN] with 100 pending.
These balances can also be "donated" to.
The function to create an order also more importantly writes the individual order details on an order slot, this is necessary for everything else to happen. Orders can also be cancelled if the user wishes to.
Likewise, if User-B wants to sell his [TOKEN], his units are sent into the exchange contract and are recorded under order balances and the process is about the same as buying.
Note that the exchange can settle up to 100 orders at a time.
There's also "order taking", which allows addresses to "take" orders rather than automatically settling them using Liquidity in order balances. An incentive to this is "reward balances" which send a small amount of [TOKEN] to the order taker each time they take an order, how much is sent and at what threshold are determined by the token's listing party.
2 & 3 ) Uniswap uses fixed Liquidity pools, if I create a pool with 10 ETH and 1,000,000 [TOKEN] this becomes a kind of limit on how much can be bought or sold. Due to slippage it would not be possible to outright buy more than 10% of the token. This is better expressed in dollar value, if the pool is worth $40000 it means orders worth more than $4000 will suffer higher slippage, the larger the order is relative to the Liquidity the harder it will be to fill without massive loss.
This is a massive limitation for tokens starting early on, in that they have to find a way to raise Liquidity, whereas with my system the volume is the Liquidity.
Which brings me to the second part of this answer; stablecoins, collateralized stablecoins are regular tokens in the sense that they have speculative value, buying increases their price and selling reduces it. If you have a stablecoin with <$100,000,000 worth of Uniswap or other CFAMM Liquidity, then a purchase or sale of $1,000,000 will swing the price by 1%.
Collateralized stablecoins use a system of issuance and redemption, arbitrageurs buy from the open market when the price is too low then redeem it at the issuer at profit for collateral such as ETH. And when the price is too high on the open market they issue new tokens and sell onto the market.
Their profit comes from the issuer, who covers this cost through Liquidity fees or other associated issuance fees. However, if the price swings are too high then the issuer loses money regardless and over time their collateral is slowly drained.
Thus with the collateralization model only very large stablecoins (>$100,000,000) can withstand such pressure.
Our system settles orders based on oracle price, this is a fixed number the exchange acquires from a source setup by the listing party. So you could setup a system that gets the price of USD or XAU or BTC from Chainlink and the exchange would use that price as the definitive price for your token.
But you can also setup your token to use a speculative price just like Uniswap or other CFAMMs.
Hi, thanks for taking time to read my documents, I appreciate it and value your time.
1 ) There are specialized order balances in the exchange, these store ETH and [TOKEN], each listed token has such individual balances.
Hi, thanks for taking time to read my documents, I appreciate it and value your time.
1 ) There are specialized order balances in the exchange, these store ETH and [TOKEN], each listed token has such individual balances.
If User-A creates an order to buy 1ETH worth of a token; this action deducts ETH from User-A's address and sends it to the exchange, there-by updating the ETH balance of the token User-A wanted to buy, thus the order balance is 1ETH.
For User-A's order to be settled there must be [TOKEN] in the order balance, so if User-A was buying 500 units of the token and 400 exist in the order balance; the exchange can be invoked to settle User-A 400 [TOKEN] with 100 pending.
These balances can also be "donated" to.
The function to create an order also more importantly writes the individual order details on an order slot, this is necessary for everything else to happen. Orders can also be cancelled if the user wishes to.
Likewise, if User-B wants to sell his [TOKEN], his units are sent into the exchange contract and are recorded under order balances and the process is about the same as buying.
Note that the exchange can settle up to 100 orders at a time.
There's also "order taking", which allows addresses to "take" orders rather than automatically settling them using Liquidity in order balances. An incentive to this is "reward balances" which send a small amount of [TOKEN] to the order taker each time they take an order, how much is sent and at what threshold are determined by the token's listing party.
2 & 3 ) Uniswap uses fixed Liquidity pools, if I create a pool with 10 ETH and 1,000,000 [TOKEN] this becomes a kind of limit on how much can be bought or sold. Due to slippage it would not be possible to outright buy more than 10% of the token. This is better expressed in dollar value, if the pool is worth $40000 it means orders worth more than $4000 will suffer higher slippage, the larger the order is relative to the Liquidity the harder it will be to fill without massive loss.
This is a massive limitation for tokens starting early on, in that they have to find a way to raise Liquidity, whereas with my system the volume is the Liquidity.
Which brings me to the second part of this answer; stablecoins, collateralized stablecoins are regular tokens in the sense that they have speculative value, buying increases their price and selling reduces it. If you have a stablecoin with <$100,000,000 worth of Uniswap or other CFAMM Liquidity, then a purchase or sale of $1,000,000 will swing the price by 1%.
Collateralized stablecoins use a system of issuance and redemption, arbitrageurs buy from the open market when the price is too low then redeem it at the issuer at profit for collateral such as ETH. And when the price is too high on the open market they issue new tokens and sell onto the market.
Their profit comes from the issuer, who covers this cost through Liquidity fees or other associated issuance fees. However, if the price swings are too high then the issuer loses money regardless and over time their collateral is slowly drained.
Thus with the collateralization model only very large stablecoins (>$100,000,000) can withstand such pressure.
Our system settles orders based on oracle price, this is a fixed number the exchange acquires from a source setup by the listing party. So you could setup a system that gets the price of USD or XAU or BTC from Chainlink and the exchange would use that price as the definitive price for your token.
But you can also setup your token to use a speculative price just like Uniswap or other CFAMMs.
Hello, Can you explain briefly, I didn’t quite understand how it works, even after reading the whitepaper.
Hello, Can you explain briefly, I didn’t quite understand how it works, even after reading the whitepaper.
