What is dForce Network (DF) | What is dForce Network token | What is DF token

What is dForce?

DF is the platform utility token of the dForce network, an integrated and interoperable DeFi platform. It will be used for transaction services, community governance, system stabilizer, incentivization, and validator deposits.

How does dForce work?

dForce advocates for building an integrated and interoperable open finance and monetary protocol matrix, including asset protocols (USDx, GOLDx, dToken), liquidity protocol (dForce Trade), and lending protocol (soon-to-be-launched dForce Lending).

dForce Token (DF) is the utility token that facilitates governance, risk buffers and interest alignment across the dForce Network.

Our team includes both crypto veterans and professionals from Goldman Sachs, Standard Chartered Bank, Hony Capital. dForce is backed by investors including CMBI (China Merchants Bank International), Multicoin Capital and Huobi Capital (the investment arm of Huobi Group).

Key Protocols:

  • USDx, the first decentralized and fiat-back stablecoin implementing systematic interest. USDx holders can earn interest by simply depositing USDx into the USR contract and can withdraw at any time.
  • GOLDx, a gold token 100% backed by physical gold (through constituent gold token PAXG) and is denominated in gram. GOLDx is featured by 0 transaction fee and is 100% compatible with all DeFi protocols, making it easy for DeFi integrations.
  • Yield Market (dToken), the most accessible yield aggregator to farm the most attractive risk-adjusted yield across DeFi protocols (the highest underlying yield in the market at present). Instant withdrawal supported.
  • dForce Trade, as an upgrade of dForce Swap, dForce Trade will scan for the best possible price and aggregate proper liquidity across multiple platforms to facilitate large-volume trades.
  • dForce Lending (coming soon), fully open and permission-less lending platform.

dForce Trade, the First Multi-Chain DEX Aggregator Supporting Binance Smart Chain

Image for post

Following the launch of dForce Yield Markets (dToken), we are thrilled to announce the launch of dForce Trade on Binance Smart Chain, the first multi-chain DEX aggregator supporting BSC. Currently, dForce Trade enables trading with access to liquidity from DEXs on both Ethereum and BSC, facilitating instant access for users to tap into DeFi on different blockchains with ease.

About dForce Trade

dForce Trade is a DEX aggregator launched by dForce. dForce Trade scans for the best possible price and aggregate proper liquidity across multiple platforms to facilitate large-volume trades. Multiple DEXes have been integrated with dForce Trade to support instant swap of tokens in a decentralized manner. dForce Trade was first deployed on Ethereum, with 7 DEXs (including Uniswap, Curve, Balancer, Unisave, etc) integrated and over 95% coverage of all ERC20 token swap.

With dForce Trade, users of Binance Smart Chain can trade tokens of your choice with minimal slippage. Currently dForce Trade covers most of DEX token pairs on Binance Smart Chain.

Serves as One Entry to Access Liquidity across Multiple DEXes with the Best Possible Price

Trades will be split across exchanges, or through multi-routing (i.e. bridged through another token to fulfill the trade order), to minimize slippage and liquidity issues. By pooling fragmented liquidity across multiple platforms based on certain criteria, dForce Trade is able to digest large-volume trades at the best possible prices.

What is BSC?

Binance Smart Chain is a sovereign smart contract blockchain delivering programmability that’s compatible with the Ethereum Virtual Machine (EVM). Designed to run in parallel with Binance Chain, Binance Smart Chain retains the high performance of the native DEX blockchain and to support a friendly Smart Contract function at the same time.

Introduction of dForce’s Multicurrency Asset and Lending Protocol

Image for post

After 6 months of hard work and development, the launch of dForce’s Multicurrency Asset and Lending Protocol is just around the corner.

This is a novel lending protocol with built-in over-collateralized multicurrency stable debt protocol, which could extend to fund the fractional reserve of an algorithmic stablecoin.

In layman’s terms, the protocol is: General Lending + Multicurrency Collateralized Stable Debt + Fractional Reserve Algorithmic Stablecoin.

The guided launch will be phased out in several stages, with the first stage featuring a general lending protocol, followed by a multicurrency stable debt protocol built on top of the lending protocol and with its interest spread to fund the fractional reserve of an algorithmic stablecoin.

dForce Lending is at the final stage of the audit process. Upon satisfactory completion of the security audit, dForce Lending will be released via a soft launch — most likely sometime February or March.

The first phase will feature a general lending protocol. I’d like to give a high-level introduction about dForce Lending and will dedicate a separate post for a deep dive into our Multicurrency Stable Debt Protocol and its associated algorithmic design.

dForce Lending is a pool-based lending protocol, with its interest rate dynamically driven by market supply and demand. There are several innovative features that set dForce Lending apart from other lending protocols.

Key highlights of dForce Lending’s Offerings Enhanced Risk Model

· LTV Factor for Borrowed Assets

Loan-to-Value ratio (or the inverse Collateral Ratio) is one of the most critical risk parameters in all lending protocols. There is one issue however, that all existing lending protocols only take the collateral risk into consideration, and the risk associated with borrowed assets is often overlooked. For example, a borrower who pledges ETH as collateral is typically able to borrow either USDC or WBTC, both at an LTV of 85%. But we believe the latter transaction (borrowing WBTC) is riskier, as both ETH and BTC market risk will impact the loan position. Hence, we believe these two loans should have different LTV discount, so the risk of both collateral and borrowed assets are accounted for into the risk factor. Borrowers who borrow non-stablecoin will likely be subject to a discount on LTV.

· Borrow/Supply Cap

One of the greatest risks a lending protocol possess is the possibility of infinite minting of the underlying asset. For example, if a bug causes infinite minting of DAI (Maker’s stablecoin), this could be detrimental to all lending protocols that accepted DAI as collateral. Maker itself has a debt ceiling on its collateral assets, but most lending protocols lack such mechanism.

dForce introduces both borrow and supply cap in our core lending protocol, and each asset is regulated by its respective cap. Considering the diversity of assets we are going to support, we believe this feature will act as an additional layer of safety margins on our protocol

· Off-chain Risk Monitoring

Lending protocols are exposed to many layers of attack vectors, some of which don’t fall under the scope of security reviews. An example is risk on the assets level. Let’s consider any protocol that accepts Cover token as collateral for example. In the recent Cover protocol hack, the hacker used a bug in the staking contract to mint an infinite number of Cover tokens. In such circumstances, the consequences can be devastating, as the tokens could flood the lending protocol and drain all users’ funds from the protocols that accept Cover token as collateral. Our off-chain monitoring system was designed to monitor anomalies including detecting token minting events of the supported collaterals, price anomalies, and many others. Once an anomaly is detected, it will send transaction to pause certain function (or all functions) of the lending protocol to contain the situation.

Multicurrency Stable Debt Protocol

This is an innovative feature that allows users to mint stablecoin debt using the same collateral they provided to dForce Lending.

