diff --git a/src/assets/images/Broadcast-Debt-Order.png b/src/assets/images/Broadcast-Debt-Order.png new file mode 100644 index 0000000..49c36db Binary files /dev/null and b/src/assets/images/Broadcast-Debt-Order.png differ diff --git a/src/components/Main/Architecture/Architecture.tsx b/src/components/Main/Architecture/Architecture.tsx new file mode 100644 index 0000000..bf3d6be --- /dev/null +++ b/src/components/Main/Architecture/Architecture.tsx @@ -0,0 +1,358 @@ +// External libraries +import * as React from "react"; + +// Semantic-UI components +import { Container, Header as SemanticHeader } from "semantic-ui-react"; + +// Components +import ContentAnchor from "../ContentAnchor"; + +/** + * A component that renders an overview of architecture to the documentation. + */ +export default class Architecture extends React.Component<{}, {}> { + public render() { + return ( + + + + Architecture Overview + + +
+

Dharma Protocol defines a procedure for issuing, funding, administering, + and trading debt assets using a set of smart contracts.

+ +

In the broadcast debt order model, a debtor will sign a debt order + specifying the parameters of a debt they want funded. An underwriter will + commit a risk rating to this order, and post it on a relayer's order book. A + creditor will fund the debt by filling the debt order. The Debt Kernel contract will issue a + tradable debt token (ERC721) to the creditor, and + store the details of the debt agreement in the Debt Registry contract. The + debt kernel will transfer funds from the creditor to the borrower, and pay + relevant fees to the underwriter and relayer for their services.

+ +

Note: The Debt Kernel makes all transfers via a Token Transfer Proxy contract, so + that the creditor and debtor would not need to update their token + permissions in the case of a contract upgrade.

+ +

Filling a Broadcast Debt Order

+ +
+ +
+ + + + DebtKernel.sol + + + +

The debt kernel is a smart contract that contains business logic + associated with filling a debt order. This includes determining whether a + debt order is valid and consensual, minting a non-fungible + debt token and transferring it to the creditor, and transferring fees to the + appropriate relayer and underwriter.

+ +

The debt kernel also handles logic for cancelling an signed debt + order, so that a debtor can prevent a counterparty from filling it in the + future. Similarly, underwriters and relayers can use the debt kernel to + cancel an issuance that they have signed from being used in a debt order in + the future.

+
+ +
+ + + + DebtRegistry.sol + + + +

The debt registry contains detailed information about each debt agreement, + including:

+
    +
  • The beneficiary of repayments
    • +
  • The address of the associated terms contract and the relevant + parameters for that contract +
    • +
  • The address of the underwriter
    • +
  • The underwriter's risk rating
    • +
  • The address of debt kernel contract used (referred to as its version) +
    • +
  • The block timestamp at issuance
    • +
+ +

The debt registry also contains a mapping of each debtor to the list of debt + agreements.

+
+ +
+ + + + TokenTransferProxy.sol + + + +

This contract exists in order to transfer tokens (including principal, fees, + repayments, and collateral), on behalf of core Dharma Protocol contracts + such as the Debt Kernel. By decoupling contracts from transfers, the + core contracts can be upgraded without requiring users to grant new transfer + approvals to the new contract's address.

+
+ +
+ + Upgrade Procedure + +

The Ethereum community is rapidly iterating on multiple layers of its + technology + stack, and hence protocols need to accommodate upgrades. Once a contract has + been deployed to the Ethereum blockchain, however, its internal logic cannot + be + changed, and so any changes to protocol logic requires completely new + contracts + to be deployed. Each time a new contract is deployed, other contracts and + accounts (including the protocol’s users) that make transfers through that + contract need to grant transfer approval - I.E. "opt-in" to using + that + contract.

+

