Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[158931291] feat: digestible whitepaper content #3

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added src/assets/images/Broadcast-Debt-Order.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
358 changes: 358 additions & 0 deletions src/components/Main/Architecture/Architecture.tsx

Large diffs are not rendered by default.

132 changes: 132 additions & 0 deletions src/components/Main/DeployedAddresses/DeployedAddresses.tsx
Original file line number Diff line number Diff line change
@@ -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 (
<Container className="Section">
<SemanticHeader size="huge" className="SectionTitle">
Contract Addresses
</SemanticHeader>

<div className="subsection">
<ContentAnchor id="AddressDebtKernel"/>
<SemanticHeader size="large">DebtKernel</SemanticHeader>

<p>Mainnet: <pre>0x8ef1351941d0cd8da09d5a4c74f2d64503031a18</pre></p>

<p>Kovan: <pre>0x755e131019e5ab3e213dc269a4020e3e82e06e20</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressDebtToken"/>
<SemanticHeader size="large">DebtToken</SemanticHeader>

<p>Mainnet: <pre>0xf7b3fc555c458c46d288ffd049ddbfb09f706df7</pre></p>

<p>Kovan: <pre>0x12c8615fd55bf6e1f5a298cebdc72e50f838df74</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressDebtRegistry"/>
<SemanticHeader size="large">DebtRegistry</SemanticHeader>

<p>Mainnet: <pre>0x4e0f2b97307ad60b741f993c052733acc1ea5811</pre></p>

<p>Kovan: <pre>0x9662d6cae0e6914a388cb96c1c161cc4d12c3d7a</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressTokenTransferProxy"/>
<SemanticHeader size="large">TokenTransferProxy</SemanticHeader>

<p>Mainnet: <pre>0x2f40766e91aaee4794d3389ac8dc3a4b8fd7ab3e</pre></p>

<p>Kovan: <pre>0x668beab2e4dfec1d8c0a70fb5e52987cb22c2f1a</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressDharmaMultiSigWallet"/>
<SemanticHeader size="large">DharmaMultiSigWallet</SemanticHeader>

<p>Mainnet: <pre>0x9445d5ddc2d8a3663ce8cc9fe74009f99b343cfc</pre></p>

<p>Kovan: <pre>0x5e6d80063af17bf22b6828a7a61693ec37881563</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressRepaymentRouter"/>
<SemanticHeader size="large">RepaymentRouter</SemanticHeader>

<p>Mainnet: <pre>0xc1df9b92645cc3b6733992c692a39c34a86fae5f</pre></p>

<p>Kovan: <pre>0x0688659d5e36896da7e5d44ebe3e10aa9d2c9968</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressTokenRegistry"/>
<SemanticHeader size="large">TokenRegistry</SemanticHeader>

<p>Mainnet: <pre>0xd79396ab3bfaaa0d9f6d11f95bb641601d93c0a9</pre></p>

<p>Kovan: <pre>0x6949948d93f3dbe50ec2fe54815fa33bfa284d35</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressSimpleInterestTermsContract"/>
<SemanticHeader size="large">SimpleInterestTermsContract</SemanticHeader>

<p>Mainnet: <pre>0xb78a7d1c1d03cf9155cc522097cbc679e15cf9a3</pre></p>

<p>Kovan: <pre>0x4cad7ad79464628c07227928c851d3bc5ef3da0c</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressCollateralizedSimpleInterestTermsContract"/>
<SemanticHeader
size="large">CollateralizedSimpleInterestTermsContract</SemanticHeader>

<p>Mainnet: <pre>0x5de2538838b4eb7fa2dbdea09d642b88546e5f20</pre></p>

<p>Kovan: <pre>0x13763cf3eb3b6813fa800d4935725a0504c8eb8f</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressCollateralizer"/>
<SemanticHeader size="large">Collateralizer</SemanticHeader>

<p>Mainnet: <pre>0xecc718386176d714dc9e4e35e177396b291499ee</pre></p>

<p>Kovan: <pre>0x4b86bbe375577262cb0b3b7893e3de0d11751dd6</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressPermissionsLib"/>
<SemanticHeader size="large">PermissionsLib</SemanticHeader>

<p>Mainnet: <pre>0xba0d793fb316d7a457b758e75a57e22ee14bc188</pre></p>

<p>Kovan: <pre>0x0e7e2aace2ed2565777b420fd181b556971a8cb1</pre></p>
</div>

<div className="subsection">
<ContentAnchor id="AddressContractRegistry"/>
<SemanticHeader size="large">ContractRegistry</SemanticHeader>

<p>Mainnet: <pre>0x10512440113cb6cb613be403135876d2e0a42c0b</pre></p>

<p>Kovan: <pre>0x506acb19a451cc6e2a5c76e65f6b65840406e5f9</pre></p>
</div>
</Container>
);
}
}
8 changes: 8 additions & 0 deletions src/components/Main/Main.css
Original file line number Diff line number Diff line change
Expand Up @@ -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;
}
24 changes: 18 additions & 6 deletions src/components/Main/Main.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -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;
Expand All @@ -33,9 +36,18 @@ export default class Main extends React.Component<Props, {}> {
<Installation/>
<Divider />

<MainConcepts/>
<Divider />

<DebtOrderAPI/>
<Divider />

<Architecture/>
<Divider />

<DeployedAddresses/>
<Divider />

{
// For each section, render a Section component with the relevant data.
_.map(documentation.sections, (section) => {
Expand All @@ -52,11 +64,11 @@ export default class Main extends React.Component<Props, {}> {
})
}

<Contributing/>
<Divider />
{/*<Contributing/>*/}
{/*<Divider />*/}

<Upgrading/>
<Divider />
{/*<Upgrading/>*/}
{/*<Divider />*/}
</Segment>
);
}
Expand Down
170 changes: 170 additions & 0 deletions src/components/Main/MainConcepts/MainConcepts.tsx
Original file line number Diff line number Diff line change
@@ -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 (
<Container className="Section">
<SemanticHeader size="huge" className="SectionTitle">
Main Concepts
</SemanticHeader>

<div className="subsection">
<ContentAnchor id="ConceptDebtOrder"/>
<SemanticHeader size="large">Debt Order</SemanticHeader>

<p>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.</p>
</div>

<div className="subsection">
<ContentAnchor id="ConceptTermsContract"/>
<SemanticHeader size="large">Terms Contract</SemanticHeader>

<p>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.</p>
</div>

<div className="subsection">
<ContentAnchor id="ConceptDebtToken"/>
<SemanticHeader size="large">Debt Token</SemanticHeader>

<p>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.</p>
</div>

<div className="subsection">
<ContentAnchor id="ConceptRelayer"/>
<SemanticHeader size="large">Relayer</SemanticHeader>

<p>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:</p>

<ol>
<li>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
</li>
<li>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.
</li>
<li>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.
</li>
</ol>

<blockquote>
<p>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. </p>
</blockquote>
</div>

<div className="subsection">
<ContentAnchor id="ConceptUnderwriter"/>
<SemanticHeader size="large">Underwriter</SemanticHeader>

<p>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. <strong>An underwriter is a <em>trusted</em> entity that
collects market-determined fees for performing the following functions:</strong>
</p>

<ul>
<li>Originating a debt order from a borrower</li>
<li>Determining and negotiating the terms of the debt (i.e. term length,
interest, amortization) with the potential debtor
</li>
<li>Cryptographically committing to the likelihood they ascribe to that debt
relationship ending in default
</li>
<li>Administering the debt order's funding by forwarding it to any number of
relayers.
</li>
<li>Servicing the debt -- i.e. doing everything in the underwriter's
reasonable power to ensure timely repayment according to the agreed upon
terms
</li>
<li>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
</li>
</ul>

<p>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.</p>

<blockquote>
<p>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.</p>
</blockquote>
</div>
</Container>
);
}
}
Loading