This was built as a separate multicurrency collateralized stablecoin protocol to run on top of our core lending protocol. The native multicurrency stablecoins will be standard ERC 20 tokens, fully compatible with existing DeFi infrastructure.

This function supports virtually any foreign exchange rate denominated debt. Several multicurrency tokens including xUSD, xEUR and xCNY have been added to the wish-list by our community, and decision will be subject to final on-chain governance.

Users will be able to mint stable debt tokens such as xUSD, xEUR, or xCNY, and treat them as DAI denominated in USD, EUR, and CNY to be used as over-collateralized stablecoin in different currency. The stable debt in different currencies will also help bridge crypto liquidity to foreign exchange exposures other than US Dollar and help building a truly global and multicurrency money market and lending protocol. More information about the Multi-currency Stable Debt Protocol will be provided in a separate post.

Public-Private Pool

The downside of pool-based lending protocols is that all assets are pooled into one single pool, and inherently assumes all assets are created equal (but they are not). Though we could use borrow/lending cap to limit the risk exposure of certain assets within a pool, it is difficult to apply such restrictions towards illiquid or alternative assets such as real-world assets like account receivables, residential rental property etc.

The vast majority of real-world assets have very distinguished risk and liquidity profiles compared to crypto assets. One can’t simply mingle all these assets into one single pool. Public-Private Pool is a customized pool catering to different classes of assets, and different type of users; i.e. a stand-alone pool for CeFi trading/lending desk, where the counterparties are mainly KYC’ed CeFi operators. In order to accommodate such demand, our lending protocol is able to supply customized pools with different liquidity and risk configuration.

Initial Public-Private Pool will likely include staking assets such as DOT, XTZ, ATOMs, etc, and may also feature a dedicated unsecured lending pool.

Flashloan Support

Flashloan is standard feature for lending protocol now and it will be enabled and we offer very attractive terms!

EIP 2612

We will implement EIP2612. This EIP saves the processes needed to approve authorizations, and it helps optimize gas fees.

On the upper layer feature level, we will support:

Fixed Rate and Fixed Term Borrowing (will be launched in later phase, community dev efforts)

Fixed rate/term borrowing, will be built on top of the core dForce Lending protocol, so the two protocols are decoupled and risks ringfenced. With a senior and junior tranche structure, loan maturity and debt seniority will be managed on the upper protocol level, not at the core lending level. The underlying lending pool (the General Pool) will supply senior capital along with junior tranche (provided by junior tranche investors) to form a Structured Pool on the upper level to capitalize risks from fixed/floating rates and loan maturity. The Structured Pool comprises of senior tranche funded by the General Pool and junior tranche funded by junior investors participating in the Structured Pool.

We are engaging community developers to implement the feature and if you are interested, please kindly approach us and join. A more detailed post about this feature will be released soon — below is a high-level flow of the mechanism.

Image for post

Credit Line Sharing

This feature allows you to share your credit line with any account, so they could borrow money with your credit lines. If we expand the use case, it could empower anyone with large collaterals and high borrowing limits to expand their offerings to other borrowers.

Unsecured Lending

Unsecured Lending feature leverages our core lending protocol by using a combination of structured financing and centralized P2P platforms. The General Pool provides senior tranche capital (low funding cost, high seniority), where junior investors risk buffer for absorbing risks associated with lending protocol. We have several solutions for tapping unsecured lending market, partnerships will be announced along the way. In a series of future posts, I will explain our plans for implementing unsecured lending.

I think the above pretty much covers our key offerings of our lending protocol, in the future posts, I will elaborate on the Multicurrency Stable Debt Protocol (to be integrated shortly after lending launch) and will also talk about the very experimental fractional reserve algorithmic stablecoin protocol to build on top of the stable debt protocol (however, this may, or may NOT come to final implementation).

dForce’s Risk Assessment Guideline

As our protocols now involve many assets (dToken supporting USDx, USDT, USDC, Dai, and the soon-to-launch dForce’s Lending and Multicurrency Stable Debt protocol supporting a variety of assets), it is important that we formalize our risk assessment framework, which will be used to onboard assets across our protocols.

Review Process

  1. Proposal stage: adding new assets or collateral supply into our protocol will be carried out through DF token voting process, i.e., snapshot page voting. The proposal shall include multiple factors including the type of asset proposed, whether or not it can be used as collateral, LTV, borrowed assets factor, supply and borrow cap, liquidation penalty.
  2. The assessment process is open and all community members can join the discussion on our forum. The internal initial evaluation will kickstart once the proposal is submitted. Team’s assessment on the smart contract will depend on the type of token proposed:
  • for standard ERC 20 tokens, we’ll have an internal vesting process and provide immediate clearance
  • for ERC 20 tokens that deviate from the standard ERC 20, our developer team would need to provide formal clearance before we move into next stage
  • for any non-ERC20 tokens, we’ll need at least one external party (either an auditor or a well-recognized community technical reviewers’ verification) to verify and audit the code.

3. It will then go through risk assessment score card checking.

4. The voting period will be 48-hour minimum, if passed, we will move into execution stage, and there is a minimum of 48 hours of grace period before the approved assets to be added into the protocol.

All new assets accepted into lending protocol needs to go through the above review and voting process. However, to ensure efficiency, the team will have discretion to determine the risk parameters for all assets which are approved into the lending protocols.

Risk Factor Coverage

We develop our assessment framework based on existing market’s best practices including the DeFi Score developed by Codefi team. This score includes the following factors: Smart Contract Risks (maturity, code security, code openness), Financial Risks (market and liquidity risks), Centralization & Intermediary Risk as well as some traditional financial market’s best practices.

Smart Contract Risks

Smart Contract Risk is the single most critical risk for a DeFi protocol. We evaluate the risk based on multiple factors, including but not limited to: maturity (how long the SC has been deployed), code complexity, audit history, open source or closed source.

Financial Risks

Similar to traditional finance, DeFi deals with mostly marketable crypto assets. Most lending protocols require over-collateralization, hence the financial risks are mainly about collateral’s market and liquidity risks.

· Market Risk

Many of the traditional financial market’s trading desks use Value at Risk model to assess the market risks of portfolios, given most of the crypto assets have pretty short trading period and lack of credible trading data to backs test the model. Therefore, we mainly use the trading volatility to gauge the market risks of collaterals.

· Liquidity Risk

Liquidity is how easily a crypto asset can be bought or sold in the market, and converted to cash, stablecoin or other crypto assets.

There are mainly two parameters measuring liquidity risk, one is the bid and ask spread and the other is liquidity depth.

Liquidity assessment refers to not only on-chain liquidity but also off-chain Centralized exchanges (CEX) liquidity. Particularly for BTC wrapper (i.e., WBTC), it is more important to take into account off-chain liquidity, given most of bitcoin’s liquidity are on CEXs.

We are looking at full market coverage when assessing liquidity risk of a collateral asset.

