# Welcome to DCAP ## **Open Letter from Jared Lutz, CEO DCAP** Building the Decentralized Capital Allocation Protocol has been the single most deliberate decision I have made in my professional career. It was not impulsive or a play on recent global events. Building DCAP is an accumulation of life experiences in my development journey within the private, NGO, and blockchain sectors. My journey has led to an intense focus on stable investments, long-term growth, and equity accumulation. I have seen companies rise and fall too fast, and this is not an example to follow. Some companies in this sector have heightened volatility because of bad actors either within or outside the company. It is essential that we stand out uniquely, and DCAP allows us to do exactly that. I have lived my life under a single guiding principle: Birds of a feather flock together. This is the same sentiment as “If I know who your friends are, I know your character.” I have met amazing and incredible people in my life, as well as in the blockchain space, and I have surrounded myself with them for the adventure of a lifetime, the DCAP adventure. DCAP was designed to thrive and be supported by a growing portfolio of properties and cash flow assets. A token backed by property acquisition with cash flow allows investors to be introduced to cryptocurrency without the fear of significant financial loss. DCAP is not a community hype project. Hyping or selling on emotion leads to alarming volatility that attracts bad actors and scam artists. The DCAP ecosystem was created to find balance and stability. DCAP is not meant for investors looking for a quick return. This type of mentality, again, leads to unnecessary volatility. We are building a stable environment that acts as a portal or gateway for traditional fiat investors to bridge into cryptocurrency investments in a safe and stable manner. We will not pump an idea, we will not pay for influencers. We do not need to. Crypto is the biggest opportunity our generation has to shape its impact on the world. This is not a fad, this is not a turn and burn opportunity. This is longevity, true financial innovation. This is our time to come together and support the pioneers that paved the way in this emerging technological space. We need to be retaining lawyers and working with lawmakers and regulators to influence policy. We need to find stability, and build a sustainable infrastructure. With the executive order President Biden signed on March 9th, 2022, the United States government is aggressively positioning themselves to be the leader and influencer in the cryptocurrency financial markets. This is leading to and will continue to lead massive amounts of global adoption. While the industry continues to be plagued with these bad actors and scam artists, institutional and long-term investors are seeking safe and secure investments, while at the same time, taking advantage of the returns from investing in an emerging technological space. Although it is true that no investment is safe, we can strive to be better at ensuring the financial security of our future. We will focus on building stability through these stable asset class investments and we will build our entire infrastructure, right on top. In our opinion, there is no stronger use case for creating stability in an otherwise unstable market. ## Important Information This communication is for information purposes only and is not, and under no circumstances is to be construed as, an invitation to make an investment in Decentralize Capital Allocation Protocol “DCAP.” Investing in DCAP Investment Products & Currency involves risks. The recovery of an initial investment is at risk, and the anticipated return on such an investment is based on many performance assumptions. The actual amount distributed will depend on numerous factors, including DCAP’s financial performance, debt covenants and obligations, interest rates, working capital requirements and future capital requirements. In addition, the market value of DCAP, its investment products and currency may decline if DCAP is unable to meet its cash distribution targets in the future, and that decline may be material. It is important for an investor to consider the particular risk factors that may affect the industry in which it is investing and therefore the stability of the distributions that it receives. There can be no assurance that income tax laws and the treatment of mutual fund trusts will not be changed in a manner which adversely affects DCAP. PAST PERFORMANCE MAY NOT BE REPEATED. Investing in DCAP can involve significant risks and the value of an investment may go down as well as up. There is no guarantee of performance. An investment in DCAP is not intended as a complete investment program and should only be made after consultation with independent investment and tax advisors. Only investors who do not require immediate liquidity of their investment should consider a potential purchase of the DCAP token. The risks involved in this type of investment may be greater than those normally associated with other types of investments. ## Risks * **Risk of Hacking and Security Weakness** 1. Hackers or other groups or organizations may attempt to interfere with DCAP in a number of ways, including, but not limited to denial of service attacks, Sybil attacks, spoofing, smurfing, malware attacks, or consensus-based attacks, and any such similar events which could have an impact on DCAP, the dcap.finance Platform and the Services the Company may offer from time to time. * **Risk of Security weakness in the Smart Contract, Website and DCAP Source Code or any associates software and/or Infrastructure** 1. There is a risk that the Smart Contract, Website, the dcap.finance Platform and DCAP may unintentionally include weaknesses or bugs in the source code interfering with the use of or causing the loss of DCAP; the source code of the Website is open and could be updated, amended, altered or modified from time to time. The Company is unable to foresee or guarantee the precise result of an update, amendment, alteration or modification. As a result, any update, amendment, alteration or modification could lead to an unexpected or unintended outcome that adversely affects DCAP and/or the Website. As a result, DCAP may be lost. * **Risk of no Listing or low/no Liquidity** 1. DCAP coins are intended to be used solely for the dcap.finance Platform and the Company will not support or otherwise facilitate any secondary trading on an exchange or the secondary market or the external valuation of DCAP, which are all beyond the scope and purpose of the dcap.finance Platform. This restricts the contemplated intended use of DCAP only to the dcap.finance Platform and could therefore create illiquidity risk with respect to DCAP that the Participant owns. Even though there are currently online services available which enable exchange of cryptographic tokens with other such tokens or even enable the exchange of cryptographic tokens for fiat money, there are no warranties and/or guarantees that DCAP will be made available for exchange with other cryptographic tokens and/or fiat money, and no guarantees are given whatsoever with regard to the capacity and/or volume of such exchange/s. It shall be explicitly cautioned that such exchange, if any, might be subject to poorly-understood regulatory oversight, and the Company does not give any warranties in regard to any exchange services providers. Users including the Participant, if applicable, might be exposed to fraud and failure affecting those exchanges. In any case, it is not the Company’s aim to enable exchange of DCAP for other cryptographic tokens or for fiat currency and it shall therefore not commit to any endeavors to list DCAP on such exchanges or any secondary markets. * **Risk of Malfunction in the Ethereum Network or any other Blockchain and of Competing Platforms** 1. It is possible that DCAP tokens are interacting with malfunctions in an unfavorable way, including but not limited to one that results in the loss of DCAP or prevent their use on the dcap.finance Platform. It is possible that alternative platforms could be established that utilize the same open source code and protocol underlying the dcap.finance Platform and attempt to facilitate services that are materially similar to the dcap.finance Platform. The dcap.finance Platform may compete with these alternatives, which could negatively impact and dcap.finance Platform, including the utility of DCAP for use of the dcap.finance Platform * **Risk of Uninsured Losses** 1. Unlike bank accounts or accounts at some other financial institutions, DCAP coins and tokens are uninsured unless the Participant specifically obtains private insurance to insure them. Thus, in the event of loss of DCAP or loss of DCAP’s value, there is no public insurer, such as the Investor Compensation Scheme or private insurance arranged by the Company to offer recourse to the Participant. * **Risk associated with uncertain Regulations and enforcement actions** 1. The regulatory status of tokens in general, Initial Token or Coin Offerings, Private Placement Event and distributed ledger technology is unclear or unsettled in many jurisdictions. It is difficult to predict how or whether regulatory authorities may apply existing regulation with respect to such technology and its applications, including the dcap.finance Platform and the DCAP. It is likewise difficult to predict how or whether legislatures or regulatory agencies may implement regulatory actions or changes to law and regulation affecting distributed ledger technology and its applications, including the dcap.finance Platform and the tokens. Regulatory actions or changes to law and regulation could negatively impact DCAP and the dcap.finance Platform in various ways, including, but not limited to, a determination that the acquisition, holding and use or disposal and transfer of DCAP constitutes a regulated instrument that require registration or licensing of those instruments or some or all of the parties involved in the acquisition, contribution, sale and delivery thereof. The Company may cease operations or interrupt the Private Placement Event in a jurisdiction in the event that regulatory actions, or changes to law or regulation, make it illegal to operate in such jurisdiction, or commercially undesirable or no longer viable to obtain the necessary regulatory approval/s to operate in such jurisdiction or to provide the dcap.finance Platform. * **Risk arising from Taxation** 1. The tax characterization of DCAP is uncertain. The Participant must seek his own tax advice in connection with purchasing DCAP, which may result in adverse tax consequences to him, including withholding taxes, income taxes and tax reporting requirements. * **Risk of insufficient interest in DCAP and the dcap.finance Platform** 1. It is possible that DCAP and the dcap.finance Platform will no longer be used by a large number of individuals, companies and other entities or that there will be limited interest in the use of DCAP and the dcap.finance Platform. Such a lack of use or interest could negatively impact the development of the dcap. finance Platform and therefore the potential utility of DCAP. * **Internet Transmission Risks** 1. There are risks associated with using DCAP including, but not limited to, the failure of hardware, software, and Internet connections, or other technologies on which the dcap.finance Platform or the use of DCAP relies. Such failures may result in disruptions in communication, errors, distortions or delays when using DCAP and the dcap.finance Platform or the Website. * **Risk of Dissolution of the Company** 1. It is possible that, due to any number of reasons, including, but not limited to, a decrease in DCAP’s utility, the failure of commercial relationships, or intellectual property ownership challenges, unfavorable market conditions and added compliance and regulatory obligations, the use of the dcap.finance Platform may no longer be viable to be offered or the Company may need to cease trading and be dissolved and liquidated. * **Risk arising from Lack of Governance Rights** 1. Since DCAP coins do not represent or confer any ownership right or stake, share or security or equivalent rights, intellectual property rights or any other form of participation relating to the Company, all decisions involving the Company will be made by Company at their sole discretion, including, but not limited to, decisions to transfer more DCAP for use, to sell or liquidate the Company. These decisions could adversely affect the utility of that the Participant holds. * **Regulatory Risks and Market Risks** 1. The Company and by operation of the dcap.finance Platform, are subject to a variety of domestic (USA) and/or EU and international laws, regulation and directives, including those with respect to privacy and data protection, consumer protection, data security, and others. These laws, regulations and directives, and the interpretation or application of these laws, regulations and directives, could change. In addition, new laws, regulations or directives affecting the Company, the dcap.finance Platform and DCAP could be enacted, which could impact the utility of DCAP and their use on the dcap.finance Platform. Additionally, the Participants are subject to industry specific laws and regulations or licensing requirements. If any of the Parties fails to comply with any of these licensing requirements or other applicable laws or regulations, or if such laws and regulations or licensing requirements become more stringent or are otherwise expanded, it could adversely impact DCAP and the dcap.finance Platform, including the DCAP’ utility on the dcap.finance Platform. The Participant hereby accepts the risk that in some countries DCAP might be considered, now or in the future, a Security Token. In this case the Company gives no representations, warranties or guarantees that the Utility Tokens are not considered to be Security Tokens in all countries. The Participant hereby accepts to be solely responsible of the legal, financial and any other risks connected to DCAP as a security in his country and to be the only responsible to check if the holding, using and the disposal of DCAP is legal in your country. Also, changes in laws, regulations and directives governing the Company’s operations may adversely affect their business and consequently the dcap. com Platform. Any change in the Company’s tax status, or in taxation legislation in Malta or elsewhere, could affect the value of its financial holdings, its business and the Company’s ability to achieve its business objective and continual commitment to the development of the dcap.finance Platform. * **Other Inherent Risks** 1. The Participant understands and accepts the inherent risks associated with DCAP, to the extent not covered elsewhere in the Terms, including, but not limited to, risks associated with (a) money laundering; (b) fraud; (c) exploitation for illegal purposes; and (d) any other unanticipated risks. * **Unanticipated Risks** 1. Cryptographic tokens such as DCAP as well as blockchain are a new and untested technology. In addition to the risks included in the DCAP Documents there are other risks associated with the Participant’s acquisition, holding and use of DCAP , including some that the Company cannot or may not anticipate. Such risks may further materialise as unanticipated variations or combinations of the risks discussed in the DCAP Documents. The Participant hereby represents and warrants that he will take sole responsibility for any restrictions and risks associated with the holding or use of DCAP. If any of the risks, mentioned in the Terms are unacceptable or the Participant is not in the position to understand, the Participant should not acquire, hold or use DCAP. # Definitions ## Ecosystem Tokens ### DCAP Coin A utility cryptographic decentralized token issued by the Company based on the Ethereum protocol (ERC20 token) being the token which can be used by participants to acquire DCAP Ecosystem Tokens Contract Address: 0x7ce910a8e811be8cda9a862f799878a96d276e7c \*\*\*DO NOT SEND MONEY or TOKEN TO THE CONTRACT ADDRESS. SENDING MONEY OR TOKEN TO THE CONTRACT ADDRESS IS UNRECOVERABLE. ### Ordinary Token A cryptographic token designed to provide utility across the DCAP ecosystem. The ordinary token is not the same but has similar attributes as a "staking token." ### Preferred Token A security cryptographic ownership token filed with the Security and Exchange Commission under Regulation D rule 506(c). The DCAP Preferred Token is created by the Company, issued by the Company and is pegged to the actual shares and ownership of DCAP, registered as, Decentralized Capital Allocation Protocol. DCAP Preferred Tokens grant holders voting rights to participate in the DCAP-DAO. The DAO participates in decision-making processes, feedback polls and surveys in regards to the operations of the ecosystem. Under SEC regulations, ALL participants and owners of the Preferred token are required to hold the asset for 1 year before selling it. ## US Accredited Investor At the initial launch of DCAP, we are launching 2 tokens and an NFT pool. DCAP coin is a currency, DCAP preferred token and the NFT Pool are both US restricted securities registered with the SEC under Reg D section 506(c) and Reg D section 506(b). To be an accredited investor you need to make 300K/year for the last 2 years and or have 1m in vested assets excluding your home, specifically excluding your primary residence. If the investor isn't an accredited investor then they invest into the NFT pool where we can have 35 non-accredited investors. Those are the only direct profit share opportunities. A special note about restricted securities. Restricted securities cannot be sold for 1 year, this is a requirement from the SEC. ## SEC Exemptions ### Regulation D #### US SEC 506(b) [Rule 506(b)](https://www.ecfr.gov/cgi-bin/text-idx?SID=cd6d4f96f78e70b89d687c7892c9f6a9\&mc=true\&node=pt17.3.230\&rgn=div5#se17.3.230_1506) of Regulation D is considered a “safe harbor” under Section 4(a)(2). It provides objective standards that a company can rely on to meet the requirements of the Section 4(a)(2) exemption. Companies conducting an offering under Rule 506(b) can raise an unlimited amount of money and can sell securities to an unlimited number of accredited investors. An offering under Rule 506(b), however, is subject to the following requirements: * no general solicitation or advertising to market the securities * securities may not be sold to more than 35 non-accredited investors (all non-accredited investors, either alone or with a purchaser representative, must meet the legal standard of having sufficient knowledge and experience in financial and business matters to be capable of evaluating the merits and risks of the prospective investment) If non-accredited investors are participating in the offering, the company conducting the offering: * must give any non-accredited investors disclosure documents that generally contain the same type of information as provided in Regulation A offerings (the company is not required to provide specified disclosure documents to accredited investors, but, if it does provide information to accredited investors, it must also make this information available to the non-accredited investors as well) * must give any non-accredited investors financial statement information specified in Rule 506 and * should be available to answer questions from prospective purchasers who are non-accredited investors Purchasers in a Rule 506(b) offering receive “[restricted securities.](https://www.sec.gov/smallbusiness/exemptofferings/faq?auHash=rh5WfJi9h3wRzP6X2anOmgYLdhPHNuo-3Vw0YNZyR_M#faq4)" A company is required to file a notice with the Commission on Form D within 15 days after the first sale of securities in the offering. Although the Securities Act provides a federal preemption from state registration and qualification under Rule 506(b), the states still have authority to require notice filings and collect state fees. Rule 506(b) offerings are subject to [“bad actor” disqualification provisions.](https://www.sec.gov/info/smallbus/secg/bad-actor-small-entity-compliance-guide.htm) #### US SEC 506(c) [Rule 506(c) ](https://www.ecfr.gov/cgi-bin/text-idx?SID=cd6d4f96f78e70b89d687c7892c9f6a9\&mc=true\&node=pt17.3.230\&rgn=div5#se17.3.230_1506)permits issuers to broadly solicit and generally advertise an offering, provided that: * all purchasers in the offering are accredited investors * the issuer takes reasonable steps to verify purchasers’ accredited investor status and * certain other conditions in Regulation D are satisfied Purchasers in a Rule 506(c) offering receive “[restricted securities.](https://www.sec.gov/smallbusiness/exemptofferings/faq?auHash=rh5WfJi9h3wRzP6X2anOmgYLdhPHNuo-3Vw0YNZyR_M#faq4)” A company is required to file a notice with the Commission on Form D within 15 days after the first sale of securities in the offering. Although the Securities Act provides a federal preemption from state registration and qualification under Rule 506(c), the states still have authority to require notice filings and collect state fees. Rule 506(c) offerings are subject to [“bad actor” disqualification provisions.](https://www.sec.gov/info/smallbus/secg/bad-actor-small-entity-compliance-guide.htm) ### Regulation S The Commission adopted Regulation S to **enhance access to offshore securities markets for both foreign and domestic issuers**. Regulation S provides a safe harbor from the registration requirements of the Securities Act for offshore offers and sales of securities. Regulation S provides **an SEC-compliant way for U.S. and international (Non-U.S.) companies to raise capital** in and outside the U.S. It is unnecessary to have a company in the United States of America use Regulation S. A Regulation S offering can issue equity or debt securities. ## Participant Any person (natural or juridical), who has contributed and is bound by the terms of the private placement and this White Paper and/ or who intends to hold and/or use DCAP Ecosystem Token(s) at any moment in time and shall include any person who intends to become a Participant. # Issuer Information #### Company Name DECENTRALIZED CAPITAL ALLOCATION PROTOCOL INC. #### Company Address 651 N Broad St, Ste 205 #7991 Middletown, Delaware 19709 #### NAICS Code Finance and Insurance (52) #### NAICS Subcode Miscellaneous Intermediation (523910) #### Formation State Delaware #### Entity Type CCORPORATION #### Formation Date N/A #### Entity ID N/A #### EIN (Tax ID Number) N/A # KYC & AML Know Your Customer (KYC) and Anti-Money Laundering (AML) & Counter Financing of Terrorism * The issuer has adopted rigorous KYC procedures to verify the identity of every applicant, and the beneficial owner (where applicable) that has expressed interest in acquiring DCAP and only those contributors which have successfully identified themselves in the KYC procedure, to the Issuer's satisfaction, have been successful in participating in the DCAP Private Placement. * Strict compliance with KYC procedures protects the contributors and the Issuer from criminal elements such as money laundering activities and terrorism financing. The KYC procedures adopted were based on current market practices and in accordance with all applicable USA legislation * The Issuer recognizes the importance of preventing money laundering and terrorism financing therefore AML and counterfinancing of terrorism procedures have been implemented in accordance with applicable legislation, notably the Prevention of Money Laundering Act, including any rules and regulations enacted thereunder. The Issuer particularly requested the identification of any politically exposed persons (“PEPs”), an individual who is or who has, been entrusted with prominent public functions, and immediate family members, or persons known to close associates of such persons. **The policies and procedures implemented by the Issuer in this respect are based on contributor’s identification and contributor’s identity verification on the basis of the following sources:** * Documentation provided by the contributors. Information about the contributors obtained from reliable and independent sources. * In particular, the Issuer has and shall not conduct business with the following risky persons: * Those refusing to provide the Issuer with required information or documentation. * Entities whose shareholder/control structure cannot be determined. * Those individuals that are included on any official sanction lists. * Individuals indicating possible involvement in criminal activities based on available information. * Those individuals with business where activity, source of funds or source of wealth cannot be reasonably verified. **An appropriate record of received documentation and information, copies or recommendations are retained by the Issuer for the legally established time period as per applicable laws, including AML legislation and data protection laws including General Data Protection Regulation.** IP Rights and Service providers * Intellectual property rights associated with the offering, projects arising from it, and protection thereof: * The DCAP and dcap.finance marks, all content on the DCAP website ([www.dcap.finance](http://www.dcap.finance)) and this white paper in relation to the DCAP offering and the dcap.finance platform, unless mentioned otherwise, remain the intellectual property rights of the Issuer. This means that readers are not allowed to use the content contained in web pages, electronic or written publications or any other media and/or words, phrases, names, designs or logo that are our trademarks without our express written permission. All information provided on website, whitepaper, business model and any other public document, is subject to change without any notice to any person including any stakeholders or token holders. # Insider Trading Updated: 15th March 2022 DCAP Insider Trading Policy Updated: 15th March 2022 ### **1) Purpose** The purpose of this Insider Trading Policy (‘Policy’) is to describe the treatment and restricted use of Nonpublic Material Information relating to Decentralized Capital Allocation Protocol Inc, dba DCAP and its affiliates and subsidiary entities (the ‘Group’). This Policy particularly seeks to protect any confidential and price-sensitive information to ensure that the market for the Tokens remains transparent and therefore trading of Tokens is a fair process for all. ### **2) Scope** The Policy is applicable to all the Associates of the Group and shall continue to apply to such persons throughout the course of their employment or association with the Group. This Policy shall also specifically apply to all Associates who may have received any Tokens from the Group by way of any Group distribution scheme. The Group has adopted this Policy to promote compliance with applicable laws to prevent insider trading by its’ Associates. The Group’s legal team has been given authority to implement, enforce and interpret this Policy, as well as to make reports about any breaches or matters arising under this Policy which may result in criminal actions being taken against the individuals reported. All questions regarding this Policy should be directed to the Group’s legal team. The Company expects strict compliance with this Policy by all Associates. Failure to observe the requirements of this Policy may result in serious legal consequences, including criminal fines and civil penalties, for the violating Associate. Failure to follow the letter and spirit of this Policy may serve as a basis for disciplinary action, including but not limited to the termination of employment or association with the Group, as may be deemed appropriate at the Group’s absolute and sole discretion. ### **3) Definitions** Associates all directors, officers and employees of, and consultants and contractors to, the Company and its subsidiaries, as well as their Related Persons; DCAP Coin the digital token issued by DCAP, a Group entity bearing the ‘$DCAP’ symbol; Ordinary Token the utility digital token issued by DCAP giving the holders thereof access to participate in the ecosystem. $DCAP coins can only be traded on the DCAP Platform, DCAP.finance and any other platforms as may be determined by us; Preferred Token the equity digital token issued by DCAP, bearing the symbol DCAPE, giving the holders thereof access to participate in revenue and profit sharing along with voting rights in the DCAP-DAO. DCAPE tokens are a restricted security filed with the Security and Exchange Commission under rule 506(c) can only be traded 1 year after purchase and only on the DCAP Platform, DCAP.finance and any other platforms as may be determined by us; Material Information information that there is a substantial likelihood a reasonable individual would consider important in making a decision to buy or sell Tokens or other instruments that is likely to have a significant effect on the market price and overall performance of the relevant Token. Material Information can be positive or negative and can relate to any aspect of the Group’s business, including but not limited to, significant changes in the Group’s prospects, potential partnerships, new and upcoming projects, changes in assets, earnings or reserves, changes in management, plans or agreements even if preliminary in nature involving mergers, acquisitions, licensing arrangements, purchases or sales of assets. Material Information is not limited to historical facts but may also include projections and forecasts. Determinations of materiality are always almost judged with the benefit of hindsight and, as such, when in doubt Associates should assume that the information is material and treat it accordingly. If unsure whether information is material, Associates should consult the Group’s Senior Personnel before making any decision to disclose such information or to trade in or recommend Tokens to which that information relates. Nonpublic information that has not been disclosed generally to the market or to the public. Unless such information was disseminated in a manner designed to reach individuals, and at least one day elapsed between the time of the event or when the information became known and its public disclosure, it shall be deemed to be Nonpublic. Nonpublic information may include (i) information available to a select group of individuals within the Group, (ii) undisclosed facts that are subject of rumors, (iii) information that has been entrusted to the Group on a confidential basis until a public announcement of the information has been made and enough time has elapsed for the market to respond to a public announcement of the information. As with questions of materiality, if it is unclear as to whether information nonpublic, Associates should either consult with any Senior Personnel or assume that the information is nonpublic and treat it as confidential. Related Person (a) a family member who resides with a person, anyone else who lives in such a person’s household and any other family members whose transactions are directed by such person or subject to such person’s influence or control. Close associates and friends are also considered as falling within the definition of Related Person.\ (b) any person who holds at least 20% of the share capital of any Group company or is controlling more than 20% of the voting power in that Group company.\ (c) A person acting in capacity as trustee of any trust, the beneficiaries of which include the related person, the related person’s dependent or a body corporate with which one is associated as set out above.\ (d) A person acting in a capacity as a business partner of that restricted person\ the Group’s directors and executive officers, specifically designated and non-executive officers and other key employees specifically designated. Senior Personnel the Group’s directors and executive officers, specifically designated and non-executive officers and other key employees specifically designated. Tokens collectively refers to the DCAP Tokens, Ordinary Tokens and the Preferred Tokens as well as any other digital tokens or instruments that may be launched or issued by the Group in the future. ### **4) Restrictions and Prohibited Transactions** Participating in any of the following transactions is strictly prohibited, irrespective whether a gain or loss is made from such transactions: 4.1. Insider Trading Restrictions a) Trading on Nonpublic Material Information. Associates in possession of, or aware of, Nonpublic Material Information relating to the Group and/or the Tokens may NOT purchase or sell (or offer to purchase or sell) Tokens, engage in or encourage a Related Person to purchase, sell or in any way encourage any other action which would take advantage of such Nonpublic Material Information, until after the lapse of one full day following the date of public disclosure of such Material Information. b) Tipping. Associates MAY NOT disclose Nonpublic Material Information to other persons or entities (including Related Persons) that could purchase or sell Tokens. An Associate who tips others may also be liable for transactions done by such ‘tipped’ persons to whom the Associate had disclosed Nonpublic Material Information. Tippers can be subject to the same penalties and sanctions as the ‘tipped’ persons that have executed the transaction, even when the tipper did not profit from the transaction. c) Information about other Companies. Associates may become aware of Nonpublic Material Information of other companies, separate and distinct from the Group, in the course of their association with the Group. Associates are prohibited from purchasing or selling Tokens or securities of other companies while they are in possession of, or aware of, such Nonpublic Material Information and from passing such information on to other persons or entities who could purchase or sell the Tokens or any other instruments of such other companies. This Policy requires Associates to treat Nonpublic Material Information of such companies with the same care required with respect to Nonpublic Material Information related directly to the Group. ### **5. Trading Blackouts** Specific Events. Under certain circumstances, the Group may impose a complete ban on the purchase/trading of Tokens as a result of specific events or during a specific timeframe and may result in Associate accounts being temporarily locked. Associates affected by such specific blackouts will be notified with respect to the specific blackout periods and all such periods will be managed in all respects by the Group’s Senior Personnel. ### **6. Permitted Token Transactions** Strictly subject to the Insider Trading Restrictions mentioned in section 4.1 above, the following transaction provision is enforced on token are permitted on DCAP.finance and DCAP platforms (and any other platforms operated by the Group): I. All persons that have access to inside information will be required to file a pre-clearance form before selling any securities. ### **7. Monitoring and Compliance with this Policy** All Associates must disclose their user IDs for any Group-owned platforms, but most notably DCAP.finance. The Group shall monitor Associate accounts periodically. Any Associate breaching this Policy may result in disciplinary proceedings being taken against the Associate and other actions which the Group deems appropriate, including the blocking of the relevant accounts and confiscation of Tokens. ### **8. Exceptions** The restrictions set out in this Policy do not apply in cases where the Group issues dedicated guidelines and instructions in relation to the trading of Tokens pursuant to any token distribution scheme, or similar document, launched by the Group following the distribution of (any) Tokens to employees and/or Associates. ### **9. Trading Orders** Associates may establish written orders with authorized exchanges which permit automatic trading of Tokens as long as such trading plans (buy order / sell orders) are NOT made during a blackout period and in accordance with the Insider Trading Restrictions outlined in Section 4.1 above. ### **10. Protection Confidential Information** Under this Policy, all Associates are expected to treat as sensitive and confidential all nonpublic Material Information relating to the Group. Associates may not disclose such information to any third party who does not have a legitimate need for such information in connection with the Group’s business. Associates are expected to be careful that their conversations are not overheard and to take all reasonable steps necessary to ensure that confidential documents containing such information are not left unattended. Any and all inquiries about the Group that may be made by the press or general public should be referred to either of the following individuals: • Jared Lutz – Chief Executive Officer: ; or\ • Jay Scheinok – Chief Operating Officer: Any queries concerning this policy should be directed to the legal department on . # Buying the Token [Click here to buy DCAP on PancakeSwap](https://pancakeswap.finance/swap?outputCurrency=0x7cE910A8e811be8CDa9A862f799878A96d276e7C) # What we do Bringing stability to cryptocurrency through sustainable returns from cash flow assets, backed by property acquisitions. DCAP is dedicated to providing generational income with the highest level of knowledge and transparency. \* Accountability \* Stability \* Growth \* ### Problem There are many problems that are present within the cryptocurrency financial markets. Most notably would be the lack of liquidity within the market. The lack of liquidity leads to significant volatility that brings forth large amounts of FUD (fear, uncertainty, doubt). Although it is true that no investment is safe, we can and should strive to be better at ensuring the financial security of our future. We need to focus on building stability through these stable asset class investments that can attract traditional fiat market participants. ### Our solution The DCAP ecosystem was built to be supported by a portfolio of properties and cash flow assets. This allows investors to be introduced to cryptocurrency without the fear of significant financial loss. DCAPs stable environment acts as a portal or gateway for traditional fiat investors to bridge into cryptocurrency in a safe and stable manner. Crypto is the biggest opportunity our generation has to shape its impact on the world. We need to be retaining lawyers and working with lawmakers and regulators to influence policy. The United States government is aggressively positioning themselves to be the leader and influencer in the cryptocurrency financial markets. This is leading to and will continue to lead massive amounts of global adoption. While the industry continues to be plagued with bad actors and scam artists, institutional and long-term investors are seeking security for their money. The DCAP ecosystem relies upon its dual liquidity protocols (token/business revenue) backed by physical income producing assets. * Income: Provides the foundation for Monthly Revenues * Investment Growth: A hard asset that appreciates over time * Lower Volatility: Our portfolio is heavily weighted with land and property acquisitions. Not Impacted by as many short-term market forces as other asset classes * Capital Preservation: For several usages a fundamental staple with downside protection * Inflation hedge: Real Estate has a history of protecting against the destruction of wealth caused by inflation. # About us Based in San Diego, California, Decentralized Capital Allocation Protocol “DCAP” is a decentralized finance company that invests in income producing business assets, including but not limited to: residential, corporate, industrial, and vacation properties, mortgage financing, corporate financing, corporate acquisitions, treasury bonds, gold, cd’s, company stocks, etc. ## Team ![](https://4077694258-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgDFjdUCD2yPUEpF0F4ja%2Fuploads%2F2VfmskVhA3DA8buEYdft%2Fteam.png?alt=media\&token=b135dd34-ac4f-4560-9e2c-9e347a644c79) ### Board of Directors ![](https://4077694258-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgDFjdUCD2yPUEpF0F4ja%2Fuploads%2FhKkc0kKKDNvEFoRLvbZ9%2Fdirectors.png?alt=media\&token=1b895823-f57c-4543-9e00-fe3d52bd473e) ### Legal ![](https://4077694258-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgDFjdUCD2yPUEpF0F4ja%2Fuploads%2FHkD06t27HbwRebLueTds%2Fmofo.png?alt=media\&token=b5d9a178-4aba-4075-b97d-b65630efa6a7) DCAP's Attorney on record is Morrison Foerster. () About MoFo **Morrison & Foerster LLP** (also known as MoFo) is an American multinational law firm headquartered in San Francisco, California, with 17 offices located throughout the United States, Asia, and Europe. The firm has over 1,000 lawyers who advise clients across a range of industries and practices, including intellectual property, patent litigation, corporate/M\&A, business restructuring, and securities. As one of the largest firms in the world, represented SoftBank in Alibaba's U.S. IPO—the largest IPO in history. MoFo clients include some of the largest financial institutions, Fortune 100 companies, and leading technology and life sciences companies. They represent investment funds and startup companies, and over the years have supported their growth and development as leading industry players and household brands. ## Contact us BSC Token Address: [0x7cE910A8e811be8CDa9A862f799878A96d276e7C](https://pancakeswap.finance/swap?outputCurrency=0x7cE910A8e811be8CDa9A862f799878A96d276e7C) Website: [www.dcap.finance](http://www.dcap.finance) Email: ### Socials Discord: YouTube: [YouTube.com/strangeinvesting](https://www.youtube.com/channel/UCJeOADiReYrHIj0TjBGe0FA?app=desktop) ​Facebook: [https://facebook.com/](https://www.facebook.com/DCAPofficial/) # Tokenomics DCAP operates a dual-layer tokenomic ecosystem that allows us to bring further stabilization to our company and your investment. ## **Layer 1** Our first layer is a pretty standard allocation of token that you’ve seen in many crypto projects.\ Our initial supply of token is allocated to our team, advisors, partners, liquidity, and our token sale. It's important to note that Layer 1 operates solely on the DCAP coin, which is our ecosystem currency. In an effort to comply with our understanding of regulations set forth by the SEC, funding the liquidity pool with a public presale from unknown investors would revoke the dcap coin currency status and the event would be classified as a security. We have a security token and security investment sales will be made there after the appropriate investor identity has adhered to SEC policies. Following the letter of law, the best we can interpret, the initial supply of the liquidity pool will only be funded by owners, board members, and partners that have an intimate understanding of the risks associated with being a liquidity provider. #### Allocation * Liquidity - 67.30% * Ordinary Token - 10,000,000 $DCAP * Preferred Token - 20,000,000 $DCAP * PancakeSwap - 5,000,000 $DCAP * NFT Pool - 11.54% * 6,000,000 $DCAP * Pre-Sale - 21.16% * 11,000,000 $DCAP ## Layer 2 What is traditional staking vs DCAP staking? * Traditional Staking * Staking cryptocurrencies is when the owner of crypto assets “commits” those assets to support a blockchain. This type of staking could be considered a security as they are “lending” those assets to a third party in exchange for “rewards,” which is effectively revenue or more token. * DCAP Staking * DCAP doesn’t operate like traditional staking. DCAP operates a multi-layer ecosystem with several tokens at play. At no point is a DCAP investor “lending” token for us to use at-will. DCAP investors are incentivized to swap DCAP for another token in our ecosystem. Swapping into another token grants the investor access to a different layer in the ecosystem that has different opportunities only available to the token holders of that layer. * What happens when the user swaps for the “Staking” layer * When the user swaps to the staking layer they are effectively selling their token or “swapping” it for the staking layer token “Ordinary Token” * What is the purpose of swapping to the Ordinary Token, why would DCAP want users to do that? * When a user swaps to the Ordinary token they are effectively removing the DCAP token from circulation therefore increasing the scarcity of the DCAP token. Increasing the scarcity (limiting supply) while retaining a steady and consistent demand compounds the value of an asset. ## Revenue, Buy Backs & Cashflow Our acquisitions, such as real estate rental properties, generate revenue. That revenue then re-enters the DCAP token ecosystem through our TAP, our Token Allocation Protocol. From there the TAP sends 40% to our secondary liquidity pool. This acts as a stabilizer to the main liquidity pool ensuring safer transactions, with less volatility of the DCAP token. The remainder of the token is used to incentivize our token holders to operate within the DCAP ecosystem. ## **10% Transaction Fee** When buying and selling DCAP, the smart contract initiates a 10% transaction fee. That fee is converted to stable token and sent to our Capital Allocation Protocol, which is controlled by the Board of Directors, and then eventually the DCAP-DAO. All funds are controlled by the Board of Directors until the DCAP DAO is launched. # Flowcharts ### Tokenomics {% file src="/files/31j2cGGV3yD1PSvldHYF" %} ### Accounting {% file src="/files/n5ARfudfBU3eaiYVualy" %} ### Corporate structure {% file src="/files/av1A5U4FAzLtnCTvU9av" %} # Smart Contracts ### 1SynDcap DAO LLC View the contract code [here](https://github.com/dcapfinance/contracts/blob/main/1syndcapDAO.sol). ### CAP Controlled by the Board of Directors, all funds received from the transactional fee are sent here and then distribution to acquisitions and operations. All funds are controlled by the Board of Directors until the DCAP DAO is launched. ### TAP **Our TAP, Token Allocation Protocol, is a smart contract that distributes DCAP profits throughout the ecosystem.** ![](https://4077694258-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgDFjdUCD2yPUEpF0F4ja%2Fuploads%2FMykssd3qwsse7xewCKFn%2Ftap-model.png?alt=media\&token=2125a092-0b48-48b8-a985-200e8828cbe7) * $DCAP Transaction Fee Funds Acquisitions and Operations * Acquisitions Fund $DCAP Liquidity * Acquisitions Buybacks $DCAP Token * Acquisitions Fund Ecosystem Token * Security Token Profit-Share * NFT Pool Profit-Share ### Oracle Oracles are designed to receive and collect off-chain data. Our Oracle is specifically designed to create a risk assessment score that will automatically allocate a certain percentage of the revenue to the liquidity pool. # $DCAP /\*\* \*Submitted for verification at BscScan.com on 2021-12-17 \*/ // SPDX-License-Identifier: MIT pragma solidity ^0.8.9; /\*\* * @dev Interface of the ERC20 standard as defined in the EIP. */ interface IERC20 { /*\* * @dev Returns the amount of tokens in existence. \*/ function totalSupply() external view returns (uint256); /\*\* * @dev Returns the amount of tokens owned by `account`. \*/ function balanceOf(address account) external view returns (uint256); /\*\* * @dev Moves `amount` tokens from the caller's account to `recipient`. * * Returns a boolean value indicating whether the operation succeeded. * * Emits a {Transfer} event. \*/ function transfer(address recipient, uint256 amount) external returns (bool); /\*\* * @dev Returns the remaining number of tokens that `spender` will be * allowed to spend on behalf of `owner` through {transferFrom}. This is * zero by default. * * This value changes when {approve} or {transferFrom} are called. \*/ function allowance(address owner, address spender) external view returns (uint256); /\*\* * @dev Sets `amount` as the allowance of `spender` over the caller's tokens. * * Returns a boolean value indicating whether the operation succeeded. * * IMPORTANT: Beware that changing an allowance with this method brings the risk * that someone may use both the old and the new allowance by unfortunate * transaction ordering. One possible solution to mitigate this race * condition is to first reduce the spender's allowance to 0 and set the * desired value afterwards: * * * Emits an {Approval} event. \*/ function approve(address spender, uint256 amount) external returns (bool); /\*\* * @dev Moves `amount` tokens from `sender` to `recipient` using the * allowance mechanism. `amount` is then deducted from the caller's * allowance. * * Returns a boolean value indicating whether the operation succeeded. * * Emits a {Transfer} event. \*/ function transferFrom( address sender, address recipient, uint256 amount ) external returns (bool); /\*\* * @dev Emitted when `value` tokens are moved from one account (`from`) to * another (`to`). * * Note that `value` may be zero. \*/ event Transfer(address indexed from, address indexed to, uint256 value); /\*\* * @dev Emitted when the allowance of a `spender` for an `owner` is set by * a call to {approve}. `value` is the new allowance. \*/ event Approval(address indexed owner, address indexed spender, uint256 value); } /\*\* * @dev Interface for the optional metadata functions from the ERC20 standard. * * *Available since v4.1.* */ interface IERC20Metadata is IERC20 { /*\* * @dev Returns the name of the token. \*/ function name() external view returns (string memory); /\*\* * @dev Returns the symbol of the token. \*/ function symbol() external view returns (string memory); /\*\* * @dev Returns the decimals places of the token. \*/ function decimals() external view returns (uint8); } /\* * @dev Provides information about the current execution context, including the * sender of the transaction and its data. While these are generally available * via msg.sender and msg.data, they should not be accessed in such a direct * manner, since when dealing with meta-transactions the account sending and * paying for execution may not be the actual sender (as far as an application * is concerned). * * This contract is only required for intermediate, library-like contracts. \*/ abstract contract Context { function \_msgSender() internal view virtual returns (address) { return msg.sender; } function \_msgData() internal view virtual returns (bytes calldata) { return msg.data; } } /\*\* * @dev Implementation of the {IERC20} interface. * * This implementation is agnostic to the way tokens are created. This means * that a supply mechanism has to be added in a derived contract using {\_mint}. * For a generic mechanism see {ERC20PresetMinterPauser}. * * TIP: For a detailed writeup see our guide * * to implement supply mechanisms]. * * We have followed general OpenZeppelin guidelines: functions revert instead * of returning `false` on failure. This behavior is nonetheless conventional * and does not conflict with the expectations of ERC20 applications. * * Additionally, an {Approval} event is emitted on calls to {transferFrom}. * This allows applications to reconstruct the allowance for all accounts just * by listening to said events. Other implementations of the EIP may not emit * these events, as it isn't required by the specification. * * Finally, the non-standard {decreaseAllowance} and {increaseAllowance} * functions have been added to mitigate the well-known issues around setting * allowances. See {IERC20-approve}. \*/ contract ERC20 is Context, IERC20, IERC20Metadata { mapping(address => uint256) private \_balances; mapping(address => mapping(address => uint256)) private \_allowances; uint256 private \_totalSupply; string private \_name; string private \_symbol; /\*\* * @dev Sets the values for {name} and {symbol}. * * The default value of {decimals} is 18. To select a different value for * {decimals} you should overload it. * * All two of these values are immutable: they can only be set once during * construction. \*/ constructor(string memory name\_, string memory symbol\_) { *name = name*; *symbol = symbol*; } /\*\* * @dev Returns the name of the token. \*/ function name() public view virtual override returns (string memory) { return \_name; } /\*\* * @dev Returns the symbol of the token, usually a shorter version of the * name. \*/ function symbol() public view virtual override returns (string memory) { return \_symbol; } /\*\* * @dev Returns the number of decimals used to get its user representation. * For example, if `decimals` equals `2`, a balance of `505` tokens should * be displayed to a user as `5,05` (`505 / 10 ** 2`). * * Tokens usually opt for a value of 18, imitating the relationship between * Ether and Wei. This is the value {ERC20} uses, unless this function is * overridden; * * NOTE: This information is only used for *display* purposes: it in * no way affects any of the arithmetic of the contract, including * {IERC20-balanceOf} and {IERC20-transfer}. \*/ function decimals() public view virtual override returns (uint8) { return 18; } /\*\* * @dev See {IERC20-totalSupply}. \*/ function totalSupply() public view virtual override returns (uint256) { return \_totalSupply; } /\*\* * @dev See {IERC20-balanceOf}. \*/ function balanceOf(address account) public view virtual override returns (uint256) { return \_balances\[account]; } /\*\* * @dev See {IERC20-transfer}. * * Requirements: * * * `recipient` cannot be the zero address. * * the caller must have a balance of at least `amount`. \*/ function transfer(address recipient, uint256 amount) public virtual override returns (bool) { \_transfer(\_msgSender(), recipient, amount); return true; } /\*\* * @dev See {IERC20-allowance}. \*/ function allowance(address owner, address spender) public view virtual override returns (uint256) { return \_allowances\[owner]\[spender]; } /\*\* * @dev See {IERC20-approve}. * * Requirements: * * * `spender` cannot be the zero address. \*/ function approve(address spender, uint256 amount) public virtual override returns (bool) { \_approve(\_msgSender(), spender, amount); return true; } /\*\* * @dev See {IERC20-transferFrom}. * * Emits an {Approval} event indicating the updated allowance. This is not * required by the EIP. See the note at the beginning of {ERC20}. * * Requirements: * * * `sender` and `recipient` cannot be the zero address. * * `sender` must have a balance of at least `amount`. * * the caller must have allowance for `sender`'s tokens of at least * `amount`. \*/ function transferFrom( address sender, address recipient, uint256 amount ) public virtual override returns (bool) { \_transfer(sender, recipient, amount); uint256 currentAllowance = \_allowances\[sender]\[\_msgSender()]; require(currentAllowance >= amount, "ERC20: transfer amount exceeds allowance"); unchecked { \_approve(sender, \_msgSender(), currentAllowance - amount); } return true; } /\*\* * @dev Atomically increases the allowance granted to `spender` by the caller. * * This is an alternative to {approve} that can be used as a mitigation for * problems described in {IERC20-approve}. * * Emits an {Approval} event indicating the updated allowance. * * Requirements: * * * `spender` cannot be the zero address. \*/ function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) { \_approve(\_msgSender(), spender, \_allowances\[\_msgSender()]\[spender] + addedValue); return true; } /\*\* * @dev Atomically decreases the allowance granted to `spender` by the caller. * * This is an alternative to {approve} that can be used as a mitigation for * problems described in {IERC20-approve}. * * Emits an {Approval} event indicating the updated allowance. * * Requirements: * * * `spender` cannot be the zero address. * * `spender` must have allowance for the caller of at least * `subtractedValue`. \*/ function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) { uint256 currentAllowance = \_allowances\[\_msgSender()]\[spender]; require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero"); unchecked { \_approve(\_msgSender(), spender, currentAllowance - subtractedValue); } return true; } /\*\* * @dev Moves `amount` of tokens from `sender` to `recipient`. * * This internal function is equivalent to {transfer}, and can be used to * e.g. implement automatic token fees, slashing mechanisms, etc. * * Emits a {Transfer} event. * * Requirements: * * * `sender` cannot be the zero address. * * `recipient` cannot be the zero address. * ``` * `sender` must have a balance of at least `amount`. \*/ function \_transfer( address sender, address recipient, uint256 amount ) internal virtual { require(sender != address(0), "ERC20: transfer from the zero address"); require(recipient != address(0), "ERC20: transfer to the zero address"); ``` ``` \_beforeTokenTransfer(sender, recipient, amount); uint256 senderBalance = \_balances\[sender]; require(senderBalance >= amount, "ERC20: transfer amount exceeds balance"); unchecked { \_balances\[sender] = senderBalance - amount; } \_balances\[recipient] += amount; emit Transfer(sender, recipient, amount); \_afterTokenTransfer(sender, recipient, amount); } ``` /\*\* @dev Creates `amount` tokens and assigns them to `account`, increasing * the total supply. * * Emits a {Transfer} event with `from` set to the zero address. * * Requirements: * * ``` * `account` cannot be the zero address. \*/ function \_mint(address account, uint256 amount) internal virtual { require(account != address(0), "ERC20: mint to the zero address"); ``` ``` \_beforeTokenTransfer(address(0), account, amount); \_totalSupply += amount; \_balances\[account] += amount; emit Transfer(address(0), account, amount); \_afterTokenTransfer(address(0), account, amount); } ``` /\*\* * @dev Destroys `amount` tokens from `account`, reducing the * total supply. * * Emits a {Transfer} event with `to` set to the zero address. * * Requirements: * * * `account` cannot be the zero address. * ``` * `account` must have at least `amount` tokens. \*/ function \_burn(address account, uint256 amount) internal virtual { require(account != address(0), "ERC20: burn from the zero address"); ``` ``` \_beforeTokenTransfer(account, address(0), amount); uint256 accountBalance = \_balances\[account]; require(accountBalance >= amount, "ERC20: burn amount exceeds balance"); unchecked { \_balances\[account] = accountBalance - amount; } \_totalSupply -= amount; emit Transfer(account, address(0), amount); \_afterTokenTransfer(account, address(0), amount); } ``` /\*\* * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens. * * This internal function is equivalent to `approve`, and can be used to * e.g. set automatic allowances for certain subsystems, etc. * * Emits an {Approval} event. * * Requirements: * * * `owner` cannot be the zero address. * ``` * `spender` cannot be the zero address. \*/ function \_approve( address owner, address spender, uint256 amount ) internal virtual { require(owner != address(0), "ERC20: approve from the zero address"); require(spender != address(0), "ERC20: approve to the zero address"); ``` ``` \_allowances\[owner]\[spender] = amount; emit Approval(owner, spender, amount); } ``` /\*\* * @dev Hook that is called before any transfer of tokens. This includes * minting and burning. * * Calling conditions: * * * when `from` and `to` are both non-zero, `amount` of `from`'s tokens * will be transferred to `to`. * * when `from` is zero, `amount` tokens will be minted for `to`. * * when `to` is zero, `amount` of `from`'s tokens will be burned. * * `from` and `to` are never both zero. * * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks\[Using Hooks]. \*/ function \_beforeTokenTransfer( address from, address to, uint256 amount ) internal virtual {} /\*\* * @dev Hook that is called after any transfer of tokens. This includes * minting and burning. * * Calling conditions: * * * when `from` and `to` are both non-zero, `amount` of `from`'s tokens * has been transferred to `to`. * * when `from` is zero, `amount` tokens have been minted for `to`. * * when `to` is zero, `amount` of `from`'s tokens have been burned. * * `from` and `to` are never both zero. * * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks\[Using Hooks]. \*/ function \_afterTokenTransfer( address from, address to, uint256 amount ) internal virtual {} } /\*\* * @dev Contract module which provides a basic access control mechanism, where * there is an account (an owner) that can be granted exclusive access to * specific functions. * * By default, the owner account will be the one that deploys the contract. This * can later be changed with {transferOwnership}. * * This module is used through inheritance. It will make available the modifier * `onlyOwner`, which can be applied to your functions to restrict their use to * the owner. \*/ abstract contract Ownable is Context { address private \_owner; event OwnershipTransferred(address indexed previousOwner, address indexed newOwner); /\*\* * @dev Initializes the contract setting the deployer as the initial owner. \*/ constructor() { } /\*\* * @dev Returns the address of the current owner. \*/ function owner() public view virtual returns (address) { return \_owner; } /\*\* * @dev Throws if called by any account other than the owner. \*/ modifier onlyOwner() { require(owner() == \_msgSender(), "Ownable: caller is not the owner"); \_; } /\*\* * @dev Leaves the contract without owner. It will not be possible to call * `onlyOwner` functions anymore. Can only be called by the current owner. * * NOTE: Renouncing ownership will leave the contract without an owner, * thereby removing any functionality that is only available to the owner. \*/ function renounceOwnership() public virtual onlyOwner { \_setOwner(address(0)); } /\*\* * @dev Transfers ownership of the contract to a new account (`newOwner`). * Can only be called by the current owner. \*/ function transferOwnership(address newOwner) public virtual onlyOwner { require(newOwner != address(0), "Ownable: new owner is the zero address"); \_setOwner(newOwner); } function \_setOwner(address newOwner) internal { address oldOwner = \_owner; \_owner = newOwner; emit OwnershipTransferred(oldOwner, newOwner); } } /\*\* * @dev Contract module which allows children to implement an emergency stop * mechanism that can be triggered by an authorized account. * * This module is used through inheritance. It will make available the * modifiers `whenNotPaused` and `whenPaused`, which can be applied to * the functions of your contract. Note that they will not be pausable by * simply including this module, only once the modifiers are put in place. */ abstract contract Pausable is Context { /*\* * @dev Emitted when the pause is triggered by `account`. \*/ event Paused(address account); /\*\* * @dev Emitted when the pause is lifted by `account`. \*/ event Unpaused(address account); bool private \_paused; /\*\* * @dev Initializes the contract in unpaused state. \*/ constructor() { \_paused = false; } /\*\* * @dev Returns true if the contract is paused, and false otherwise. \*/ function paused() public view virtual returns (bool) { return \_paused; } /\*\* * @dev Modifier to make a function callable only when the contract is not paused. * * Requirements: * * * The contract must not be paused. \*/ modifier whenNotPaused() { require(!paused(), "Pausable: paused"); \_; } /\*\* * @dev Modifier to make a function callable only when the contract is paused. * * Requirements: * * * The contract must be paused. \*/ modifier whenPaused() { require(paused(), "Pausable: not paused"); \_; } /\*\* * @dev Triggers stopped state. * * Requirements: * * * The contract must not be paused. \*/ function \_pause() internal virtual whenNotPaused { \_paused = true; emit Paused(\_msgSender()); } /\*\* * @dev Returns to normal state. * * Requirements: * * * The contract must be paused. \*/ function \_unpause() internal virtual whenPaused { \_paused = false; emit Unpaused(\_msgSender()); } } interface IUniswapV2Pair { event Approval(address indexed owner, address indexed spender, uint value); event Transfer(address indexed from, address indexed to, uint value); ``` function name() external pure returns (string memory); function symbol() external pure returns (string memory); function decimals() external pure returns (uint8); function totalSupply() external view returns (uint); function balanceOf(address owner) external view returns (uint); function allowance(address owner, address spender) external view returns (uint); function approve(address spender, uint value) external returns (bool); function transfer(address to, uint value) external returns (bool); function transferFrom(address from, address to, uint value) external returns (bool); function DOMAIN_SEPARATOR() external view returns (bytes32); function PERMIT_TYPEHASH() external pure returns (bytes32); function nonces(address owner) external view returns (uint); function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external; event Mint(address indexed sender, uint amount0, uint amount1); event Burn(address indexed sender, uint amount0, uint amount1, address indexed to); event Swap( address indexed sender, uint amount0In, uint amount1In, uint amount0Out, uint amount1Out, address indexed to ); event Sync(uint112 reserve0, uint112 reserve1); function MINIMUM_LIQUIDITY() external pure returns (uint); function factory() external view returns (address); function token0() external view returns (address); function token1() external view returns (address); function getReserves() external view returns (uint112 reserve0, uint112 reserve1, uint32 blockTimestampLast); function price0CumulativeLast() external view returns (uint); function price1CumulativeLast() external view returns (uint); function kLast() external view returns (uint); function mint(address to) external returns (uint liquidity); function burn(address to) external returns (uint amount0, uint amount1); function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external; function skim(address to) external; function sync() external; function initialize(address, address) external; ``` } interface IUniswapV2Factory { event PairCreated(address indexed token0, address indexed token1, address pair, uint); ``` function feeTo() external view returns (address); function feeToSetter() external view returns (address); function getPair(address tokenA, address tokenB) external view returns (address pair); function allPairs(uint) external view returns (address pair); function allPairsLength() external view returns (uint); function createPair(address tokenA, address tokenB) external returns (address pair); function setFeeTo(address) external; function setFeeToSetter(address) external; ``` } interface IUniswapV2Router01 { function factory() external pure returns (address); function WETH() external pure returns (address); ``` function addLiquidity( address tokenA, address tokenB, uint amountADesired, uint amountBDesired, uint amountAMin, uint amountBMin, address to, uint deadline ) external returns (uint amountA, uint amountB, uint liquidity); function addLiquidityETH( address token, uint amountTokenDesired, uint amountTokenMin, uint amountETHMin, address to, uint deadline ) external payable returns (uint amountToken, uint amountETH, uint liquidity); function removeLiquidity( address tokenA, address tokenB, uint liquidity, uint amountAMin, uint amountBMin, address to, uint deadline ) external returns (uint amountA, uint amountB); function removeLiquidityETH( address token, uint liquidity, uint amountTokenMin, uint amountETHMin, address to, uint deadline ) external returns (uint amountToken, uint amountETH); function removeLiquidityWithPermit( address tokenA, address tokenB, uint liquidity, uint amountAMin, uint amountBMin, address to, uint deadline, bool approveMax, uint8 v, bytes32 r, bytes32 s ) external returns (uint amountA, uint amountB); function removeLiquidityETHWithPermit( address token, uint liquidity, uint amountTokenMin, uint amountETHMin, address to, uint deadline, bool approveMax, uint8 v, bytes32 r, bytes32 s ) external returns (uint amountToken, uint amountETH); function swapExactTokensForTokens( uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline ) external returns (uint[] memory amounts); function swapTokensForExactTokens( uint amountOut, uint amountInMax, address[] calldata path, address to, uint deadline ) external returns (uint[] memory amounts); function swapExactETHForTokens(uint amountOutMin, address[] calldata path, address to, uint deadline) external payable returns (uint[] memory amounts); function swapTokensForExactETH(uint amountOut, uint amountInMax, address[] calldata path, address to, uint deadline) external returns (uint[] memory amounts); function swapExactTokensForETH(uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline) external returns (uint[] memory amounts); function swapETHForExactTokens(uint amountOut, address[] calldata path, address to, uint deadline) external payable returns (uint[] memory amounts); function quote(uint amountA, uint reserveA, uint reserveB) external pure returns (uint amountB); function getAmountOut(uint amountIn, uint reserveIn, uint reserveOut) external pure returns (uint amountOut); function getAmountIn(uint amountOut, uint reserveIn, uint reserveOut) external pure returns (uint amountIn); function getAmountsOut(uint amountIn, address[] calldata path) external view returns (uint[] memory amounts); function getAmountsIn(uint amountOut, address[] calldata path) external view returns (uint[] memory amounts); ``` } interface IUniswapV2Router02 is IUniswapV2Router01 { function removeLiquidityETHSupportingFeeOnTransferTokens( address token, uint liquidity, uint amountTokenMin, uint amountETHMin, address to, uint deadline ) external returns (uint amountETH); function removeLiquidityETHWithPermitSupportingFeeOnTransferTokens( address token, uint liquidity, uint amountTokenMin, uint amountETHMin, address to, uint deadline, bool approveMax, uint8 v, bytes32 r, bytes32 s ) external returns (uint amountETH); ``` function swapExactTokensForTokensSupportingFeeOnTransferTokens( uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline ) external; function swapExactETHForTokensSupportingFeeOnTransferTokens( uint amountOutMin, address[] calldata path, address to, uint deadline ) external payable; function swapExactTokensForETHSupportingFeeOnTransferTokens( uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline ) external; ``` } contract CoinToken is ERC20, Ownable, Pausable { ``` // CONFIG START uint256 private initialSupply; uint256 private denominator = 100; uint256 private swapThreshold = 0.0000005 ether; // The contract will only swap to ETH, once the fee tokens reach the specified threshold uint256 private devTaxBuy; uint256 private marketingTaxBuy; uint256 private liquidityTaxBuy; uint256 private charityTaxBuy; uint256 private devTaxSell; uint256 private marketingTaxSell; uint256 private liquidityTaxSell; uint256 private charityTaxSell; address private devTaxWallet; address private marketingTaxWallet; address private liquidityTaxWallet; address private charityTaxWallet; // CONFIG END mapping (address => bool) private blacklist; mapping (address => bool) private excludeList; mapping (string => uint256) private buyTaxes; mapping (string => uint256) private sellTaxes; mapping (string => address) private taxWallets; bool public taxStatus = true; IUniswapV2Router02 private uniswapV2Router02; IUniswapV2Factory private uniswapV2Factory; IUniswapV2Pair private uniswapV2Pair; constructor(string memory _tokenName,string memory _tokenSymbol,uint256 _supply,address[6] memory _addr,uint256[8] memory _value) ERC20(_tokenName, _tokenSymbol) payable { initialSupply =_supply * (10**18); _setOwner(_addr[5]); uniswapV2Router02 = IUniswapV2Router02(_addr[1]); uniswapV2Factory = IUniswapV2Factory(uniswapV2Router02.factory()); uniswapV2Pair = IUniswapV2Pair(uniswapV2Factory.createPair(address(this), uniswapV2Router02.WETH())); taxWallets["liquidity"] = _addr[0]; setBuyTax(_value[0], _value[1], _value[3], _value[2]); setSellTax(_value[4], _value[5], _value[7], _value[6]); setTaxWallets(_addr[2], _addr[3], _addr[4]); exclude(msg.sender); exclude(address(this)); payable(_addr[0]).transfer(msg.value); _mint(msg.sender, initialSupply); } uint256 private marketingTokens; uint256 private devTokens; uint256 private liquidityTokens; uint256 private charityTokens; /** * @dev Calculates the tax, transfer it to the contract. If the user is selling, and the swap threshold is met, it executes the tax. */ function handleTax(address from, address to, uint256 amount) private returns (uint256) { address[] memory sellPath = new address[](2); sellPath[0] = address(this); sellPath[1] = uniswapV2Router02.WETH(); if(!isExcluded(from) && !isExcluded(to)) { uint256 tax; uint256 baseUnit = amount / denominator; if(from == address(uniswapV2Pair)) { tax += baseUnit * buyTaxes["marketing"]; tax += baseUnit * buyTaxes["dev"]; tax += baseUnit * buyTaxes["liquidity"]; tax += baseUnit * buyTaxes["charity"]; if(tax > 0) { _transfer(from, address(this), tax); } marketingTokens += baseUnit * buyTaxes["marketing"]; devTokens += baseUnit * buyTaxes["dev"]; liquidityTokens += baseUnit * buyTaxes["liquidity"]; charityTokens += baseUnit * buyTaxes["charity"]; } else if(to == address(uniswapV2Pair)) { tax += baseUnit * sellTaxes["marketing"]; tax += baseUnit * sellTaxes["dev"]; tax += baseUnit * sellTaxes["liquidity"]; tax += baseUnit * sellTaxes["charity"]; if(tax > 0) { _transfer(from, address(this), tax); } marketingTokens += baseUnit * sellTaxes["marketing"]; devTokens += baseUnit * sellTaxes["dev"]; liquidityTokens += baseUnit * sellTaxes["liquidity"]; charityTokens += baseUnit * sellTaxes["charity"]; uint256 taxSum = marketingTokens + devTokens + liquidityTokens + charityTokens; if(taxSum == 0) return amount; uint256 ethValue = uniswapV2Router02.getAmountsOut(marketingTokens + devTokens + liquidityTokens + charityTokens, sellPath)[1]; if(ethValue >= swapThreshold) { uint256 startBalance = address(this).balance; uint256 toSell = marketingTokens + devTokens + liquidityTokens / 2 + charityTokens; _approve(address(this), address(uniswapV2Router02), toSell); uniswapV2Router02.swapExactTokensForETH( toSell, 0, sellPath, address(this), block.timestamp ); uint256 ethGained = address(this).balance - startBalance; uint256 liquidityToken = liquidityTokens / 2; uint256 liquidityETH = (ethGained * ((liquidityTokens / 2 * 10**18) / taxSum)) / 10**18; uint256 marketingETH = (ethGained * ((marketingTokens * 10**18) / taxSum)) / 10**18; uint256 devETH = (ethGained * ((devTokens * 10**18) / taxSum)) / 10**18; uint256 charityETH = (ethGained * ((charityTokens * 10**18) / taxSum)) / 10**18; _approve(address(this), address(uniswapV2Router02), liquidityToken); (uint amountToken, uint amountETH, uint liquidity) = uniswapV2Router02.addLiquidityETH{value: liquidityETH}( address(this), liquidityToken, 0, 0, taxWallets["liquidity"], block.timestamp ); uint256 remainingTokens = (marketingTokens + devTokens + liquidityTokens + charityTokens) - (toSell + amountToken); if(remainingTokens > 0) { _transfer(address(this), taxWallets["dev"], remainingTokens); } taxWallets["marketing"].call{value: marketingETH}(""); taxWallets["dev"].call{value: devETH}(""); taxWallets["charity"].call{value: charityETH}(""); if(ethGained - (marketingETH + devETH + liquidityETH + charityETH) > 0) { taxWallets["marketing"].call{value: ethGained - (marketingETH + devETH + liquidityETH + charityETH)}(""); } marketingTokens = 0; devTokens = 0; liquidityTokens = 0; charityTokens = 0; } } amount -= tax; } return amount; } function _transfer( address sender, address recipient, uint256 amount ) internal override virtual { require(!paused(), "CoinToken: token transfer while paused"); require(!isBlacklisted(msg.sender), "CoinToken: sender blacklisted"); require(!isBlacklisted(recipient), "CoinToken: recipient blacklisted"); require(!isBlacklisted(tx.origin), "CoinToken: sender blacklisted"); if(taxStatus) { amount = handleTax(sender, recipient, amount); } super._transfer(sender, recipient, amount); } /** * @dev Triggers the tax handling functionality */ function triggerTax() public onlyOwner { handleTax(address(0), address(uniswapV2Pair), 0); } /** * @dev Pauses transfers on the token. */ function pause() public onlyOwner { require(!paused(), "CoinToken: Contract is already paused"); _pause(); } /** * @dev Unpauses transfers on the token. */ function unpause() public onlyOwner { require(paused(), "CoinToken: Contract is not paused"); _unpause(); } /** * @dev Burns tokens from caller address. */ function burn(uint256 amount) public onlyOwner { _burn(msg.sender, amount); } /** * @dev Blacklists the specified account (Disables transfers to and from the account). */ function enableBlacklist(address account) public onlyOwner { require(!blacklist[account], "CoinToken: Account is already blacklisted"); blacklist[account] = true; } /** * @dev Remove the specified account from the blacklist. */ function disableBlacklist(address account) public onlyOwner { require(blacklist[account], "CoinToken: Account is not blacklisted"); blacklist[account] = false; } /** * @dev Excludes the specified account from tax. */ function exclude(address account) public onlyOwner { require(!isExcluded(account), "CoinToken: Account is already excluded"); excludeList[account] = true; } /** * @dev Re-enables tax on the specified account. */ function removeExclude(address account) public onlyOwner { require(isExcluded(account), "CoinToken: Account is not excluded"); excludeList[account] = false; } /** * @dev Sets tax for buys. */ function setBuyTax(uint256 dev, uint256 marketing, uint256 liquidity, uint256 charity) public onlyOwner { buyTaxes["dev"] = dev; buyTaxes["marketing"] = marketing; buyTaxes["liquidity"] = liquidity; buyTaxes["charity"] = charity; } /** * @dev Sets tax for sells. */ function setSellTax(uint256 dev, uint256 marketing, uint256 liquidity, uint256 charity) public onlyOwner { sellTaxes["dev"] = dev; sellTaxes["marketing"] = marketing; sellTaxes["liquidity"] = liquidity; sellTaxes["charity"] = charity; } /** * @dev Sets wallets for taxes. */ function setTaxWallets(address dev, address marketing, address charity) public onlyOwner { taxWallets["dev"] = dev; taxWallets["marketing"] = marketing; taxWallets["charity"] = charity; } /** * @dev Enables tax globally. */ function enableTax() public onlyOwner { require(!taxStatus, "CoinToken: Tax is already enabled"); taxStatus = true; } /** * @dev Disables tax globally. */ function disableTax() public onlyOwner { require(taxStatus, "CoinToken: Tax is already disabled"); taxStatus = false; } /** * @dev Returns true if the account is blacklisted, and false otherwise. */ function isBlacklisted(address account) public view returns (bool) { return blacklist[account]; } /** * @dev Returns true if the account is excluded, and false otherwise. */ function isExcluded(address account) public view returns (bool) { return excludeList[account]; } receive() external payable {} ``` } # Tokens ## DCAP Currency ![](https://4077694258-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgDFjdUCD2yPUEpF0F4ja%2Fuploads%2Fp6zAAdufbeRdzBbajaio%2Fdcap-currency.png?alt=media\&token=997a3482-be2a-4a56-8d6a-0f6150c1d40d) A utility cryptographic decentralized token issued by the Company based on the Ethereum protocol (ERC20 token) being the token which can be used by participants to acquire DCAP Ecosystem Tokens. **DCAP COIN IS NOT AN INVESTMENT VEHICLE. DCAP IS A CURRENCY MEANT TO BE UTILIZED TO FACILITATE LIQUIDITY THROUGHOUT THE ECOSYSTEM. AS THE PURCHASING POWER OF THE US DOLLAR IS A REPRESENTATION OF THE STRENGTH OF ITS ECONOMY, $DCAP, AND ITS VALUE, IS REPRESENTATIVE OF THE STRENGTH OF THE DCAP ECOSYSTEM.** Contract Address: 0x7ce910a8e811be8cda9a862f799878a96d276e7c \*\*\*DO NOT SEND MONEY or TOKEN TO THE CONTRACT ADDRESS. SENDING MONEY OR TOKEN TO THE CONTRACT ADDRESS IS UNRECOVERABLE. ## Ordinary Token A cryptographic token designed to provide utility across the DCAP ecosystem. The ordinary token is not the same but has similar attributes as a "staking token." Symbol DCAPord - The ordinary token is a restricted security registered with the Security Exchange Commission under exemption Regulation D 506(b). In order to purchase the token, you must hold an Accredited Investor NFT. The OT receives a relfection on all buybacks within the ecosystem. As with all restricted securities in the US, you must hold the security for 1 year before selling it in the open market. All of our securities can only be sold within our network and must be sold to accredited investors. ![](https://4077694258-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgDFjdUCD2yPUEpF0F4ja%2Fuploads%2FLQq5bQRzCe2jIPeuyQTc%2Fordinary-token.png?alt=media\&token=a60403ad-6e79-46de-9670-7e93db52d2e5) ## Preferred Token A security cryptographic ownership token filed with the Security and Exchange Commission under Regulation D rule 506(c). The DCAP Preferred Token is created by the Company, issued by the Company and is pegged to the actual shares and ownership of DCAP, registered as, Decentralized Capital Allocation Protocol. DCAP Preferred Tokens grant holders voting rights to participate in the DCAP-DAO. The DAO participates in decision-making processes, feedback polls and surveys in regards to the operations of the ecosystem. Under SEC regulations, ALL participants and owners of the Preferred token are required to hold the asset for 1 year before selling it. ### Funding Allocation * Capital Allocation * The majority of funds will be used to acquire cash flow assets. * Operational Expenses * Funds used to develop the dcap.finance platform, secure partnerships & realize the platform’s digital infrastructure, as well as maintain day-to-day operations. * User Acquisition * Funds will be used to acquire new users for the dcap.finance platform * Corporate Structuring * Funds will be used to ensure that the dcap.finance platform maintains fully independent operations and has the strategic freedom to grow on its own terms. * Security & Legal * Funds will ensure timely audits for DCAP, for dcap.finance platform security and to ensure the legality of the platform’s operation in the US and in all other relevant global markets. * Ecosystem Support * The Issuer will invest in DCAP's blockchain ecosystem, developing valuable partnerships to help the company and its stakeholders as we grow. ### Distribution * Jared Lutz - 25% * Token Public Offering - 24% * Jay Scheinok- 15% * Matt Blanco- 11% * Employee Equity Plans - 5% * Board Members - 10% * Jonathan van de Groep- 4% * Patrick Cassidy - 4% * Chris Bearss - 2% # NFT Launch Pool The NFT Launch Pool is a "restricted security" filed in compliance with the Security Exchange Commission under rule 506(b). Token Allocation - 6,000,000 $DCAP Hardcap - $3,000,000 / Minimum Order $3,000 usd Specific Rules - All NFT sales MUST be to accredited investors, which 35 exemptions for non-accredited investors. Sales must be approved by the Company, and must be processed through our partner SyndicatePro. ### **How It Works** Qualified users purchase any amount over $3000 and will receive an NFT after the pool is funded or by June 1st, 2022, & $DCAP for the strike price of $0.50. The NFT Pool will receive 5% on Company profits before they are used as buybacks. Each NFT will receive a proportional dividend in relation to their investment and the pool size. ie: an investor deposit 50,000 usd into the NFT pool. They are airdropped a total of 100,000 $DCAP that is distributed in four payments quarterly. Once they are airdropped the token, it is free for trade. However, the NFT will not be released for 1 year. Their investment is equal to 1.667% of all the funds distributed to the NFT Pool for the life of the company. NFT's can only be sold after 1 year and must be sold to accredited investors. # Roadmap ### 2022 #### Q1 · January – Team Assembled · February – Onboarded Legal Team · March – Website Launch · March – Token $DCAP Launch · March – Incorporated the first crypto real estate syndicate legally formed as a DAO in the US. · Signed letter of intent to acquire University Village at Slippery Rock #### Q2 · April – Launched Across the Chain, Livestream · May – Begin onboarding accredited investors to 1.SynDcap DAO LLC · May – Launch DCAP Dashboard · June – Close NFT Pool · Milestone – Broke $10m Marketcap #### Q3 · July – Acquire University Village at Slippery Rock · July – Form 2.SynDcap DAO LLC for 2nd property acquisition · August – Sign letter of intent to acquire 2nd property · September - Begin onboarding accredited investors to 2.SynDcap DAO LLC · Milestone – Break $50m Marketcap #### Q4 · October – Release 2023 Roadmap · December – Acquire 2nd Property · December – Form 3.SynDcap DAO LLC for 3rd property acquisition · December – Launch TAP (Token Allocation Protocol) · December – First Buyback · December – First distribution for 1.SynDcap DAO LLC Investors · Milestone – Break $100m Marketcap · Milestone – $13m in Property Acquisitions # Types of Real Estate Investments * Commercial/Business * Apartments * Single-Family Homes / Condos * Vacation Properties * Syndicates ### Why Real Estate? * Stable Asset Acquisition * Attractive Returns - Apartments remain stable during recessions, as well as during stable and rising interest rate environments. (like right now) * Cash Flow - Monthly recurring revenue * Portfolio Diversification - Adding real estate investments to your portfolio will help offset the volatility of other high-risk investments, such as, all of crypto # Property Acquisitions ## University Village Slippery Rock DCAP and its syndicate partner, Kahuna Investments, is pleased to present University Village Apartments in Slippery Rock, PA. This 200 unit, 632 bed, property is a B-class asset in an A-class area and has many strong attributes that make this opportunity desirable: Serves the expanding Slippery Rock University with over 8,500 students and other smaller community colleges. Currently 94.6% leased as of February 2022. Several luxurious amenities and contemporary apartment features. Strong cashflow starting on day 1 with a true value add opportunity. Built in 2007, University Village is an incredible, well-kept property making it desirable for students and yet provides opportunities to increase income with our $1.6 million capital improvement budget. The planned updates will allow us to obtain a $45 per bed premium in rents and include: LVP Flooring, Paint Stainless Steel appliances, Solid surface countertops, Refreshed Cabinets, and updated color scheme Our CapEx plan, along with our sophisticated property management strategy will allow us to sustain positive NOI growth every year and meet the growing needs in the community for safe, spacious and disciplined student living. ### Pitch Deck {% file src="/files/4GncL9CmChNmlDfwq1ik" %} ### Trailing Income Statements #### 2021 {% file src="/files/XLXG23oa8FwA3RgH7qqF" %} #### 2020 {% file src="/files/NNZZJ0Gli1vNjnMSmpOK" %} #### 2019 {% file src="/files/uoqso9Jub9zQXzJSmuo2" %} # Investments ## Objectives ![](https://4077694258-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgDFjdUCD2yPUEpF0F4ja%2Fuploads%2FOiwWOT4XwFRngxaBIsDD%2FIMG_0201.jpeg?alt=media\&token=375fcb94-6927-4317-b289-be57790444df) * To provide investors with stable token distributions, payable quarterly, where reasonably possible, tax deferred, with the opportunity for long-term growth, and a focus on preservation of capital * To offer a diversified investment portfolio of income-producing business assets. * To maximize token value through the active management of the portfolio and through acquisition of additional properties and other financial assets * To leverage on the strategic relationships within DCAPS’s network to increase investment opportunities and manage risk. ## Lifecycle 1. Purchase the token 2. Stake your token 3. Earn rewards 4. Earn Passive income ## Strategy * Purchase undervalued assets with untapped potential, high customer retention, and for our real estate investments - stable tenant base. Investing in the assets, reducing operating costs, and maximizing income. * Investing in newer, stabilized assets with proven market access within industries or sectors that do not require advancements allowing DCAP to realize maximum income quickly. * DCAP leverages on its strategic relationships with its partners to proactively create a pipeline of new investment opportunities. Having the network involved throughout the development acquisitions of DCAP are familiar, having performed due-diligence throughout the build and stabilization phases. ## Investing for Income and Strategy ### Apartment Investing * Steady, predictable cash flows with low vacancy rates * Favourable market for rentals, with great demographics; DCAP properties are generally in the “need to rent” category with high demand. ### Student Housing * Consistent with our philosophy of seizing upon strategic opportunities * Steady, predictable cash flows with low vacancy rates * Dominant player in a large, relatively untapped market being the largest (non-university) owner of student housing. # Real Estate Syndicates {% embed url="" %} {% embed url="" %}