To avoid disruptions to user experience during upgrades, Dharma Protocol uses + a "proxy" mechanism for token transfers. Specifically, a user + authorizes a simple proxy contract to make transfers with specified amounts + from + their account, and core Dharma Protocol contracts are authorized to invoke + those + transfers. When a core contract needs to be replaced, the old contract’s + proxy + permissions will be revoked, and a newly deployed contract will be + authorized to + make transfers through the proxy. However, this change will only go into + effect + if at least three of the five signatories in the Dharma Protocol multi-signature wallet agree to the + change, and a “timelock” period of seven days has passed since the change + was + submitted.

+

The timelock is imposed to allow the Dharma community to view, contest, or + opt-out of any such changes if they do not agree that they are appropriate. + At + no time can the Dharma Protocol team make any changes to the logic of the + protocol within the timelock period, except to{" "} + pause + the protocol in the case of an emergency. Proposed changes are + broadcast + as events to the public blockchain at the time of proposal, before the + timelock + begins.

+ + +

Disaster Recovery

+

The Dharma Protocol contracts have tested extensively, and independently + audited + and reviewed by three external auditors (Zeppelin, ZK Labs, and Trail of + Bits) + Even so, it is possible that vulnerabilities may surface in the protocol. + The + team has implemented a way to pause the procotcol in the case of + emergencies, to + prevent a situation where a hacker is able to exploit a known vulnerability. + The + signatories of Dharma’s multi-signature wallet, collectively are able to + pause + any the following Dharma Protocol contracts:

+
    +

  • DebtKernel

    +
    • +

  • DebtRegistry

    +
    • +

  • Collateralizer

    +
    • +

  • RepaymentRouter

    +
    • +
+

The pause operation is the only function that the Dharma Protocol + can + invoke + immediately - all other functions require a timelock of seven days to elapse + before taking effect. Hence, once a fix has been made for the vulnerability, + the + protocol can only be unpause again after seven days have passed. + This + allows + Dharma community members to view and contest the fix, and, if necessary, + revoke + transfer allowances.

+ + +

The Effect of + Pausing Contracts on Users

+

The pause operation prevents the core functions in a contract from + further + execution. For example, if the Collateralizer contract is paused, users will + no + longer be able to return and seize collateral assets, or collateralize more + assets using the contract. In the case of the DebtKernel contract, a pause + would + mean that users are no longer allowed to fill debt orders, cancel debt + orders, + or cancel an issuance. The pause function is therefore a way to protect + assets + that might otherwise be at risk in the case of a vulnerability.

+

It is important to note that in the case of open orders, an inability to make + repayments due to a paused RepaymentRouter may result in delinquency.

+

Here is a list of functions that are will be paused, in the case of an + emergency, + for each contract:

+
    +
  • + DebtKernel +
      +
    • fillDebtOrder
      • +
    • cancelDebtOrder
      • +
    • cancelIssuance
      • +
    +
    • +
  • + DebtRegistry +
      +
    • insert
      • +
    • modifyBeneficiary
      • +
    +
    • +
  • + Collateralizer +
      +
    • seizeCollateral
      • +
    • collateralize
      • +
    • returnCollateral
      • +
    +
    • +
  • + RepaymentRouter +
      +
    • repay
      • +
    +
    • +
+ + +

Multisig Management

+

We have deployed a 3-of-5 multi-signature wallet to be the owner of all + deployed + Dharma Protocol contracts. This means that there are five signatories who + can + submit or confirm a transaction as the owner of a Dharma Protocol contract, + and + that any such transaction will only be executed if at least 3 of the + signatories + confirm the transaction. All of the multi-signature wallet transactions, + with + the exception of the pause operation, are subject to a seven-day + timelock + following the majority confirmation.

+ +

Contract Owner Capabilities

+