For lending protocols, in addition to market liquidity, it is also quite important to look at the utilization ratio, to gauge funding liquidity risks. An example of this is, during market chaos, DAI is often in huge demand for deleveraging and closing CDPs, hence drain out DAI’s liquidity and create substantial funding liquidity risk.

Counterparty Risks

Counterparty risk is mainly about centralization risk and intermediary risk. For example, is the token contract has special administrative right to mint assets, is it subject to time lock. It is an important risk to consider when lending money with DeFi protocols. Different DeFi protocols have different levels of centralization risk.

One of the biggest risk factors to centralization risk in DeFi protocols is the use of admin keys. Admin keys allow protocol developers to change different parameters of their smart contract systems like oracles, interest rates and potentially more.

The above risk assessment is to determine different risk aspect of asset and then, we could decide the risk parameters of each assets based on the score.

Risk parameters are the quantifiable triggers to set risk limits for lending protocols. Below is the list of risk parameters we evaluate :

Risk Parameters

Collateral support, Supply Cap, Borrow Cap, Loan-To-Value, Liquidation Penalty, Borrowed Asset Factor, Reserve Ratio.

Below is a brief explanation on the above risk parameters:

Collateral Support refers to whether an asset can be used as collateral in a lending protocol. This is the first line of defense against infinite mint risk, or risk of market price volatility. For example, let’s assume asset ABC is enabled as a collateral. If there is infinite mint of ABC, or in the event of ABC price collapsing, we will see a flood of ABC depositing into the lending protocol and borrowing out other assets. On the contrary, if a collateral is disabled to be used as collateral in the protocol, it will substantially limit its usability and liquidity. We have introduced a supply cap, which helps limit the collateral risk exposure while maintaining a certain level of flexibility.

Supply Cap. We are one of the two protocols who utilize this risk parameter. In simple terms, the Supply Cap limits the overall exposure of a specific asset. This is particularly important if the said asset is enabled as a collateral within the protocol. For example, say we enable ABC as collateral within our lending protocol, if we set a supply cap of 10m ABC, at a collateral ratio of 75%, this will significantly limit the infinite mint risk of ABC; i.e., even if someone prints 1bn ABC, they can only supply no more than 10m into the lending protocol.

Borrow Cap is used to mitigate against risk of concentration risk and liquidity risk of the lending protocol. An example of this can be illustrated with Compound. Compound protocol initially did not have a Borrow Cap when in the initial periods of the yield farming craze. In one instance, when arbitrageurs used recursive borrowing to borrow significant amounts of BAT, the borrowing went out of control. If there is significant price swing for BAT, it could put the protocol at risk of being insolvent.

Loan-to-Value (or collateral ratio), this is the most important parameter in a lending protocol. It is basically the leverage ratio of a specific asset, i.e., how much you can borrow against the collateral. The more liquid, stable, and mature an asset is, the higher the loan-to-value ratio.

Liquidation Penalty, is the discount factor to be applied in the event of liquidation of a loan position. During liquidation, a liquidator is able to buy the defaulted borrower’s collateral at discount to market price by repaying the defaulted loan on borrower’s behalf. The discount is the liquidation penalty. The more illiquid, less matured, and more volatile an asset is, there’s typically a higher liquidation penalty to incentivize liquidators to liquidate the defaulted loans in the event of default.

Borrowed Asset Factor. dForce is the only lending protocol that introduce this risk parameter. This is to further expand LTV ratio, to consider the liquidity and market risks of the borrowed assets. For example, a borrower who supplies ETH to borrow USDC, is less risky than a borrower who supplies ETH to borrow WBTC (due to price volatility of both ETH/WBTC and illiquidity of WBTC v.s USDC). In other lending protocols, both transactions are subject to the same LTV ratio by design. dForce will take the borrowed asset risk factor into account, which could result in a lower LTV for the same collateral with different borrowed asset. Please note that in the initial stages, we will be setting the Borrowed Asset Factor to 100% to simplify the risk module.

Reserve Factor is the amount of interest spread that can charged into the reserve pool. This is similar to interest rate spread charge to be reserved by future use.

The above summarizes our risk assessment process and risk parameter standards for each asset accepted into the dForce lending protocol. A more detailed analysis of each asset will be proposed in due course.

Looking for more information…

WebsiteExplorerExplorer 2Source CodeSocial ChannelSocial Channel 2Social Channel 3Message BoardMessage Board 2Coinmarketcap

Would you like to earn DF right now! ☞ CLICK HERE

Top exchanges for token-coin trading. Follow instructions and make unlimited money

BinanceBittrexPoloniexBitfinexHuobi

Thank for visiting and reading this article! I’m highly appreciate your actions! Please share if you liked it!

#blockchain #crypto #dforce network #df

What is GEEK

Buddha Community

What is dForce Network (DF) | What is dForce Network token | What is DF token

What is dForce Network (DF) | What is dForce Network token | What is DF token

What is dForce?

DF is the platform utility token of the dForce network, an integrated and interoperable DeFi platform. It will be used for transaction services, community governance, system stabilizer, incentivization, and validator deposits.

How does dForce work?

dForce advocates for building an integrated and interoperable open finance and monetary protocol matrix, including asset protocols (USDx, GOLDx, dToken), liquidity protocol (dForce Trade), and lending protocol (soon-to-be-launched dForce Lending).

dForce Token (DF) is the utility token that facilitates governance, risk buffers and interest alignment across the dForce Network.

Our team includes both crypto veterans and professionals from Goldman Sachs, Standard Chartered Bank, Hony Capital. dForce is backed by investors including CMBI (China Merchants Bank International), Multicoin Capital and Huobi Capital (the investment arm of Huobi Group).

Key Protocols:

  • USDx, the first decentralized and fiat-back stablecoin implementing systematic interest. USDx holders can earn interest by simply depositing USDx into the USR contract and can withdraw at any time.
  • GOLDx, a gold token 100% backed by physical gold (through constituent gold token PAXG) and is denominated in gram. GOLDx is featured by 0 transaction fee and is 100% compatible with all DeFi protocols, making it easy for DeFi integrations.
  • Yield Market (dToken), the most accessible yield aggregator to farm the most attractive risk-adjusted yield across DeFi protocols (the highest underlying yield in the market at present). Instant withdrawal supported.
  • dForce Trade, as an upgrade of dForce Swap, dForce Trade will scan for the best possible price and aggregate proper liquidity across multiple platforms to facilitate large-volume trades.
  • dForce Lending (coming soon), fully open and permission-less lending platform.

dForce Trade, the First Multi-Chain DEX Aggregator Supporting Binance Smart Chain

Image for post

Following the launch of dForce Yield Markets (dToken), we are thrilled to announce the launch of dForce Trade on Binance Smart Chain, the first multi-chain DEX aggregator supporting BSC. Currently, dForce Trade enables trading with access to liquidity from DEXs on both Ethereum and BSC, facilitating instant access for users to tap into DeFi on different blockchains with ease.

