This file describes the high-level requirements
in non-technical terms for the EGT system,
including E-Gold, DigiGold and CMCF concepts.

<h1>Requirements</h1>


  
<h2>Structure</h2>

<h3>E-Gold</h3>

Issuers of E-Gold are
known as <i>Reserve Institutions.</i>
<p>
<small>
Strictly speaking, issuers is an inappropriate
term, but from the software point of view, there
is no distinction.  Here, I'll stick to the
software usage.
</small>
<p>

Following notes apply:

<ol><li>
    There are multiple Reserve Institutions.
</li><p><li>
    E-gold can be atomically transferred
    by users
    between Reserve Institutions as well.
</li><p><li>
    Reserve Institutions should be 
    legally distinct entities,
    geographically and jurisdictionally
    distributed.
</li><p><li>
    Reserve Institutions must be auditable
    by &lt;someone&gt; to ensure successful
    execution of contractual obligations
    to holders of E-Gold.
</li></ol>

<p>
As an assumption, all reserve institutions
are settled via one system, and this is operated
by EGT.  This permits, at least, that users
can transfer assets amongst different RIs.


<h3>CMCF</h3>

A CyberMetal Credit Facility (CMCF) must be able to:

<ol><li>
    <b>issue own debt to raise funds for loaning out.</b>
    No particular fashion but it is envisaged to be negotiable certificates.
  
  </li><p><li>
    <b>A CMCF can take deposits.</b>
    This is financially the same as the issuance of own debt.
  
  </li><p><li>
    A CMCF can make loans.
  
  </li><p><li>
    <b>A CMCF can securitize the issue of small borrowers.</b>
  
  </li><p><li>
    A CMCF must be able to create multiple digital instruments,
    preferably on the fly.
  
  </li><p><li>
    Must be capable of publishing the complete
    balance sheet for a currency.
</li></ol>

CMCF should be able to securitize an asset from
a single party for the purpose of floating that
asset as certificates.
E.g., the Berkshire-Hathaway idea.

<h2>DigiGold</h2>

DigiGold certificates are
<ol><li>
    negotiable,
  </li><li>
    branded (as DigiGold),
  </li><li>
    fractionally reserved,
  </li><li>
    redeemable in e-gold,
  </li><li>
    redeemable according to contract stated by issuer,
  </li><li>
    suitably audited for redemption performance,
  </li><li>
    unit of account is oz-e-gold,
    or similar E-Gold metal.
  </li><li>
    may be cleared through third party CMCFs,
  </li><li>
    meant to be used as a currency,
  </li><li>
    should not be defradable.
    This means probably accounts are not
    temperable by the CMCF
    (tamper-resistant hardware or distributed).
</li></ol>

<p>
What is a 100%-backed-by-e-gold certificate?

<p>
How and what is <i>suitable auditiability</i>?
Is this a process of working at a bunch of ideas,
or of specific requirements?

<h3>Transactions</h3>

<h4>DigiGold Transaction</h4>

A transaction using the DigiGold certificate should
meet these requirements:

<ol><li>
    Provide non-repudiable receipts, that are
</li><li>
    checkable by at least a TTP or the client, and
</li><li>
    atomic, and therefore idempotent and cancellable,
</li></ol>

<h4>E-gold Transaction</h4>

E-gold transactions are

<ol><li>
    push - in that the payer must initiate,
</li><li>
    payer must authenticate,
</li><li>
    transactions are not roll-backable,
</li><li>
    and therefore, authentications must be strong.
</li><li>
    available both to humans and programs
    (web and API interfaces), as it is assumed
    that some access for running DigiGold issuance
    will be program-driven.
</li><li>
    accounting supports transactions costs
    and other statistical methods (e.g.
    balance).
</li><li>
    capable of being costless for designated
    accounts and/or transactions.
</li></ol>


Big question of solvency - how to measure and enforce.

<h4>CMCF Transactional System</h4>

The CMCF has conventional accounting
systems for borrowers with tailored
loans, etc.

<p>
deposit of DigiGold and E-gold.
This is standard accounts.

<h2>The User</h2>

The client software must provide the
following user requirements.

<ol><li>
    There must be only one class of user
    (no purchaser-merchant distinction).
</li><li>
    The user must be able to receive and
    process a payment in an automated fashion.
    This is the merchant-wallet.
</li><li>
    The wallet must store a processed payment
    in safe storage.