The owner of the Dharma Protocol contracts, the multi-signature wallet, + cannot + directly control any assets or debt orders on the protocol. Its main + capabilities relate to pausing contracts in the case of an emergency, and + authorizing which contracts may execute functions on other contracts within + the + protocol. For example, the signatories may collectively vote to change which + contracts will be allowed to act as a transfer agent - to transfer funds + using + the transfer proxy. Currently this set of contracts include the + /RepaymentRouter/ (to transfer funds specified as loan repayments), the + /DebtKernel/ (to transfer principal from the creditor to the debtor, and + fees to + the underwriter and relayer), and the /Collateralizer/ (to transfer + collateral + to the Collateralizer contract.) If one of these contracts were to be + upgraded, + a new contract would be deployed and the signatories would vote on granting + that + contract the authorization to act as a transfer agent. If the majority of + the + signatories confirm that authorization, the update will occur following a + seven-day timelock.

+

The following functions are executable by the contract owner:

+
    +
  • + DebtKernel +
      +
    • setDebtToken
      • +
    +
    • +
  • + DebtToken +
      +
    • addAuthorizedMintAgent
      • +
    • revokeMintAgentAuthorization
      • +
    • addAuthorizedTokenURIAgent
      • +
    • revokeTokenURIAuthorization
      • +
    +
    • +
  • + Collateralizer +
      +
    • addAuthorizedCollateralizeAgent
      • +
    • revokeCollateralizeAuthorization
      • +
    +
    • +
  • + DebtRegistry +
      +
    • addAuthorizedInsertAgent
      • +
    • revokeInsertAgentAuthorization
      • +
    • addAuthorizedEditAgent
      • +
    • revokeEditAgentAuthorization
      • +
    +
    • +
  • + TokenRegistry +
      +
    • setTokenAttributes
      • +
    +
    • +
  • + TokenTransferProxy +
      +
    • addAuthorizedTransferAgent
      • +
    • revokeTransferAgentAuthorization
      • +
    +
    • +
+ +

Security Considerations

+

Static Token Address Assumptions

+

Tokens on the Ethereum blockchain are upgradeable, in which case the address + or + symbol for that token may change. When token upgrades occur for supported + tokens, Dharma Protocol contracts that store those token attributes, such as + the + TokenRegistry, will need to be updated.

+

The TokenRegistry in Dharma Protocol provides a mapping of each supported + token’s + symbol to the address of that token. The Dharma team can update the stored + attributes for any supported token in the registry, including the token’s + address, and add new token symbols to the registry. However, like other + contract + upgrades, these changes invoke the seven-day time-lock. In the case of token + updates, + it is appropriate for the applications that use Dharma Protocol (e.g. Dharma + Plex), to signal to their users that the token has changed.

+

We have audited the Dharma Protocol and found no further cases where the + assumption has been made that a token’s attributes will remain fixed over + time.

+
+ + ); + } +} diff --git a/src/components/Main/DeployedAddresses/DeployedAddresses.tsx b/src/components/Main/DeployedAddresses/DeployedAddresses.tsx new file mode 100644 index 0000000..97b190f --- /dev/null +++ b/src/components/Main/DeployedAddresses/DeployedAddresses.tsx @@ -0,0 +1,132 @@ +// External libraries +import * as React from "react"; + +// Semantic-UI components +import { Container, Header as SemanticHeader } from "semantic-ui-react"; + +// Components +import ContentAnchor from "../ContentAnchor"; + +/** + * A component that renders an overview of architecture to the documentation. + */ +export default class DeployedAddresses extends React.Component<{}, {}> { + public render() { + return ( + + + Contract Addresses + + +
+ + DebtKernel + +

Mainnet: 

0x8ef1351941d0cd8da09d5a4c74f2d64503031a18

+ +

Kovan: 

0x755e131019e5ab3e213dc269a4020e3e82e06e20

+
+ +
+ + DebtToken + +

Mainnet: 

0xf7b3fc555c458c46d288ffd049ddbfb09f706df7

+ +

Kovan: 

0x12c8615fd55bf6e1f5a298cebdc72e50f838df74

+
+ +
+ + DebtRegistry + +

Mainnet: 

0x4e0f2b97307ad60b741f993c052733acc1ea5811