About dForce Trade

dForce Trade is a DEX aggregator launched by dForce. dForce Trade scans for the best possible price and aggregate proper liquidity across multiple platforms to facilitate large-volume trades. Multiple DEXes have been integrated with dForce Trade to support instant swap of tokens in a decentralized manner. dForce Trade was first deployed on Ethereum, with 7 DEXs (including Uniswap, Curve, Balancer, Unisave, etc) integrated and over 95% coverage of all ERC20 token swap.

With dForce Trade, users of Binance Smart Chain can trade tokens of your choice with minimal slippage. Currently dForce Trade covers most of DEX token pairs on Binance Smart Chain.

Serves as One Entry to Access Liquidity across Multiple DEXes with the Best Possible Price

Trades will be split across exchanges, or through multi-routing (i.e. bridged through another token to fulfill the trade order), to minimize slippage and liquidity issues. By pooling fragmented liquidity across multiple platforms based on certain criteria, dForce Trade is able to digest large-volume trades at the best possible prices.

What is BSC?

Binance Smart Chain is a sovereign smart contract blockchain delivering programmability that’s compatible with the Ethereum Virtual Machine (EVM). Designed to run in parallel with Binance Chain, Binance Smart Chain retains the high performance of the native DEX blockchain and to support a friendly Smart Contract function at the same time.

Introduction of dForce’s Multicurrency Asset and Lending Protocol

Image for post

After 6 months of hard work and development, the launch of dForce’s Multicurrency Asset and Lending Protocol is just around the corner.

This is a novel lending protocol with built-in over-collateralized multicurrency stable debt protocol, which could extend to fund the fractional reserve of an algorithmic stablecoin.

In layman’s terms, the protocol is: General Lending + Multicurrency Collateralized Stable Debt + Fractional Reserve Algorithmic Stablecoin.

The guided launch will be phased out in several stages, with the first stage featuring a general lending protocol, followed by a multicurrency stable debt protocol built on top of the lending protocol and with its interest spread to fund the fractional reserve of an algorithmic stablecoin.

dForce Lending is at the final stage of the audit process. Upon satisfactory completion of the security audit, dForce Lending will be released via a soft launch — most likely sometime February or March.

The first phase will feature a general lending protocol. I’d like to give a high-level introduction about dForce Lending and will dedicate a separate post for a deep dive into our Multicurrency Stable Debt Protocol and its associated algorithmic design.

dForce Lending is a pool-based lending protocol, with its interest rate dynamically driven by market supply and demand. There are several innovative features that set dForce Lending apart from other lending protocols.

Key highlights of dForce Lending’s Offerings Enhanced Risk Model

· LTV Factor for Borrowed Assets

Loan-to-Value ratio (or the inverse Collateral Ratio) is one of the most critical risk parameters in all lending protocols. There is one issue however, that all existing lending protocols only take the collateral risk into consideration, and the risk associated with borrowed assets is often overlooked. For example, a borrower who pledges ETH as collateral is typically able to borrow either USDC or WBTC, both at an LTV of 85%. But we believe the latter transaction (borrowing WBTC) is riskier, as both ETH and BTC market risk will impact the loan position. Hence, we believe these two loans should have different LTV discount, so the risk of both collateral and borrowed assets are accounted for into the risk factor. Borrowers who borrow non-stablecoin will likely be subject to a discount on LTV.

· Borrow/Supply Cap

One of the greatest risks a lending protocol possess is the possibility of infinite minting of the underlying asset. For example, if a bug causes infinite minting of DAI (Maker’s stablecoin), this could be detrimental to all lending protocols that accepted DAI as collateral. Maker itself has a debt ceiling on its collateral assets, but most lending protocols lack such mechanism.

dForce introduces both borrow and supply cap in our core lending protocol, and each asset is regulated by its respective cap. Considering the diversity of assets we are going to support, we believe this feature will act as an additional layer of safety margins on our protocol

· Off-chain Risk Monitoring

Lending protocols are exposed to many layers of attack vectors, some of which don’t fall under the scope of security reviews. An example is risk on the assets level. Let’s consider any protocol that accepts Cover token as collateral for example. In the recent Cover protocol hack, the hacker used a bug in the staking contract to mint an infinite number of Cover tokens. In such circumstances, the consequences can be devastating, as the tokens could flood the lending protocol and drain all users’ funds from the protocols that accept Cover token as collateral. Our off-chain monitoring system was designed to monitor anomalies including detecting token minting events of the supported collaterals, price anomalies, and many others. Once an anomaly is detected, it will send transaction to pause certain function (or all functions) of the lending protocol to contain the situation.

Multicurrency Stable Debt Protocol

This is an innovative feature that allows users to mint stablecoin debt using the same collateral they provided to dForce Lending.

This was built as a separate multicurrency collateralized stablecoin protocol to run on top of our core lending protocol. The native multicurrency stablecoins will be standard ERC 20 tokens, fully compatible with existing DeFi infrastructure.

This function supports virtually any foreign exchange rate denominated debt. Several multicurrency tokens including xUSD, xEUR and xCNY have been added to the wish-list by our community, and decision will be subject to final on-chain governance.

Users will be able to mint stable debt tokens such as xUSD, xEUR, or xCNY, and treat them as DAI denominated in USD, EUR, and CNY to be used as over-collateralized stablecoin in different currency. The stable debt in different currencies will also help bridge crypto liquidity to foreign exchange exposures other than US Dollar and help building a truly global and multicurrency money market and lending protocol. More information about the Multi-currency Stable Debt Protocol will be provided in a separate post.

Public-Private Pool

The downside of pool-based lending protocols is that all assets are pooled into one single pool, and inherently assumes all assets are created equal (but they are not). Though we could use borrow/lending cap to limit the risk exposure of certain assets within a pool, it is difficult to apply such restrictions towards illiquid or alternative assets such as real-world assets like account receivables, residential rental property etc.

The vast majority of real-world assets have very distinguished risk and liquidity profiles compared to crypto assets. One can’t simply mingle all these assets into one single pool. Public-Private Pool is a customized pool catering to different classes of assets, and different type of users; i.e. a stand-alone pool for CeFi trading/lending desk, where the counterparties are mainly KYC’ed CeFi operators. In order to accommodate such demand, our lending protocol is able to supply customized pools with different liquidity and risk configuration.

Initial Public-Private Pool will likely include staking assets such as DOT, XTZ, ATOMs, etc, and may also feature a dedicated unsecured lending pool.

Flashloan Support

Flashloan is standard feature for lending protocol now and it will be enabled and we offer very attractive terms!

EIP 2612

We will implement EIP2612. This EIP saves the processes needed to approve authorizations, and it helps optimize gas fees.

On the upper layer feature level, we will support:

Fixed Rate and Fixed Term Borrowing (will be launched in later phase, community dev efforts)