</li><li>
    The system must not require
    identifying information (of either party)
    in order to effect a DigiGold transaction.
</li><li>
    The system may provide a method of identifying
    the payer to the payee.  This is for the
    purposes of authenticating a merchant as
    a trustworthy recipient of purchasers' funds.
</li><li>
    The system
    must be able to create a non-revocable
    payment.
</li><li>
    The system must shield a purchaser-user
    from the distinction between
    different contracts issued in the same
    unit of account...  The method of this
    shielding is deliberately not specified
    (because the obvious will not work...).
</li></ol>

<h2>The DigiGold Wallet</h2>

The Wallet requirements for the DigiGold system include

<ol><li>
    Access to (individual) contract summations must be provided.
</li><li>
    There must be at least one
    wallet choice available that keeps
    history and makes it available for client software,
    and one choice that does not keep any history.
    This could either be by
    options or distinct software packages.
</li><li>
    The wallet must use Ricardian contracts.
    These are contracts which are identified
    by a hash of a document that provides for
    (legal) contractual and (technical) access
    details.
</li><li>
    The Wallet should be Open Software.
</li><li>
    CMCF is only required to live up to ???
</li><li>
    Wallet must take appropriate security
    measures to ensure protection of
    assets and records.
    (Appropriate is implementor-dependant.)
</li><li>
    Wallet may request authentication
    of some form from the user.
    E.g., passphrase.
</li><li>
    The Wallet must provide stream output and
    input for export and import of payments.
    ( This feature is for the ascii-armoured
    payments that can be cut-and-pasted and
    mailed between users, see client ).
</li></ol>

<h2>The Client</h2>

The client is the user program that uses the wallet
to access the protocol and value core.
Basic client includes:

<ol><li>
    The client must provide the following
    information:
    <ul><li>
      </li><li>
          A balance for individual contracts.
      </li><li>
          A consolidated balance
          for groups of assets, where
          a given unit of account should
          be a group under this definition.
          This may be summed according to
          some unspecified algorithm, where different
          contracts imply distinct underlying
          values.
      </li><li>
          A consolidated asset value may
          be presented, where sufficient information
          is available for conversion between dissimilar
          underlying assets (e.g., gold and silver).
    </li></ul>
    It is not at this stage specified if this information
    needs to be provided under option or configuration
    control.
</li><li>
    history of digigold transactions
    may be provided,
</li><li>
    Must provide choice of history on or off.
    (I.e., stores audit trail on or off.)
</li><li>
    Should include:
    <ul>
       <li>some authentication method for
           payer-authentication of payees.
    </ul>
</li><li>
    Should be capable of handling multiple wallets.
</li><li>
    Raw application included in all clients is
    export and import of value in ascii data message.
</li></ol>

Need to consider how to do multiple
wallets standards.

<h2>Auditing</h2>

The issuance of DigiGold implies a level of auditing
by (any?) external parties.
The values to audit should include:

<ol><li>
    Size of Reserves held at E-Gold.
    <p>
    The question here revolves around how
    to make sure that those funds do in
    fact form redemption reserves for any
    given issued contract.
    
  </li><p><li>
    Quantity of issued certificates against those
    reserves.
    <p>
    The question here is basically how to ensure
    that the issuer's accounting system reveals
    the truth about this number.
    
  </li><p><li>
    Summed or otherwise camoflaged values of
    redemptions and deposits?
    
</li></ol>

<h2>Redemption</h2>

There can be redemption by one or more
methods.  The following is required.

<ol><li>
    There must be a method by which the client
    can return DigiGold to the issuer
    (as identified in the Ricardian contract)
    in return for the underlying asset
    (being E-Gold metal transfer).
  </li><p><li>
    An exchange (or secondary market) should
    be provided to permit the client to trade
    the DigiGold for other DigiGold assets or
    some other asset.
    This is in addition to the direct redemption
    into E-Gold, above.
  </li><p><li>
    An issuer may provide
    some other method as
    specified by the contract between the holder
    and the issuer.  This is not specified.
</li></ol>

<h3>Primary and Secondary Market</h3>

Primary and Secondary market - distinction
lies in one of initial distribution of
issue to customer base versus the trading
of issue on an exchange.

<p>
At this stage, no particular support for
a primary market is envisaged.  Is this
nieve?  It is mostly a customer base concern.

<p>
OTOH, a secondary market is envisaged, as
and when the clients and wallets are capable
of performing the appropriate protocols.