+ +

Kovan: 

0x9662d6cae0e6914a388cb96c1c161cc4d12c3d7a

+
+ +
+ + TokenTransferProxy + +

Mainnet: 

0x2f40766e91aaee4794d3389ac8dc3a4b8fd7ab3e

+ +

Kovan: 

0x668beab2e4dfec1d8c0a70fb5e52987cb22c2f1a

+
+ +
+ + DharmaMultiSigWallet + +

Mainnet: 

0x9445d5ddc2d8a3663ce8cc9fe74009f99b343cfc

+ +

Kovan: 

0x5e6d80063af17bf22b6828a7a61693ec37881563

+
+ +
+ + RepaymentRouter + +

Mainnet: 

0xc1df9b92645cc3b6733992c692a39c34a86fae5f

+ +

Kovan: 

0x0688659d5e36896da7e5d44ebe3e10aa9d2c9968

+
+ +
+ + TokenRegistry + +

Mainnet: 

0xd79396ab3bfaaa0d9f6d11f95bb641601d93c0a9

+ +

Kovan: 

0x6949948d93f3dbe50ec2fe54815fa33bfa284d35

+
+ +
+ + SimpleInterestTermsContract + +

Mainnet: 

0xb78a7d1c1d03cf9155cc522097cbc679e15cf9a3

+ +

Kovan: 

0x4cad7ad79464628c07227928c851d3bc5ef3da0c

+
+ +
+ + CollateralizedSimpleInterestTermsContract + +

Mainnet: 

0x5de2538838b4eb7fa2dbdea09d642b88546e5f20

+ +

Kovan: 

0x13763cf3eb3b6813fa800d4935725a0504c8eb8f

+
+ +
+ + Collateralizer + +

Mainnet: 

0xecc718386176d714dc9e4e35e177396b291499ee

+ +

Kovan: 

0x4b86bbe375577262cb0b3b7893e3de0d11751dd6

+
+ +
+ + PermissionsLib + +

Mainnet: 

0xba0d793fb316d7a457b758e75a57e22ee14bc188

+ +

Kovan: 

0x0e7e2aace2ed2565777b420fd181b556971a8cb1

+
+ +
+ + ContractRegistry + +

Mainnet: 

0x10512440113cb6cb613be403135876d2e0a42c0b

+ +

Kovan: 

0x506acb19a451cc6e2a5c76e65f6b65840406e5f9