Fixed rate/term borrowing, will be built on top of the core dForce Lending protocol, so the two protocols are decoupled and risks ringfenced. With a senior and junior tranche structure, loan maturity and debt seniority will be managed on the upper protocol level, not at the core lending level. The underlying lending pool (the General Pool) will supply senior capital along with junior tranche (provided by junior tranche investors) to form a Structured Pool on the upper level to capitalize risks from fixed/floating rates and loan maturity. The Structured Pool comprises of senior tranche funded by the General Pool and junior tranche funded by junior investors participating in the Structured Pool.

We are engaging community developers to implement the feature and if you are interested, please kindly approach us and join. A more detailed post about this feature will be released soon — below is a high-level flow of the mechanism.

Image for post

Credit Line Sharing

This feature allows you to share your credit line with any account, so they could borrow money with your credit lines. If we expand the use case, it could empower anyone with large collaterals and high borrowing limits to expand their offerings to other borrowers.

Unsecured Lending

Unsecured Lending feature leverages our core lending protocol by using a combination of structured financing and centralized P2P platforms. The General Pool provides senior tranche capital (low funding cost, high seniority), where junior investors risk buffer for absorbing risks associated with lending protocol. We have several solutions for tapping unsecured lending market, partnerships will be announced along the way. In a series of future posts, I will explain our plans for implementing unsecured lending.

I think the above pretty much covers our key offerings of our lending protocol, in the future posts, I will elaborate on the Multicurrency Stable Debt Protocol (to be integrated shortly after lending launch) and will also talk about the very experimental fractional reserve algorithmic stablecoin protocol to build on top of the stable debt protocol (however, this may, or may NOT come to final implementation).

dForce’s Risk Assessment Guideline

As our protocols now involve many assets (dToken supporting USDx, USDT, USDC, Dai, and the soon-to-launch dForce’s Lending and Multicurrency Stable Debt protocol supporting a variety of assets), it is important that we formalize our risk assessment framework, which will be used to onboard assets across our protocols.

Review Process

  1. Proposal stage: adding new assets or collateral supply into our protocol will be carried out through DF token voting process, i.e., snapshot page voting. The proposal shall include multiple factors including the type of asset proposed, whether or not it can be used as collateral, LTV, borrowed assets factor, supply and borrow cap, liquidation penalty.
  2. The assessment process is open and all community members can join the discussion on our forum. The internal initial evaluation will kickstart once the proposal is submitted. Team’s assessment on the smart contract will depend on the type of token proposed:
  • for standard ERC 20 tokens, we’ll have an internal vesting process and provide immediate clearance
  • for ERC 20 tokens that deviate from the standard ERC 20, our developer team would need to provide formal clearance before we move into next stage
  • for any non-ERC20 tokens, we’ll need at least one external party (either an auditor or a well-recognized community technical reviewers’ verification) to verify and audit the code.

3. It will then go through risk assessment score card checking.

4. The voting period will be 48-hour minimum, if passed, we will move into execution stage, and there is a minimum of 48 hours of grace period before the approved assets to be added into the protocol.

All new assets accepted into lending protocol needs to go through the above review and voting process. However, to ensure efficiency, the team will have discretion to determine the risk parameters for all assets which are approved into the lending protocols.

Risk Factor Coverage

We develop our assessment framework based on existing market’s best practices including the DeFi Score developed by Codefi team. This score includes the following factors: Smart Contract Risks (maturity, code security, code openness), Financial Risks (market and liquidity risks), Centralization & Intermediary Risk as well as some traditional financial market’s best practices.

Smart Contract Risks

Smart Contract Risk is the single most critical risk for a DeFi protocol. We evaluate the risk based on multiple factors, including but not limited to: maturity (how long the SC has been deployed), code complexity, audit history, open source or closed source.

Financial Risks

Similar to traditional finance, DeFi deals with mostly marketable crypto assets. Most lending protocols require over-collateralization, hence the financial risks are mainly about collateral’s market and liquidity risks.

· Market Risk

Many of the traditional financial market’s trading desks use Value at Risk model to assess the market risks of portfolios, given most of the crypto assets have pretty short trading period and lack of credible trading data to backs test the model. Therefore, we mainly use the trading volatility to gauge the market risks of collaterals.

· Liquidity Risk

Liquidity is how easily a crypto asset can be bought or sold in the market, and converted to cash, stablecoin or other crypto assets.

There are mainly two parameters measuring liquidity risk, one is the bid and ask spread and the other is liquidity depth.

Liquidity assessment refers to not only on-chain liquidity but also off-chain Centralized exchanges (CEX) liquidity. Particularly for BTC wrapper (i.e., WBTC), it is more important to take into account off-chain liquidity, given most of bitcoin’s liquidity are on CEXs.

We are looking at full market coverage when assessing liquidity risk of a collateral asset.

For lending protocols, in addition to market liquidity, it is also quite important to look at the utilization ratio, to gauge funding liquidity risks. An example of this is, during market chaos, DAI is often in huge demand for deleveraging and closing CDPs, hence drain out DAI’s liquidity and create substantial funding liquidity risk.

Counterparty Risks

Counterparty risk is mainly about centralization risk and intermediary risk. For example, is the token contract has special administrative right to mint assets, is it subject to time lock. It is an important risk to consider when lending money with DeFi protocols. Different DeFi protocols have different levels of centralization risk.

One of the biggest risk factors to centralization risk in DeFi protocols is the use of admin keys. Admin keys allow protocol developers to change different parameters of their smart contract systems like oracles, interest rates and potentially more.

The above risk assessment is to determine different risk aspect of asset and then, we could decide the risk parameters of each assets based on the score.

Risk parameters are the quantifiable triggers to set risk limits for lending protocols. Below is the list of risk parameters we evaluate :

Risk Parameters

Collateral support, Supply Cap, Borrow Cap, Loan-To-Value, Liquidation Penalty, Borrowed Asset Factor, Reserve Ratio.

Below is a brief explanation on the above risk parameters:

Collateral Support refers to whether an asset can be used as collateral in a lending protocol. This is the first line of defense against infinite mint risk, or risk of market price volatility. For example, let’s assume asset ABC is enabled as a collateral. If there is infinite mint of ABC, or in the event of ABC price collapsing, we will see a flood of ABC depositing into the lending protocol and borrowing out other assets. On the contrary, if a collateral is disabled to be used as collateral in the protocol, it will substantially limit its usability and liquidity. We have introduced a supply cap, which helps limit the collateral risk exposure while maintaining a certain level of flexibility.

Supply Cap. We are one of the two protocols who utilize this risk parameter. In simple terms, the Supply Cap limits the overall exposure of a specific asset. This is particularly important if the said asset is enabled as a collateral within the protocol. For example, say we enable ABC as collateral within our lending protocol, if we set a supply cap of 10m ABC, at a collateral ratio of 75%, this will significantly limit the infinite mint risk of ABC; i.e., even if someone prints 1bn ABC, they can only supply no more than 10m into the lending protocol.

Borrow Cap is used to mitigate against risk of concentration risk and liquidity risk of the lending protocol. An example of this can be illustrated with Compound. Compound protocol initially did not have a Borrow Cap when in the initial periods of the yield farming craze. In one instance, when arbitrageurs used recursive borrowing to borrow significant amounts of BAT, the borrowing went out of control. If there is significant price swing for BAT, it could put the protocol at risk of being insolvent.

Loan-to-Value (or collateral ratio), this is the most important parameter in a lending protocol. It is basically the leverage ratio of a specific asset, i.e., how much you can borrow against the collateral. The more liquid, stable, and mature an asset is, the higher the loan-to-value ratio.

Liquidation Penalty, is the discount factor to be applied in the event of liquidation of a loan position. During liquidation, a liquidator is able to buy the defaulted borrower’s collateral at discount to market price by repaying the defaulted loan on borrower’s behalf. The discount is the liquidation penalty. The more illiquid, less matured, and more volatile an asset is, there’s typically a higher liquidation penalty to incentivize liquidators to liquidate the defaulted loans in the event of default.

Borrowed Asset Factor. dForce is the only lending protocol that introduce this risk parameter. This is to further expand LTV ratio, to consider the liquidity and market risks of the borrowed assets. For example, a borrower who supplies ETH to borrow USDC, is less risky than a borrower who supplies ETH to borrow WBTC (due to price volatility of both ETH/WBTC and illiquidity of WBTC v.s USDC). In other lending protocols, both transactions are subject to the same LTV ratio by design. dForce will take the borrowed asset risk factor into account, which could result in a lower LTV for the same collateral with different borrowed asset. Please note that in the initial stages, we will be setting the Borrowed Asset Factor to 100% to simplify the risk module.

Reserve Factor is the amount of interest spread that can charged into the reserve pool. This is similar to interest rate spread charge to be reserved by future use.

The above summarizes our risk assessment process and risk parameter standards for each asset accepted into the dForce lending protocol. A more detailed analysis of each asset will be proposed in due course.

Looking for more information…

WebsiteExplorerExplorer 2Source CodeSocial ChannelSocial Channel 2Social Channel 3Message BoardMessage Board 2Coinmarketcap

Would you like to earn DF right now! ☞ CLICK HERE

Top exchanges for token-coin trading. Follow instructions and make unlimited money

BinanceBittrexPoloniexBitfinexHuobi

Thank for visiting and reading this article! I’m highly appreciate your actions! Please share if you liked it!

#blockchain #crypto #dforce network #df

Words Counted: A Ruby Natural Language Processor.

WordsCounted

We are all in the gutter, but some of us are looking at the stars.

-- Oscar Wilde

WordsCounted is a Ruby NLP (natural language processor). WordsCounted lets you implement powerful tokensation strategies with a very flexible tokeniser class.

Are you using WordsCounted to do something interesting? Please tell me about it.

 

Demo

Visit this website for one example of what you can do with WordsCounted.

Features

  • Out of the box, get the following data from any string or readable file, or URL:
    • Token count and unique token count
    • Token densities, frequencies, and lengths
    • Char count and average chars per token
    • The longest tokens and their lengths
    • The most frequent tokens and their frequencies.
  • A flexible way to exclude tokens from the tokeniser. You can pass a string, regexp, symbol, lambda, or an array of any combination of those types for powerful tokenisation strategies.
  • Pass your own regexp rules to the tokeniser if you prefer. The default regexp filters special characters but keeps hyphens and apostrophes. It also plays nicely with diacritics (UTF and unicode characters): Bayrūt is treated as ["Bayrūt"] and not ["Bayr", "ū", "t"], for example.
  • Opens and reads files. Pass in a file path or a url instead of a string.

Installation

Add this line to your application's Gemfile:

gem 'words_counted'

And then execute:

$ bundle

Or install it yourself as:

$ gem install words_counted

Usage

Pass in a string or a file path, and an optional filter and/or regexp.

counter = WordsCounted.count(
  "We are all in the gutter, but some of us are looking at the stars."
)

# Using a file
counter = WordsCounted.from_file("path/or/url/to/my/file.txt")

.count and .from_file are convenience methods that take an input, tokenise it, and return an instance of WordsCounted::Counter initialized with the tokens. The WordsCounted::Tokeniser and WordsCounted::Counter classes can be used alone, however.

API

WordsCounted

WordsCounted.count(input, options = {})

Tokenises input and initializes a WordsCounted::Counter object with the resulting tokens.

counter = WordsCounted.count("Hello Beirut!")

Accepts two options: exclude and regexp. See Excluding tokens from the analyser and Passing in a custom regexp respectively.

WordsCounted.from_file(path, options = {})

Reads and tokenises a file, and initializes a WordsCounted::Counter object with the resulting tokens.

counter = WordsCounted.from_file("hello_beirut.txt")

Accepts the same options as .count.

Tokeniser

The tokeniser allows you to tokenise text in a variety of ways. You can pass in your own rules for tokenisation, and apply a powerful filter with any combination of rules as long as they can boil down into a lambda.

Out of the box the tokeniser includes only alpha chars. Hyphenated tokens and tokens with apostrophes are considered a single token.

#tokenise([pattern: TOKEN_REGEXP, exclude: nil])

tokeniser = WordsCounted::Tokeniser.new("Hello Beirut!").tokenise

# With `exclude`
tokeniser = WordsCounted::Tokeniser.new("Hello Beirut!").tokenise(exclude: "hello")

# With `pattern`
tokeniser = WordsCounted::Tokeniser.new("I <3 Beirut!").tokenise(pattern: /[a-z]/i)

See Excluding tokens from the analyser and Passing in a custom regexp for more information.

Counter

The WordsCounted::Counter class allows you to collect various statistics from an array of tokens.

#token_count

Returns the token count of a given string.

counter.token_count #=> 15

#token_frequency

Returns a sorted (unstable) two-dimensional array where each element is a token and its frequency. The array is sorted by frequency in descending order.

counter.token_frequency

[
  ["the", 2],
  ["are", 2],
  ["we",  1],
  # ...
  ["all", 1]
]

#most_frequent_tokens

Returns a hash where each key-value pair is a token and its frequency.

counter.most_frequent_tokens

{ "are" => 2, "the" => 2 }

#token_lengths

Returns a sorted (unstable) two-dimentional array where each element contains a token and its length. The array is sorted by length in descending order.

counter.token_lengths

[
  ["looking", 7],
  ["gutter",  6],
  ["stars",   5],
  # ...
  ["in",      2]
]

#longest_tokens

Returns a hash where each key-value pair is a token and its length.

counter.longest_tokens

{ "looking" => 7 }

#token_density([ precision: 2 ])

Returns a sorted (unstable) two-dimentional array where each element contains a token and its density as a float, rounded to a precision of two. The array is sorted by density in descending order. It accepts a precision argument, which must be a float.