+
+ + ); + } +} diff --git a/src/components/Main/Main.css b/src/components/Main/Main.css index ecf6a28..a720c6c 100644 --- a/src/components/Main/Main.css +++ b/src/components/Main/Main.css @@ -33,3 +33,11 @@ p { .subsection { margin-top: 40px; } + +blockquote { + margin: 0; + margin-bottom: .85em; + padding: 0 15px; + color: #858585; + border-left: 4px solid #e5e5e5; +} \ No newline at end of file diff --git a/src/components/Main/Main.tsx b/src/components/Main/Main.tsx index 40b7ad6..1b002a7 100644 --- a/src/components/Main/Main.tsx +++ b/src/components/Main/Main.tsx @@ -11,11 +11,14 @@ import Section from "./Section/Section"; // Component-specific style import "./Main.css"; -import Contributing from "./Contributing/Contributing"; +import Architecture from "./Architecture/Architecture"; +// import Contributing from "./Contributing/Contributing"; import DebtOrderAPI from "./DebtOrderAPI/DebtOrderAPI"; +import DeployedAddresses from "./DeployedAddresses/DeployedAddresses"; import Interface from "./Interface/Interface"; import Installation from "./Introduction/Installation"; -import Upgrading from "./Upgrading/Upgrading"; +import MainConcepts from "./MainConcepts/MainConcepts"; +// import Upgrading from "./Upgrading/Upgrading"; interface Props { documentation: Documentation; @@ -33,9 +36,18 @@ export default class Main extends React.Component { + + + + + + + + + { // For each section, render a Section component with the relevant data. _.map(documentation.sections, (section) => { @@ -52,11 +64,11 @@ export default class Main extends React.Component { }) } - - + {/**/} + {/**/} - - + {/**/} + {/**/} ); } diff --git a/src/components/Main/MainConcepts/MainConcepts.tsx b/src/components/Main/MainConcepts/MainConcepts.tsx new file mode 100644 index 0000000..901bc87 --- /dev/null +++ b/src/components/Main/MainConcepts/MainConcepts.tsx @@ -0,0 +1,170 @@ +// External libraries +import * as React from "react"; + +// Semantic-UI components +import { Container, Header as SemanticHeader } from "semantic-ui-react"; + +// Components +import ContentAnchor from "../ContentAnchor"; + +/** + * A component that renders main concepts to the documentation. + */ +export default class MainConcepts extends React.Component<{}, {}> { + public render() { + return ( + + + Main Concepts + + +
+ + Debt Order + +

Debt orders are data packets listed by relayers that are the fundamental + primitive of Dharma protocol -- submitting a valid debt order to the Debt + Kernel triggers the issuance of a debt token and its swap with the requested + principal amount. Dharma protocol is agnostic to the means by which + creditors, debtors, underwriters, and relayers communicate and transfer debt + order packets between one another -- A debt order can have up to 3 ECDSA + signatures attached to it -- a debtor's signature, a creditor's signature, + and an underwriter's signature.

+
+ +
+ + Terms Contract + +

We require that any Debt issued via Dharma protocol commit to a smart + contract, referred to as a Terms Contract. The purpose of the Terms Contract + is to provide an immutable and programmatically queryable source-of-truth + revealing the repayment status of the debt. This allows us to empirically + and unambiguously both define the terms repayment scheme in the Debt + Issuance process and evaluate the debt's repayment status during the debt's + lifecycle both on and off-chain.

+
+ +
+ + Debt Token + +

A Dharma Debt Token is a non-fungible token that a creditor receives when + filling a loan. Future repayments on the loan go to the owner of the Debt + Token.

+
+ +
+ + Relayer + +

Relayers in Dharma protocol perform an analogous function to relayers in the + 0x Protocol -- namely, relayers aggregate signed debt order messages and, + for an agreed upon fee, host the messages in a centralized order book and + provide retail investors with the ability to invest in the requested debt + orders by filling the signed debt orders. Note that, similarly to the 0x + relaying mechanism, Dharma Protocol relayers need not hold any agent's + tokens -- they simply provide a mechanism for creditors to browse through + aggregated signed debt order messages, which creditors can use to + trustlessly issue themselves debt tokens in exchange for the requested + principal via client-side contract interactions (this mechanism is specified + later in this paper). The primary differences between relayers in Dharma + protocol and 0x are:

+ +
    +
  1. Dharma protocol relayers are not hosting a secondary market order book, + but rather, an order book containing requests for debts that have yet to + be issued +
    2. +
  2. Dharma protocol relayers provide creditors with signed debt-specific + metadata associated with the debt order messages and their accompanying + underwriter so that they can make informed investment decisions about + the risk profile of a given debt order. +
    3. +
  3. Dharma protocol relayers do not freely allow any anonymous party to + publish signed debt orders on to their order book, and use their + discretion to only accept signed debt orders from known, trusted + underwriters. +
    4. +
+ +
+

Example: Bob wants to build a retail loan investor portal through which + users can invest in a variety of debt assets -- a Kayak for peer-to-peer + loans, if you will. Bob becomes a Dharma protocol relayer by setting up + an online order book, building a retail investment platform, and + allowing investors to browse through debt requests and examine + associated data pertaining to the debtors' credit worthiness and the + identity of the backing underwriters. Since Bob has seen that the + empirical historical performance of Alice's attested assets has been in + line with her predictions and knows that Alice's company is a publicly + trusted and regulated entity, Bob allows Alice to broadcast signed debt + orders onto his order book. When a debt order is filled on his platform, + Bob is paid out a fee stipulated in the signed debt order.

+
+
+ +
+ + Underwriter + +

In traditional debt markets, underwriters are entities that collect fees for + administering the public issuance of debt and pricing borrower default risk + into the asset. In Dharma protocol, this definition is expanded and + formalized. An underwriter is a trusted entity that + collects market-determined fees for performing the following functions: +

+ +
    +
  • Originating a debt order from a borrower
    • +
  • Determining and negotiating the terms of the debt (i.e. term length, + interest, amortization) with the potential debtor +
    • +
  • Cryptographically committing to the likelihood they ascribe to that debt + relationship ending in default +
    • +
  • Administering the debt order's funding by forwarding it to any number of + relayers. +
    • +
  • Servicing the debt -- i.e. doing everything in the underwriter's + reasonable power to ensure timely repayment according to the agreed upon + terms +
    • +
  • In the case of defaults or delinquencies, collecting on collateral (if + debt is secured) or the individual's assets via legal mechanisms and + passing collected proceeds to investors +
    • +
+ +

This is not particularly out of band with what most online lenders do in + their day-to-day underwriting and servicing operations. We foresee Dharma + protocol facilitating an alternative, cheaper route for aspiring online + lending platforms to bootstrap their operations and earn similar margins as + they would in the status quo by becoming an underwriter -- all-the-while + never holding balance sheet risk and avoiding the upfront time and capital + costs associated with raising the requisite debt vehicles from traditional + investors.

+ +
+

Example: Alice has a novel thesis on how to originate, underwrite, and + service loans to aspiring ZCash miners who need significant upfront + capital to buy GPUs on bulk. In lieu of knocking on the doors of + traditional fixed-income investors, Alice decides to become an + underwriter in Dharma protocol. She obtains the necessary lending + licenses, sets up a website advertising lending services for miners, and + drums up hype in the ZCash community for her credit product. When + borrowers come to her site, their creditworthiness is automatically + scored by Alice's proprietary technology and they are presented with the + terms of the loan, as determined by Alice. Upon acceptance of the terms, + Alice cryptographically attests to the borrower's likelihood of default, + forwards the signed debt order to a relayer, and, upon the loan's + funding, collects her desired fee. The entire flow of funds is + transparently auditable on-chain, and Alice's competence in servicing + and collecting on the debt can be empirically determined ex post + facto.

+
+
+ + ); + } +} diff --git a/src/components/Navigation/Navigation.tsx b/src/components/Navigation/Navigation.tsx index 4c8cc0b..282315d 100644 --- a/src/components/Navigation/Navigation.tsx +++ b/src/components/Navigation/Navigation.tsx @@ -6,6 +6,12 @@ import { Accordion, Menu, Sidebar } from "semantic-ui-react"; import "./Navigation.css"; import Classes from "./Classes"; +import ArchitectureContent from "./Sections/ArchitectureContent"; +import BasicContent from "./Sections/BasicContent"; +import DeployedAddresses from "./Sections/DeployedAddresses"; +import FurtherReading from "./Sections/FurtherReading"; +import InstallationContent from "./Sections/InstallationContent"; +import MainConceptsContent from "./Sections/MainConceptsContent"; interface Props { documentation: Documentation; @@ -56,54 +62,6 @@ export default class Navigation extends React.Component { ), }); - const InstallationContent = ( - - ); - - const BasicContent = ( - - ); - const APIReferenceContent = (
@@ -111,9 +69,13 @@ export default class Navigation extends React.Component { ); const rootPanels = [ - { title: "Installation", content: { content: InstallationContent, key: "content-1" } }, - { title: "Introduction", content: { content: BasicContent, key: "content-2" } }, - { title: "API Reference", content: { content: APIReferenceContent, key: "content-3" } }, + { title: "Installation", content: { content: , key: "content-1" } }, + { title: "Main Concepts", content: { content: , key: "content-2" } }, + { title: "Using DharmaJS", content: { content: , key: "content-3" } }, + { title: "Architecture Overview", content: { content: , key: "content-4" } }, + { title: "Contract Addresses", content: { content: , key: "content-5" } }, + { title: "API Reference", content: { content: APIReferenceContent, key: "content-6" } }, + { title: "Further Reading", content: { content: , key: "content-7" } }, ]; return ( diff --git a/src/components/Navigation/Sections/ArchitectureContent.tsx b/src/components/Navigation/Sections/ArchitectureContent.tsx new file mode 100644 index 0000000..a12a85f --- /dev/null +++ b/src/components/Navigation/Sections/ArchitectureContent.tsx @@ -0,0 +1,33 @@ +// External libraries +import * as React from "react"; + +// Semantic-UI components +import { Menu } from "semantic-ui-react"; + +export default class ArchitectureContent extends React.Component<{}, {}> { + public render() { + return ( + + ); + } +} diff --git a/src/components/Navigation/Sections/BasicContent.tsx b/src/components/Navigation/Sections/BasicContent.tsx new file mode 100644 index 0000000..ea2ccd8 --- /dev/null +++ b/src/components/Navigation/Sections/BasicContent.tsx @@ -0,0 +1,41 @@ +// External libraries +import * as React from "react"; + +// Semantic-UI components +import { Menu } from "semantic-ui-react"; + +export default class BasicContent extends React.Component<{}, {}> { + public render() { + return ( + + ); + } +} diff --git a/src/components/Navigation/Sections/DeployedAddresses.tsx b/src/components/Navigation/Sections/DeployedAddresses.tsx new file mode 100644 index 0000000..d922c55 --- /dev/null +++ b/src/components/Navigation/Sections/DeployedAddresses.tsx @@ -0,0 +1,62 @@ +// External libraries +import * as React from "react"; + +// Semantic-UI components +import { Menu } from "semantic-ui-react"; + +export default class DeployedAddresses extends React.Component<{}, {}> { + public render() { + return ( + + ); + } +} diff --git a/src/components/Navigation/Sections/FurtherReading.tsx b/src/components/Navigation/Sections/FurtherReading.tsx new file mode 100644 index 0000000..6bb7809 --- /dev/null +++ b/src/components/Navigation/Sections/FurtherReading.tsx @@ -0,0 +1,17 @@ +// External libraries +import * as React from "react"; + +// Semantic-UI components +import { Menu } from "semantic-ui-react"; + +export default class FurtherReading extends React.Component<{}, {}> { + public render() { + return ( +
+ + Whitepaper + +
+ ); + } +} diff --git a/src/components/Navigation/Sections/InstallationContent.tsx b/src/components/Navigation/Sections/InstallationContent.tsx new file mode 100644 index 0000000..de1379c --- /dev/null +++ b/src/components/Navigation/Sections/InstallationContent.tsx @@ -0,0 +1,25 @@ +// External libraries +import * as React from "react"; + +// Semantic-UI components +import { Menu } from "semantic-ui-react"; + +export default class InstallationContent extends React.Component<{}, {}> { + public render() { + return ( + + ); + } +} diff --git a/src/components/Navigation/Sections/MainConceptsContent.tsx b/src/components/Navigation/Sections/MainConceptsContent.tsx new file mode 100644 index 0000000..e0be9de --- /dev/null +++ b/src/components/Navigation/Sections/MainConceptsContent.tsx @@ -0,0 +1,33 @@ +// External libraries +import * as React from "react"; + +// Semantic-UI components +import { Menu } from "semantic-ui-react"; + +export default class MainConceptsContent extends React.Component<{}, {}> { + public render() { + return ( +
+ + Debt Order + + + + Terms Contract + + + + Debt Token + + + + Relayer + + + + Underwriter + +
+ ); + } +}