counter.token_density

[
  ["are",     0.13],
  ["the",     0.13],
  ["but",     0.07 ],
  # ...
  ["we",      0.07 ]
]

#char_count

Returns the char count of tokens.

counter.char_count #=> 76

#average_chars_per_token([ precision: 2 ])

Returns the average char count per token rounded to two decimal places. Accepts a precision argument which defaults to two. Precision must be a float.

counter.average_chars_per_token #=> 4

#uniq_token_count

Returns the number of unique tokens.

counter.uniq_token_count #=> 13

Excluding tokens from the tokeniser

You can exclude anything you want from the input by passing the exclude option. The exclude option accepts a variety of filters and is extremely flexible.

  1. A space-delimited string. The filter will normalise the string.
  2. A regular expression.
  3. A lambda.
  4. A symbol that names a predicate method. For example :odd?.
  5. An array of any combination of the above.
tokeniser =
  WordsCounted::Tokeniser.new(
    "Magnificent! That was magnificent, Trevor."
  )

# Using a string
tokeniser.tokenise(exclude: "was magnificent")
# => ["that", "trevor"]

# Using a regular expression
tokeniser.tokenise(exclude: /trevor/)
# => ["magnificent", "that", "was", "magnificent"]

# Using a lambda
tokeniser.tokenise(exclude: ->(t) { t.length < 4 })
# => ["magnificent", "that", "magnificent", "trevor"]

# Using symbol
tokeniser = WordsCounted::Tokeniser.new("Hello! محمد")
tokeniser.tokenise(exclude: :ascii_only?)
# => ["محمد"]

# Using an array
tokeniser = WordsCounted::Tokeniser.new(
  "Hello! اسماءنا هي محمد، كارولينا، سامي، وداني"
)
tokeniser.tokenise(
  exclude: [:ascii_only?, /محمد/, ->(t) { t.length > 6}, "و"]
)
# => ["هي", "سامي", "وداني"]

Passing in a custom regexp

The default regexp accounts for letters, hyphenated tokens, and apostrophes. This means twenty-one is treated as one token. So is Mohamad's.

/[\p{Alpha}\-']+/

You can pass your own criteria as a Ruby regular expression to split your string as desired.

For example, if you wanted to include numbers, you can override the regular expression:

counter = WordsCounted.count("Numbers 1, 2, and 3", pattern: /[\p{Alnum}\-']+/)
counter.tokens
#=> ["numbers", "1", "2", "and", "3"]

Opening and reading files

Use the from_file method to open files. from_file accepts the same options as .count. The file path can be a URL.

counter = WordsCounted.from_file("url/or/path/to/file.text")

Gotchas

A hyphen used in leu of an em or en dash will form part of the token. This affects the tokeniser algorithm.

counter = WordsCounted.count("How do you do?-you are well, I see.")
counter.token_frequency

[
  ["do",   2],
  ["how",  1],
  ["you",  1],
  ["-you", 1], # WTF, mate!
  ["are",  1],
  # ...
]

In this example -you and you are separate tokens. Also, the tokeniser does not include numbers by default. Remember that you can pass your own regular expression if the default behaviour does not fit your needs.

A note on case sensitivity

The program will normalise (downcase) all incoming strings for consistency and filters.

Roadmap

Ability to open URLs

def self.from_url
  # open url and send string here after removing html
end

Contributors

See contributors.

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

Author: abitdodgy
Source code: https://github.com/abitdodgy/words_counted
License: MIT license

#ruby  #ruby-on-rails 

Royce  Reinger

Royce Reinger

1658068560

WordsCounted: A Ruby Natural Language Processor

WordsCounted

We are all in the gutter, but some of us are looking at the stars.

-- Oscar Wilde

WordsCounted is a Ruby NLP (natural language processor). WordsCounted lets you implement powerful tokensation strategies with a very flexible tokeniser class.

Features

  • Out of the box, get the following data from any string or readable file, or URL:
    • Token count and unique token count
    • Token densities, frequencies, and lengths
    • Char count and average chars per token
    • The longest tokens and their lengths
    • The most frequent tokens and their frequencies.
  • A flexible way to exclude tokens from the tokeniser. You can pass a string, regexp, symbol, lambda, or an array of any combination of those types for powerful tokenisation strategies.
  • Pass your own regexp rules to the tokeniser if you prefer. The default regexp filters special characters but keeps hyphens and apostrophes. It also plays nicely with diacritics (UTF and unicode characters): Bayrūt is treated as ["Bayrūt"] and not ["Bayr", "ū", "t"], for example.
  • Opens and reads files. Pass in a file path or a url instead of a string.

Installation

Add this line to your application's Gemfile:

gem 'words_counted'

And then execute:

$ bundle

Or install it yourself as:

$ gem install words_counted

Usage

Pass in a string or a file path, and an optional filter and/or regexp.

counter = WordsCounted.count(
  "We are all in the gutter, but some of us are looking at the stars."
)

# Using a file
counter = WordsCounted.from_file("path/or/url/to/my/file.txt")

.count and .from_file are convenience methods that take an input, tokenise it, and return an instance of WordsCounted::Counter initialized with the tokens. The WordsCounted::Tokeniser and WordsCounted::Counter classes can be used alone, however.

API

WordsCounted

WordsCounted.count(input, options = {})

Tokenises input and initializes a WordsCounted::Counter object with the resulting tokens.

counter = WordsCounted.count("Hello Beirut!")

Accepts two options: exclude and regexp. See Excluding tokens from the analyser and Passing in a custom regexp respectively.

WordsCounted.from_file(path, options = {})

Reads and tokenises a file, and initializes a WordsCounted::Counter object with the resulting tokens.

counter = WordsCounted.from_file("hello_beirut.txt")

Accepts the same options as .count.

Tokeniser

The tokeniser allows you to tokenise text in a variety of ways. You can pass in your own rules for tokenisation, and apply a powerful filter with any combination of rules as long as they can boil down into a lambda.

Out of the box the tokeniser includes only alpha chars. Hyphenated tokens and tokens with apostrophes are considered a single token.

#tokenise([pattern: TOKEN_REGEXP, exclude: nil])

tokeniser = WordsCounted::Tokeniser.new("Hello Beirut!").tokenise

# With `exclude`
tokeniser = WordsCounted::Tokeniser.new("Hello Beirut!").tokenise(exclude: "hello")

# With `pattern`
tokeniser = WordsCounted::Tokeniser.new("I <3 Beirut!").tokenise(pattern: /[a-z]/i)

See Excluding tokens from the analyser and Passing in a custom regexp for more information.

Counter

The WordsCounted::Counter class allows you to collect various statistics from an array of tokens.

#token_count

Returns the token count of a given string.

counter.token_count #=> 15

#token_frequency

Returns a sorted (unstable) two-dimensional array where each element is a token and its frequency. The array is sorted by frequency in descending order.

counter.token_frequency

[
  ["the", 2],
  ["are", 2],
  ["we",  1],
  # ...
  ["all", 1]
]

#most_frequent_tokens

Returns a hash where each key-value pair is a token and its frequency.

counter.most_frequent_tokens

{ "are" => 2, "the" => 2 }

#token_lengths

Returns a sorted (unstable) two-dimentional array where each element contains a token and its length. The array is sorted by length in descending order.

counter.token_lengths

[
  ["looking", 7],
  ["gutter",  6],
  ["stars",   5],
  # ...
  ["in",      2]
]

#longest_tokens

Returns a hash where each key-value pair is a token and its length.

counter.longest_tokens

{ "looking" => 7 }

#token_density([ precision: 2 ])

Returns a sorted (unstable) two-dimentional array where each element contains a token and its density as a float, rounded to a precision of two. The array is sorted by density in descending order. It accepts a precision argument, which must be a float.

counter.token_density

[
  ["are",     0.13],
  ["the",     0.13],
  ["but",     0.07 ],
  # ...
  ["we",      0.07 ]
]

#char_count

Returns the char count of tokens.

counter.char_count #=> 76

#average_chars_per_token([ precision: 2 ])

Returns the average char count per token rounded to two decimal places. Accepts a precision argument which defaults to two. Precision must be a float.

counter.average_chars_per_token #=> 4

#uniq_token_count

Returns the number of unique tokens.

counter.uniq_token_count #=> 13

Excluding tokens from the tokeniser

You can exclude anything you want from the input by passing the exclude option. The exclude option accepts a variety of filters and is extremely flexible.

  1. A space-delimited string. The filter will normalise the string.
  2. A regular expression.
  3. A lambda.
  4. A symbol that names a predicate method. For example :odd?.
  5. An array of any combination of the above.
tokeniser =
  WordsCounted::Tokeniser.new(
    "Magnificent! That was magnificent, Trevor."
  )

# Using a string
tokeniser.tokenise(exclude: "was magnificent")
# => ["that", "trevor"]

# Using a regular expression
tokeniser.tokenise(exclude: /trevor/)
# => ["magnificent", "that", "was", "magnificent"]

# Using a lambda
tokeniser.tokenise(exclude: ->(t) { t.length < 4 })
# => ["magnificent", "that", "magnificent", "trevor"]

# Using symbol
tokeniser = WordsCounted::Tokeniser.new("Hello! محمد")
tokeniser.tokenise(exclude: :ascii_only?)
# => ["محمد"]

# Using an array
tokeniser = WordsCounted::Tokeniser.new(
  "Hello! اسماءنا هي محمد، كارولينا، سامي، وداني"
)
tokeniser.tokenise(
  exclude: [:ascii_only?, /محمد/, ->(t) { t.length > 6}, "و"]
)
# => ["هي", "سامي", "وداني"]

Passing in a custom regexp

The default regexp accounts for letters, hyphenated tokens, and apostrophes. This means twenty-one is treated as one token. So is Mohamad's.

/[\p{Alpha}\-']+/

You can pass your own criteria as a Ruby regular expression to split your string as desired.

For example, if you wanted to include numbers, you can override the regular expression:

counter = WordsCounted.count("Numbers 1, 2, and 3", pattern: /[\p{Alnum}\-']+/)
counter.tokens
#=> ["numbers", "1", "2", "and", "3"]

Opening and reading files

Use the from_file method to open files. from_file accepts the same options as .count. The file path can be a URL.

counter = WordsCounted.from_file("url/or/path/to/file.text")

Gotchas

A hyphen used in leu of an em or en dash will form part of the token. This affects the tokeniser algorithm.

counter = WordsCounted.count("How do you do?-you are well, I see.")
counter.token_frequency

[
  ["do",   2],
  ["how",  1],
  ["you",  1],
  ["-you", 1], # WTF, mate!
  ["are",  1],
  # ...
]

In this example -you and you are separate tokens. Also, the tokeniser does not include numbers by default. Remember that you can pass your own regular expression if the default behaviour does not fit your needs.

A note on case sensitivity

The program will normalise (downcase) all incoming strings for consistency and filters.

Roadmap

Ability to open URLs

def self.from_url
  # open url and send string here after removing html
end

Are you using WordsCounted to do something interesting? Please tell me about it.

Gem Version 

RubyDoc documentation.

Demo

Visit this website for one example of what you can do with WordsCounted.


Contributors

See contributors.

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

Author: Abitdodgy
Source Code: https://github.com/abitdodgy/words_counted 
License: MIT license

#ruby #nlp 

Lisa joly

Lisa joly

1624658400

PAID NETWORK Review, Is it worth Investing in? Token Sale Coming Soon !!

Hey guys, in this video I review PAID NETWORK. This is a DeFi project that aims to solve complex legal process using decentralised protocols and DeFi products for 2021.

PAID Network is an ecosystem DAPP that leverages blockchain technology to deliver DeFi powered SMART Agreements to make business exponentially more efficient. We allow users to create their own policy, to ensure they Get PAID.

📺 The video in this post was made by Crypto expat
The origin of the article: https://www.youtube.com/watch?v=ZIU5javfL90
🔺 DISCLAIMER: The article is for information sharing. The content of this video is solely the opinions of the speaker who is not a licensed financial advisor or registered investment advisor. Not investment advice or legal advice.
Cryptocurrency trading is VERY risky. Make sure you understand these risks and that you are responsible for what you do with your money
🔥 If you’re a beginner. I believe the article below will be useful to you ☞ What You Should Know Before Investing in Cryptocurrency - For Beginner
⭐ ⭐ ⭐The project is of interest to the community. Join to Get free ‘GEEK coin’ (GEEKCASH coin)!
☞ **-----CLICK HERE-----**⭐ ⭐ ⭐
Thanks for visiting and watching! Please don’t forget to leave a like, comment and share!

#bitcoin #blockchain #paid network #paid network review #token sale #paid network review, is it worth investing in? token sale coming soon !!

aaron silva

aaron silva

1622197808

SafeMoon Clone | Create A DeFi Token Like SafeMoon | DeFi token like SafeMoon

SafeMoon is a decentralized finance (DeFi) token. This token consists of RFI tokenomics and auto-liquidity generating protocol. A DeFi token like SafeMoon has reached the mainstream standards under the Binance Smart Chain. Its success and popularity have been immense, thus, making the majority of the business firms adopt this style of cryptocurrency as an alternative.

A DeFi token like SafeMoon is almost similar to the other crypto-token, but the only difference being that it charges a 10% transaction fee from the users who sell their tokens, in which 5% of the fee is distributed to the remaining SafeMoon owners. This feature rewards the owners for holding onto their tokens.

Read More @ https://bit.ly/3oFbJoJ

#create a defi token like safemoon #defi token like safemoon #safemoon token #safemoon token clone #defi token