Save location
Recall location
Clear location

Software Implementation

Content Illustration

Rev 0.02

We will now descend into some of the more detailed aspects of how MyCHIPs should be structured and implemented. With this increase in specificity, comes also more uncertainty. Some assertions are still not consistent or complete, and need more work. Some points may even be worded as questions, seeking an answer.

So the reader is encouraged to challenge the assertions and show how to break the suggested security models. Only after this section is robust, can a functional RFC be drafted.

If this is where you landed first, you may want to review previous articles in this section. And for more depth, you can check out the original presentation in the book.

Finally, the ideas presented here are specific to a MyCHIPs implementation. For example, a CHIP, or Credit Hour in Pool could certainly be created in a number of different ways. But in this context, it means a CHIP, as implemented in the MyCHIP, digital credit exchange protocol.

Money as a Contract

Up until this time, money has been described as credit, a debt, or a promise. While it is all these things, we will now start to use a more formal term: a contract. This will help us understand some of the technical aspects of what the software must accomplish.

Although the Bitcoin blockchain has evolved to contemplate the idea of a contract, a coin itself is probably not a contract. Rather it is a thing—a token that gets discovered, or mined, and then can be spent, or transferred. Like gold, there is a limited supply of it around. Once mined, it must be safely stored or it can be stolen or even lost.

A CHIP is different in that it represents a contract between two parties, debtor and creditor. It can be created out of nothing except a mutually acceptable agreement, and it can be destroyed by fulfilling that agreement. Please read the linked article next—specifically the paragraph on the Split Tally.

Consider how the split tally had two halves which identifiably belonged to each other. And think how a debt was documented by issuing one half of the stick to each of the parties. The notches on the stick identified the value of the tally. But the unique placement of the notches, and the random tear resulting from splitting the stick, produced a security measure to prevent fraudulent tampering.

It would be virtually impossible to change the value (the notches) of the tally undetected, unless you were physically in possession of both halves of the stick. And it would be even harder to manufacture a new stock or foil meant to go along with the other half of the stick. It would not match up at the seam and so would be identifiable as an obvious forgery.

MyCHIPs aims to create a digital implementation of the split tally, so we will adopt some of its nomenclature.

A tally represents a trading relationship between two entities, or nodes. It would presumably consist of an encrypted string of data containing, at least, these components:

  • A universally unique transaction code
  • The type or version of the tally
  • The date the tally was created
  • The identity of the issuer, or holder of the foil (the expected debtor)
  • The signature of the issuer, validating the whole of the tally
  • The identity of the recipient, or holder of the stock (the expected creditor)
  • The signature of the recipient, validating the whole of the tally
  • References to and hashes of any external contracts which may govern the contract
  • Any credit limit for the issuer (the most positive CHIPs authorized to accrue on this tally)
  • Any credit limit for the recipient (the most negative CHIPs authorized to accrue on this tally)
  • Call terms, such as how/when a recipient can require an outstanding balance to be redeemed
  • Put terms, such as how/when an issuer can require an outstanding balance to be redeemed
  • A list of signed transactions indicating the number of CHIPs for each and the date and time transferred

A digital tally would also consist of two halves, a stock and a foil—just like a historical tally stick. But they are just complementary strings representing a digital contract, secured by asymmetric cryptography. The stock would presumably be encoded in such a way that only the holder could read it, using his private key. The foil would likewise be encoded so only the issuer could read it, using his private key.

More importantly, the internal signatures represent hashes of all the relevant data in the tally itself, encrypted with the keys of the agreeing parties. This way, anyone in possession of either half of the unencrypted tally can prove that both parties had consented to the transaction.

The tally is an important concept to understand because it forms the basis for how MyCHIPs will work. Normally we think of money as something that travels. You give me some money for something, and then I spend that same money for something else. The money has traveled from you, to me, and then to another person.

Strictly speaking, a tally is designed to be transferrable, as long as the issuer is agreeable. This just means, the recipient can pass the whole tally along to a new recipient, just as you might pass a dollar bill along when you buy something. In case of such a transfer, the tally would also have to be appended to, to include information about the new recipient and signatures proving the consent of the issuer and the transferor.

However, in most cases, value doesn’t flow by passing tallies around. We will explain more on this later. But for now, you should think of the tally as an open account established between two parties. The parties can trade IOU’s back and forth by appending debits or credits to the tally. And for the most part, there is no reason to close the tally until such time as the parties decide they don’t want to do business with each other any more.

Basic Security Model

The MyCHIPs architecture is intended, among other things, to solve the scalability problem notable with Bitcoin. Under the blockchain architecture, everyone has to have a full copy of the community database. But MyCHIPs is intended to be more fully distributed and de-centralized. For the most part, nodes (individual network servers) should only have to maintain data about their own transactions, and other nodes they regularly do business with.

This is modeled after the paper model of contracts where each party keeps a copy, or the physical tally model where each person keeps his half of the stick. If one party breaks the contract, the other party can present his copy in court for redress. With no single central authority for resolving disputes, the network itself will provide the first layer of accountability.

For example, a compliant node will accurately advertise to, and exchange traffic with, and on behalf of, other nodes it associates with. So if you hold a credit a badly behaving node refuses to honor, other relevant parties will be able to know about it. This will affect the quality rating of the issuer, and others will be less likely to do direct business with him until he is willing to resolve the matter satisfactorily.

If all on-network mechanisms fail to properly report bad behavior (for example, someone modifies his software to mask traffic to/from complainers), then very likely you are in breach of your compliance contract. If it is a good one, it will contain provisions to collect attorneys fees, recovery of losses, and perhaps even punitive measures. The system should thoroughly document the bad behavior for the aggrieved party, with an auditable transaction trail, so the breach can be taken to a court in the real world if the economic benefit of a claim warrants it. A good “attorney fees clause” can do much to facilitate this.

In addition to relying on nodes to accurately relay traffic regarding their own behavior, it is expected certain auditor nodes may choose to collect and publish information about bad players. Although this is not truly a centralized model, still nodes could consult a group of trusted databases to check for any bad credit reports before choosing to do business with a new partner.

Finally, the MyCHIPs system is best represented as a protocol, rather than as a single implementation of software. Although an official reference server should be coded, other nodes should be able to operate their own choice of software, as long as they are fully compliant to the agreed upon communication protocol.

There are no centralized or otherwise specially authorized nodes. And there is no single clearinghouse for transactions. All nodes operate strictly on their own as peers with all other nodes in the network.


An identity (ID) is a digital string that ideally, uniquely identifies a particular individual or company (entity) throughout the term of its life. In addition to just knowing a trading partner’s ID, other nodes will need to know a reliable URL where transactions can be conducted with the entity. So one possible approach would simply be to use a domain name for the ID.

This scheme has the advantage of using the existing DNS system for resolving a host location from a symbolic name. It also can benefit from the existing identity certification authority infrastructure to prevent rogue sites from spoofing legitimate ones.

Such a strategy shouldn’t pose much of a problem for most business entities. They will likely want their MyCHIPs interface to be associated with their regular domain name anyway. The expected complications would occur when one business is acquired by another, or a company otherwise undergoes a branding change.

But it could be a much bigger issue for individual MyCHIPs users. For example, if you started out with a url like: chip://, you might someday get tired of using goochips as your provider and want to switch. But another provider couldn’t necessarily provide you with the same url. It might end up being something like: chip://

So a more sensible idea would be to register a universally unique domains like You could pay a one-time fee into an annuity to fund a lifetime registration, and then use DNS as needed to repoint the domain to any provider you might choose.

It might also be helpful to set up a new top-level domain so personal URLs could look something like: chip://fred_19980301.jones.chip or just: chip://fredjones-19980301.chip. As long as the domain belongs to the individual, it shouldn’t be too much of a problem to repoint a MyCHIP account to any provider you want.

As mentioned, corporate names sometimes change over time. Assuming existing tallies need to persist through this change, a company may have to continue keeping the old domain name registered and active on the web. But it could simply redirect to the new domain name. Once there, the authoritative MyCHIPs server should publish and recognize all such aliases it may operate under.

Obviously, it is possible for someone to make more than one identity for themselves, in order to engage in fraudulent activities. In fact, this is to be expected and anticipated. The goal is to make it difficult to do this and still maintain an excellent quality rating on one’s account. It would also be desirable if this breaks a well accepted compliance covenant so dishonest parties can potentially become exposed to real world consequences.

But as we will see, simply having more than one MyCHIPs ID does not automatically mean you are defrauding anyone—particularly if you don’t make any representations to the contrary. As long as all issued tallies are faithfully honored, and all issued CHIPs fully redeemed, no promises will have been broken, and no one will have been harmed.

In instances where it is important that a single ID correspond uniquely to a single real-world identity, a number of possible real-world methods could be used to certify this uniqueness. For example, a corporate entity could publish information about its legal jurisdictions of incorporation, along with publicly verifiable tax ID numbers for each one.

For individuals, this could include credit certification, or insurance by a known and trusted entity who has access to the individual’s private tax ID number but can also keep that information confidential from the public. Examples include an employer, a life insurance company or a bank where you regularly do business.

It should also be impossible for the public to derive a person’s real world identity simply by knowing a digital ID that may appear or be discovered on the web. For example, maybe you choose a less descriptive id like: chip://abx_1976_0512.chip. Of course, parties you regularly do transactions will by necessity, know this is your ID. But no one else should be able to derive any confidential information about who you really are, just by querying your server.


The system is not intended as a mechanism for hiding illicit activities from government oversight. Neither should it allow visibility to unrelated parties without the consent of the rightful owners of the information.

The paper contract is a good model here as well. Parties create a contract, and as long as it is not breached, others in the world may never see it or even know it exists. It is as if the documents are secure in locked filing cabinets on the private property of each of the parties.

If the contract is to be sold or otherwise presented to third parties, that is by the prior agreement of the original two parties. If one of the parties needs to bring a contract public in order to enforce it, such can be done by choice of the aggrieved party. And if law enforcement wants to see a contract, a ledger, or other chain of activity, they can obtain a search warrant as the local jurisdiction may allow, deliver it to the parties in the real world, and cause them to decrypt the data as appropriate for review.

Agent Server

In the abstract, an ID represents a real world asset, or the net result of a group of assets—a balance sheet, if you will. For a company, the value of the asset could be in products and services, in demand, which it will provide in exchange for credits. For a person, the value will often be future work which can be rendered, past work which has already been banked in the system, or other real-world assets which can be traded or leveraged in exchange for credits.

The server representing one’s ID has the duty to faithfully transact all business on behalf of its real-world entity. Most transactions will only be carried out by the direct and explicit authority of the controlling entity, meaning the person, or an authorized agent within the company. For example, if money is to be spent (net credits issued), the server will obey whatever set of authentication rules the user has set up for himself.

If you are paying for a meal in a restaurant, an app on your phone could pop up and ask you to validate the transaction. This might mean entering a password or scanning a fingerprint.

If you are approving a payroll run for your company, you might even have a more stringent protocol such as entering a number from an electronic token, or taking an iris scan. These would all be functions of auxiliary, or helper applications which would authenticate with your MyCHIPs server using established, secure protocols. Normal precautions can also be taken, such as texting and emailing you any time a credit is issued, or your profile is accessed or changed.

Other functions of the server can be more autonomous. For example, part of your compliance contract can be an agreement to relay information accurately to and from from your trading partners. If you refuse to redeem an existing credit, other parties should be able to know this about you. They would do this by asking to communicate with all holders of your CHIPs, presumably for the purpose of negotiating a trade for them. In the course of that dialog, disgruntled nodes would have an opportunity to warn the would-be buyer of past bad behavior.

You certainly don’t have to agree to a compliance contract that involves the faithful relaying of this kind of information. Many private users will choose not to. But other parties may not want to do certain types of business with you unless you do. So companies and individuals buying and selling directly on the network will likely choose to.

In addition to quality queries and complaints, the server will need to conduct certain trades autonomously, as will be discussed in more detail later. In short, each server must publish information about the CHIPs it knows to be in demand to be bought, or available for sale. Maintaining an honest and ample list of this data will also likely be a part of a strong quality rating.

Also, as part of an automatic reconciliation process, the servers will have to conduct high speed trades, reallocating CHIPs according to parameters established in advance by the owner. These trades will have to be possible without the delays that would be interjected by human interaction. More on this later too.

Consequences of Decentralization

Because the system is decentralized, many functions present in a more centralized system may seem difficult to achieve. For example, what if someone wants to query the entire system to find out where all their CHIPs are? Or what if you want to ask someone authoritative, about the reputation of a potential trading partner? What if I want to find every instance of a particular CHIP issuance for sale?

These type of functions, if necessary, must be implemented as well as possible, but in a totally distributed fashion.

First, and foremost, all nodes are purely peers. Furthermore, each node is only guaranteed to know about the other nodes with which it has an existing credit relationship, established in the real world. So queries of the network will have to happen in some kind of recursive way, propagating outward through associated nodes, along relevant pathways, but truncating where appropriate so as not to bog down the entire network.

Another consequence of decentralization is, all transactions must be completely voluntary. Because there is no central authority, there is no enforcement mechanism, other than the cooperation, or lack thereof from other peers.

Two or more entities should be able to establish a trading relationship with each other, totally independent of the rest of the network. They don’t even have to agree to any particular compliance contracts. They don’t have to publish any financial or other data, unless it becomes necessary to procure the cooperation of other parties they want to do business with.

Ideally, each node will only possess direct knowledge of the other nodes it has a direct connection, or tally with. However, nodes will have to have a way to communicate information with other nodes, more distant on the network.

In order to preserve a reasonable amount of privacy, it is proposed to facilitate indirect communication by sending information through your direct partners. The remote nodes would be identified by using a hash of the node’s real ID. For example, your immediate partner A, may report to you that he knows about another partner (B) who you might want to include in a credit lift. He gives you a hashed ID for B—not B’s real ID.

You can communicate with B, but you do it by passing the message through A, specifying B’s hash ID (HID) as the message destination. That way, B’s ID can be kept somewhat confidential.

We should note, B’s identity can not readily be derived simply from its hash. However, if you guess B’s real identify, you could confirm your guess is correct if the hash is a known algorithm. Therefore, each node should generate its own HID with a randomized component, known only to itself. Direct partners would ask the node for its HID and communicate with other neighbors only using that information.

Since each node is responsible for passing traffic onto other nodes, each one can employ its own policy in conformance with its own compliance documents. In other words, it can decide what to pass along and what to discard. This can reduce or possibly eliminate unwanted or unsolicited traffic on your local network.

Data Storage

As mentioned, each server should only have to store data related to the tallies it is a party to. But there are exceptions, including the following:

One desirable quality is, a node should be able to suffer a complete loss of data and still reinitialize itself from scratch knowing nothing but its private key and a few basic network relationships. In other words, your server could be destroyed in a fire. And as long as you have your private key stored in a safe deposit box, you can plug in a new server, access the private key, and point the server to a few known peers on the network. It will be able to find its bearings and eventually restore its entire database as it had been before.

This implies the need for redundant data stored on the cloud. And the ideal place would be on on your peer servers. Most people wouldn’t want their data available to read on other people’s servers, whether friendly or not. So some kind of data slicing model and encryption would be necessary so no one site could really make any sense of the data it warehouses for its associates.

There would also need to be a protocol for negotiating with other sites, to store their backup data, and have them likewise store yours. One job of the server would be to periodically checksum externally stored backup data to make sure all peer sites are doing their job and storing your data as agreed.

Ideally a node would store every transaction it had ever taken part in, throughout its lifetime, and possibly beyond. While this is much much smaller than what is required in the blockchain model, still it could grow to a large size for some large organizations.

Consideration should be given to the question of whether redeemed CHIPs can safely be pruned out of the database-either right away, or after some period of time has elapsed. Certainly if a fraud is detected after some time has passed, it would be desirable for all legitimate parties to the transaction to have access to the truth of what happened.

In light of the aforementioned constraints, ultimately the choice must be up to the individual user and the compliance contracts he agrees to.

If you lose the record of a tally which is in a debit balance, you may not be able to enforce the debt—at least not without some cooperation from the debtor, or some other party to the transaction. If you delete or lose the record of a completed closed tally, it may never matter, unless you discover a fraud later on and want to document it. If you lose the record of a tally with a credit balance, nothing really changes. Your creditor can still enforce it against you whether you know it or not.

Quality Rating

Just as all entities are responsible to present trust-worthy data about themselves, it is up to potential trading partners to interpret that data. Each entity will have a potential character we will call “quality.” It should be understood, this quality will be in the eye of the beholder—that is, whoever is doing the evaluation.

For simplicity, we will refer to quality as a real number between 0 and 1, or for presentation, a percentage from 0 to 100%. But this number, if it exists, will be generated according to an individual user’s preferences. In other words, entity A may evaluate entity C’s quality at 85%, while entity B might view entity C as having an 80% rating.

The data published by entity C is the same, and seen the same by A and B. But A and B are free to place different values on different parts of the data, and interpret it is they see fit.

In practice, it is likely specialists will emerge who publish recommended formulae for computing a quality rating. Most people will not be sophisticated enough to come up with their own algorithms and so will adopt an algorithm from another trusted party.

Nodes or companies who wish to discuss their own quality rating would therefore qualify it, as in: “My Standard and Poor’s quality rating is 97.5%.”

Each server may optionally make any of the following data available about itself:

  • Server software release and version in use
  • Adopted compliance contracts
  • Date of first issuance
  • Total CHIPs issued to date
  • Total CHIPs satisfactorily redeemed
  • Total CHIPs outstanding or unredeemed
  • Qualification partner IDs
  • Insurance partner IDs
  • Published auditor endorsements
  • Published financial reporting
  • Money market data (CHIPs held and known for sale, wanted, or known wanted, with pricing)
  • A portal for communicating with neighboring nodes
  • Confirmation requests for validating existing tallies
  • Other?
To reiterate, this information is optional. But entities may want to reveal certain things in order to facilitate the trades they want to take part in.

For example, if you only want to exist on the network as a consumer, you may not need to entice others to accept your credit. But you can still establish trading relationships.

For example, you might establish a tally with Wal-Mart. They may not let you spend your CHIPs to buy things. But you can certainly collect their CHIPs and then spend them later for the things you want to buy.

In this example, you are lending value to Wal-Mart, by buying their CHIPs. But they may not be willing to lend you value if you can’t prove to them you can be trusted to redeem the credits later for the kind of CHIPs they ultimately want.

In practice, a consumer might establish just few credit relationships with entities such as their employer or mortgage holder. Tallies held with other entities would allow trading, but not credit, or going into debt.

On the other hand, many companies would have every incentive to publish their fiscal data as widely as possible. Each one of their CHIPs acquired represents free credit obtained from willing participants. The company is free to use that debt for their own capital needs as long as the CHIP is outstanding, or until it is redeemed in exchange for goods, services, or other CHIPs.

Part of an entity’s quality might involve the total number of CHIPs successfully redeemed, compared to the number currently outstanding. A quality algorithm might also take into account how long the node has been successfully trading CHIPs.

An entity’s quality can be further enhanced by including a reference from a well known auditor. In this case, a quality algorithm would contact the auditing entity directly to ask about the entity claiming the endorsement. The auditor could return a signature indicating its approval of the data published by the entity.

Credit qualifiers and insurers would work similarly. However, these relationships are binding. The guarantying entity would, essentially co-sign tallies on behalf of the debtor entity. That way, if the entity defaults, the qualifier or insurer would be obligated itself to fulfill the obligation.

Ideally, each representation made by a server would be subject to some kind of independent verification. This way freelance auditor nodes could query a server, try to validate the information, and then have a way to communicate problems to holders, or potential holders of the issuer’s credit.

Subject to a compliance contract, nodes may be required to publish the HID’s of any entities that have outstanding CHIPs and have still not been made whole, to their complete satisfaction. It will then be up to a quality evaluation algorithm to query those ID’s for further metrics, should they want to provide them. There might well be a counter-complaint from the original entity. Then it may be up to the algorithm to see which of the two parties have more complaints from other, un-related parties.

In the case of a non-compliant node, a disgruntled holder of credit might report his problem directly to someone who specializes in auditing. His tally will prove the consent of the issuer. Yet if the issuer refuses to report the disgruntled node itself, it can be proven to be in violation of its contract, and redress can be sought in the outside world.

Others should also be able to independently query other ID’s you claim as insurers, auditors or credit certifiers. Once you provide the proper authority, you should be able to get any relevant data from those entities. By performing recursive quality ratings on those entities, you should be able to compute a composite quality rating for the original entity.

Compliance contracts should normally refer to standardized contracts, known and recognized by the community so a quality algorithm can know how to apply a weight to it. But it is possible to make up your own contracts and publish them as well. If they catch on, they could become known and understood by other quality scorers.

Here are some examples of the kinds of things that can be represented in standard compliance contracts.

  • The party agrees to value a CHIP according to the specified definition for standardized unskilled labor.
  • The party agrees to maintain an active server as long as there are outstanding CHIPs, or open tallies
  • The party agrees to only engage in transactions that are completely voluntary on the part of both parties.
  • The party agrees to only engage in transactions that are completely informed on the part of both parties.
  • The party agrees to only engage in transactions that are completely competent (capable adult) on the part of both parties.
  • The party agrees to submit to binding mediation, provided by other members of the network, chosen at random by a pre-identified jury pool service.
  • The party agrees to reimburse all time, costs, if he loses a network mediation battle.
  • The party agrees to reimburse all time, collection costs and attorney fees in the outside world, if he loses a claim.
  • The party agrees to pay treble damages for misrepresentation or fraud.
  • The party agrees to honor the published protocol: release version.
  • The party certifies its server software has not been modified from the published release.
  • The party agrees all transactions will involve activities that are legal within his own jurisdiction.
  • The party agrees not to use bankruptcy to avoid or discharge debts accrued on the network.
  • The party agrees it has, and will ever have, only a single ID on the MyCHIPs network.
  • This site will submit itself to outside freelance audits

Credit Partitions

Within a single identity, it should be possible to create a number of smaller partitions, or separate credit containers. In a corporate setting, these could be used to associate a block of credit with a particular employee or manager who has spending authority with that money. For example, payroll might have certain established limits to how much can be spent each week. Similarly, accounts payable could be authorized from a separate partition, and for different purposes.

This granularity could conceivably go to any level, such as “Bob’s meal account.” But these distinctions should not have much to do with the entity’s obligations when viewed by the outside world. Primarily, they would be for the purpose of internal tracking and controls.

For a personal entity, it might be nice to have a partition for normal monthly expenses, such as you would put on a credit card. If someone steals your phone, or otherwise compromises your private key, it would be better to have the potential damage capped at 100 CHIPs, for example, than worrying someone might try to buy a new car or house on your credit.

A larger partition, which you may actually use to buy a home or car, could have different rules than your day-to-day partition. For example, you might need to make a phone call to a specified contact. Or you might even have to show up in person to authorize certain larger expenditures.

Your profile should keep track of your settings, and not allow issuance of credit in any given partition without respecting the specified authorization protocol and credit limit. Furthermore, provisions should exist to cross-check your security settings with known or published trading partners who cache your information. That way, a potential hacker would have to break two or more sites to falsify your credit authorization.

Key Security

As mentioned, tallies use a private/public key strategy, not only to keep the data private from outside parties, but also to establish the consent of the parties to the contract. This leads to the important question: What happens if a party loses his private key, or the private key is compromised?

In the real world, parties can lose their copy of a contract and often still enforce it—as long as they can find a copy, or otherwise prove the existence and terms of the contract. However, any programmatic provisions for recovering a lost private key would probably also create weaknesses which would expose the system to potential attack.

First let us consider a lost private key. Assuming data is stored unencrypted, the owner would still be able to establish all his creditors and debtors. But he would not be able to create new tallies, nor add new credits to existing ones.

All existing tallies, in the hands of trading partners would still be enforceable, but they would not be readily tradable, or amendable. This would introduce an immediate quality problem for a node’s partners who are trying to conduct credit lifts.

The problem will have to be solved relatively quickly, but most likely only with human intervention. A partner holding a tally in debit balance (a creditor) will need the ability to unilaterally sign the tally indicating that it is remitted back to its issuer. Obviously, a creditor would only do this in exchange for equal consideration, such as a new tally, built with a new replacement key and, possibly including additional compensation for his time and trouble.

The debtor would need to retain the endorsed, and remitted tally forever to be able to prove the debt had been discharged. Otherwise, the creditor could later produce an unsigned version of the tally and be able to assert indebtedness. The debtor would have no reason to assert his unsigned copy, as it only constitutes a potential liability to him.

A partner holding a tally in credit balance (a debtor) owes money to the person who lost his key. If asked nicely, or otherwise induced, he should be able to amend the tally at least to zero without the consent of the party with the lost key. If amended to zero, the tally can be retired and replaced with a new tally built from the replacement key. But like any lost contract, enforcement is uncertain, at best.

If a private key is stolen or otherwise exposed, the problem is a lot more serious. The private key is used to sign, or certify the binding agreement inherent in the tally. If someone else uses it, it is like forging your signature in the real world.

Legally, you shouldn’t be liable for an expense in the real world incurred by an imposter who is forging your identity. But it can still be difficult to prove you are not the originator of a contract bearing your signature. And your reputation and credit rating can still be damaged, even if you did nothing wrong. The same principles hold true in MyCHIPs.

So the question is, how to best secure the secrecy of the private key in the first place? Then, how to design the server so the damage will be minimized to a user whose private key has been compromised? Finally, how can the system track and record bogus transactions so fraudulent parties can be held accountable in the real world?

Presumably, an attacker in possession of your private key will try to use it to enrich himself at your expense. This could be done by creating a new tally between you and him, or another node he somehow controls. The tally would be populated by transactions, presumably crediting you and debiting him.

Another strategy would be for him to use your signature to assign existing tally’s in your possession over to himself, or another node he controls. As long as he maintains an identity on the network, either of these approaches would be quite dangerous to him because all contracts are stored by all participating nodes. In other words, if his node claims you owe him credits, your node will know his ID, or to whom the credits are owed.

You would only have to establish in the real world that you have no transactional relationship. In other words, he hasn’t sold you anything, or otherwise transferred value to him, so there was no reason to pay him. If there is no invoice, shipping event, or services rendered you should be able to avoid ultimate responsibility for the bogus credits. But it could be a bit of a fight. On your side is the fact that his behavior is fraudulent (i.e. criminal) so he shouldn’t want to risk potential jail time.

The biggest danger is, an attacker could establish a fresh new network ID without any kind of credit worthiness. He could then use your private key to transfer tallies to himself, or effect credit lifts, resulting in net credits to your ID, and readily tradable credits being transferred to himself. If he could trade those credits for traditional money, and then shut down and abandon his temporary ID, he would have made off with the money at your expense.

The MyCHIPs server should address these issues in several ways. First, any transaction that would be net credit to your account should not be allowed without an explicit validation from the user. This would include a validation of your private key from your smart phone, for example. But it should also include a password or pin known only to you. And it would be great if it includes a biometric validation, or mobile token you might carry.

Validations initiated by your mobile device could connect to your server on a port, and evan an IP number unknown to the public. In other words, you would not connect to your server at the same address everyone else does. Only you would know how and where you make that connection. And there is no reason a daemon listening on that port would have to answer to any query unless the proper credentials have been provided.

Furthermore, the server could validate things like the IP number, and the unique device identification you are connecting from to perform the validation. Any attempt to validate a transaction that does not match every aspect of your validation protocol could cause your server to go into a lock-down mode. Net zero and net debit transfers could still carry on, so your ability to participate in lifts would not be impaired. But no net credits could accrue, and no new tallies could be created until the condition is reset with human intervention from your system’s administrator.

Any transaction net crediting your ID should generate a pop-up advice on your device, requiring an approval before proceeding. If the advice goes unanswered, the server should be able to contact a backup device to report the problem. And any attempt to change this advisory protocol should generate further text and email alerts and/or throw the system into lock-down mode.

Once you know your key has been compromised, you will need a way to recover. The procedure would be to create a new credit partition, with a new private and public key. You would then have to negotiate with each of your direct trading partners (possibly in the real world) to close all existing tally balances and transfer them over to the new partition.

In the end, the best answer is to keep private keys safe (like a backup copy in a safe deposit box) and secure (encoded and/or offline). If your private key is compromised, you can recover, but it will be a lot of work and trouble.


Before going into more detail about network functionality, let’s go through a few typical transactions that might occur on a fairly regular basis.

Let’s assume you’ve just had a great meal at your favorite restaurant. You like it partly because the nifty MyCHIPs logo in the front window means you can pay with your MyCHIPs-capable phone app.

The waiter comes to your table and presents you with the bill, and you show him the screen of your phone which is displaying a MyCHIPs URL barcode. He pulls out his nifty iPad and scans your barcode, and behind the scenes, things start happening.

First, the credit provider for the restaurant queries your MyCHIPs server to see what your credit looks like. This could involve quite a number of transactions as the software tries to figure out who you are, and why the restaurant should accept your credit. If you are a regular customer, you might already have an established account with the restaurant, and they may be willing to accept your credit on face value. Otherwise, they will be performing some kind of a recursive query with your credit certifier, your employer, your insurers, and auditors, etc. to make a programmatic credit decision. The restaurant’s internal logic makes some formulaic decisions about your fitness as a debtor, and within a few seconds, the waiter smiles at you and asks to see your picture ID.

Satisfied that you are the same person he is seeing on the screen of his iPad, the waiter presses another button, and within a few more seconds, the app on your phone pops up with an authorization prompt. The restaurant has, in essence sent your server an invoice, or a request for payment. It did not require any special authority from you in order to get this far, because no money has yet been spent.

If you were getting this invoice from an unsolicited source, you could easily hit a complaint button at this point, which would do all kinds of nasty things to tarnish the reputation of the MyCHIPs identity spamming you with an unwanted pay request. He and others like him would quickly lose reputation to the point that further unsolicited invoicing requests would not pass your quality bar and so would be rejected without you even knowing about them. But this one is legitimate, so you need to answer it.

It turns out the waiter is also a MyCHIPs enthusiast and he gives you the eye, so you aim your phone at him, he pulls out his phone, and you send him the tip directly over IR link, your personal credit, direct to his. The bill to the restaurant, you authorize without a tip.

Behind the scenes, a brand new piece of money gets minted electronically, and it bears the digital signatures of both you and the restaurant. You agree to ”pay” them within 30 days, and they agree to let you out of the restaurant without you washing any dishes.

So this raises an interesting question: What are you going to use to pay them? After all, this is an article on new money, and you’ve just given them some—yours. So why do you have to do anything further?

Because the value behind money doesn’t stand still. It travels in circles, until eventually redeemed. And we haven’t completed the process until that somehow happens.

Because you have such a stellar credit rating, we can imagine the next step happening just as you are walking out of the restaurant. You have instructed your MyCHIPs server to pay all your bills right away, rather than waiting the allowed 30 days. This helps you get out of restaurants and other places quickly so it is well worth it.

So your server makes a standard followup query to the restaurant’s server and asks it what kinds of CHIPs it has and what kind of CHIPs it wants most. The restaurant also gives you a call-back address which will allow you to indirectly query all its direct suppliers and employees as well as its regular, known customers.

We mentioned you are going to pay the restaurant. And the first rule of MyCHIPs is the issuer of a CHIP must always accept its own credits in full satisfaction of a debt. It’s the only legal tender law you will find in the MyCHIPs construct. So you are going to try to find some of the restaurant’s own issued CHIPs in the network and pay it with those.

Not only will that be fully satisfactory to the restaurant, but it will retire some CHIPs that may have been floating around in the CHIP-o-sphere for a while. That will contract the money supply slightly, and will clean up the restaurant’s books just a bit.

If you can’t find those, we will go to the next best thing and try to find something else on the restaurant’s list of “CHIPs it wants.” Anything it specifies in its “want list” is good enough to settle your account.

Most likely, the restaurant is also interested in acquiring the CHIPs of its suppliers. And the more kinds of CHIPs it accepts, the better its quality rating, so they are probably in the list too.

The restaurant will be purchasing food and other supplies on a regular basis and it knows having those kind of CHIPs will make payment easy and fast. The vendors are also known businesses, so their credit is a relatively safe place to store value. So they are good CHIPs to hold—in other words, a good deal for the restaurant.

The restaurant would also be interested in its employees’ CHIPs if they can be found. Paying an employee with his own CHIPs would also close an existing money loop.

But the restaurant may not always have vendor CHIPs available so it may also pay them with its own CHIPs sometimes. And the restaurant will normally be paying its employees with its own CHIPs, so they are likely to have some available. This is why your server will be querying downstream, through the vendor’s supply and labor network, looking for the kind of CHIPs the restaurant wants, but doesn’t yet have enough of.

At the same time, your server may also query upstream in your own network. You are a supplier of labor to your own employer, so he is considered upstream from you. If you find an entity downstream who has CHIPs, satisfactory to the restaurant, you are going to have to give him something in return. You’re not sure what that is yet, but as you query the possible candidates, you will get a list of CHIPs they are looking for as well.

You are looking upstream because that is the stream of CHIPs you have easiest access to, to use for payment. Most obvious among these are the CHIPs of your own employer. You’ve been working there for several months now and you haven’t spent all the credits you have accrued with him.

But you may not find anyone downstream with restaurant CHIPs to sell who wants the CHIPs of your employer. So you may have to keep searching upstream and downstream simultaneously in a recursive, distributed correlation algorithm until you find some available CHIPs upstream that is in demand by someone downstream who has the restaurant CHIPs you are looking for. Another way of saying this is, when you find the same HID both upstream and downstream, you have, in essence found a money circle. It is a pathway, which if you follow far enough, will return right back to you. And the restaurant is the first link in the chain.

Now you are ready to reconcile the bill, which comes nest.

We call this a “credit lift” because of what it looks like on a graph. If you visualize money flowing downhill, or downstream from one entity to the next, you can imagine the restaurant somewhere in the middle. Above it are its customers. Below it are its suppliers and employees.

The money flows downhill, from customer to vendor, from employer to employee, at each step along the way. The value, or product flows in the opposite direction, uphill. Imagine raw materials being mined out of the earth and traveling up through a supply chain to finally become a finished product.

You have found some restaurant CHIPs for sale, held by one of the restaurant’s immediate trading partners. And that partner is looking for CHIPs for sale, held by one of its immediate trading partners. Your algorithm has found a chain of interconnected links, each node of which is interested in collecting some chips of his immediate down-streamer (his supplier). And the end of the chain comes right back to you, through your employer or one of your other trading partners.

Everyone along the chain is willing and able to perform a transaction involving the requested number of CHIPs. Each node only has to worry about the credit worthiness of his immediate trading partners. Each individual node’s logic is: I would willingly give some of my customer’s/employer’s CHIPs back to him, as long as I am guaranteed, at the same time, to receive an equal number of my own CHIPs back from one of my suppliers.

Using a sophisticated database locking mechanism, all servers allocate the transaction, and then execute it simultaneously, in an all-or-nothing, atomic, transaction. Where new credits are needed along the chain, they are generated. Where existing debits (credits in the opposite direction) already exist, they are redeemed, as appropriate.

Each node along the chain digitally signs any existing credits that are changing hands. And all nodes get to verify all the other involved signatures, so everyone in the chain agrees that the transaction is valid, and balances to zero. If any node fails to complete the transaction, the entire thing is rolled back and the search starts over.

At the end of a successful lift, you end up with some restaurant credits, which you trade to them for the personal credit, outstanding. And your bill is now resolved.

All this has happened behind the scenes, while you were enjoying the walk back to your car. That is, if everything worked out right.

More on Transactions

There may well be possible cases where an automated algorithm can’t find satisfactory voluntary trades to resolve all balances. If your server configuration is pretty sophisticated, it may keep trying for 2 or 3 weeks, until your 30 day credit is nearly coming due.

Then you may have a choice to make. Your server might be preconfigured to go out to known money market sites and continue the search for tradable credits. But this may have a modest cost, if nodes are only willing to conduct the necessary trade for a fee.

If you just can’t find the necessary match, you can always convert to dollars, euros, or whatever else the restaurant accepts and resolve the bill that way. The more widespread the MyCHIPs user base, the easier it will become to avoid this last resort.

We should note, your server could also be configured to anticipate your spending patterns. You probably have a handful of grocery stores, restaurants and movie chains you like to frequent from time to time. It would be easy to begin to collect these kinds of CHIPs proactively—even before you need them.

A business may well be willing to give you net 30 terms for your personal credit. But they would prefer to be paid faster. What they really love is when people pay them in advance.

That is the effect of holding a company’s CHIPs. It is like you lending them money or paying for one of their gift certificates. So they might even be willing to give you a discount if you pay directly using their own CHIPs.

One of the fundamental principles of a CHIP is, all CHIPs should ideally be exchanged in voluntary trades at a 1:1 multiple. The list published by a server of what it has, and what it wants, defines the trades it is willing to do at par, or nominal CHIP value.

But it is also possible to include the notion of what I have, that I could give up, but don’t really want to, and what I don’t really need, but am willing to buy under the right circumstances. This is the definition of a money market node—trades the node is willing to engage in, but only if an additional fee is paid, in the form of a trading ratio.

CHIPs you hope to keep, but would let go of for a price, you list a premium ratio for, say 1.05 times par. CHIPs you will take, but are not as anxious to buy, you list a discount radio, say 0.95 of par. Any node anywhere should be able to communicate with you, by way of a message relayed through your immediate trading partners. It is in your best interest for your server to answer such buy/sell questions without reservation or bias.

Double Spending

One of the potential problems dealt with by blockchain technology is the double spending dilemma. MyCHIPs is not entirely immune to this problem. But it is much less vulnerable, due to its recognition that money is credit, and credit can be created and destroyed at will by any two consenting parties.

An initial tally is created between two parties, debtor and creditor. And it contains the signatures of both parties. When it is initially created, there is no particular problem with double spending.

Furthermore, as the parties trade further debits and credits on the same tally, there is still no problem. And transactions really only need to be signed by the party whose net balance is being reduced. The party accepting a net transfer of monetary value only needs to record the transaction—not necessarily agree to it.

But a tally is also itself transferrable. It can be assigned from one recipient to a new party, who becomes the new recipient. This where a potential double spending problem can occur.

If an unscrupulous node, produces, or acquires CHIPs on a tally and then attempts to assign that tally to more than one party, it could artificially inflate the issuer’s currency. Said another way, it could encumber more debt for the issuer than he had agreed to. The node could then obtain other, more reliable CHIPs in trade and spend them for real value, while gradually flooding the market with the counterfeit CHIPs.

The key to preventing, or at least, limiting this lies in the contractual nature of the CHIP. First, the transfer of a tally must involve a locking, atomic transaction that includes the original issuer of the tally, the current holder of the tally, the transferee, and possibly every other past transferee along the line (at least to the degree possible). That way the holder can prove that the transfer was rightful. In other words, the final authority of the transfer is the original issuer himself.

Reputable issuers won’t want anything to do with a scheme to over-issue their own currency. And disreputable issuers won’t have been able to establish a credit rating anyone will want to deal with. A standard part of evaluating the value of held CHIPs will be to query the issuer himself to validate the authenticity of a held tally. And any node that refuses to answer such queries will not be trusted.

A dishonest issuer might manage to get insurance to cover his misdeeds. But then the loss will be passed to the insurer, a known risk. And the dishonest issuer will presumably be subject to real world redress in addition to a lifetime blemish on the network.

Since each tally as a unique ID, it is easy for an issuer to determine he has been scammed. The first time someone asks to verify a phony tally, the problem will be exposed. And since each tally carries an auditable transaction trail, any parties to the fraud would be left very exposed—in both the digital and the real world.

MyCHIPs is not meant to be a secret trading platform where dark parties can carry out objectionable transactions in secret. It is meant for honest people with real jobs, and reputable businesses with real products and services, to carry out legitimate transactions with great security and reasonable privacy.

If the network makes it hard for scammers and deadbeats to survive, that’s exactly the point.

Risk Coverage

We have mentioned insurance and credit certification. In order to be of the highest use, such contracts need to be readily enforceable, preferably by the network itself—but also in the outside world.

What is imagined is something like a conditional tally. The idea is that an insured or guaranteed tally carries not only the ID and signature of the issuer and the owner, but also of the guarantor. In the event that an incurred debt is not honored by its issuer, the owner needs to be able to automatically convert the tally, and its contained CHIPs to become the issue of the guarantor.

This is an irrevocable contract of sorts. Once this option is exercised, the guarantor shall have options for redress, but not against the owner—rather against the original issuer who reneged in the first place. Perhaps the guarantor should end up with a pre-signed and authorized tally issued from the original issuer, and payable to the insurer. That way, if the defaulting entity returns to the network at a later time, the bad debt can eventually be collected.

Personal Strategies

Your server should represent you and your best interests within the economy of credit trading. This opens the door for add-on services which can interact with your node to serve your long term financial interests.

One interesting byproduct of carrying on all your financial transactions in a single trading platform is better accounting.

Few people really do, or even understand, accounting very well. Our money is earned and spent in a variety of different ways. And it takes a huge amount of effort to consolidate all those transactions into a single accounting program like Quickbooks, for example.

Furthermore, if we do go to the trouble of entering all that data, many of us don’t really know how to get a benefit out of it. For example, what can we learn by looking at our balance sheet, or our income statement? If we had better feedback coming from an accounting analysis application, could we perhaps modify our behavior in ways that would improve our quality of life?

Today we have phone apps that help us remember to exercise, or tell us how well we are sleeping. What if an app could tell us how we are doing at saving for college or for retirement? With proper accounting, this could be done. But the amount of work to feed in all the data is often prohibitive. And most of us don’t know how to analyze the data anyway.

But if all our financial transactions are available in a single trading platform, it would be very feasible to develop intuitive ways of presenting, and hence, comprehending our financial fitness. Imagine a graphical representation of your balance sheet, over time that would show you the effect of certain behaviors and help you plan effectively for the future.

An add-on package could tuck away a few CHIPs each week and begin to accumulate them in an interest-bearing, real estate backed issuance. It could help you apply the discipline necessary to assure that when your working years are over, you will have an accumulation of assets capable of carrying you through your later years.

MyCHIPs software should facilitate an API allowing the development of a whole market of add-on products and services to help people take better control of their financial lives.


One more advanced topic involves the idea of mediation. Of course, compliance contracts can, and perhaps should include language enabling damaged parties to seek redress in the outside legal system. Clauses which agree in advance to third-party mediation might be attractive to many quality scoring algorithms. But it is also possible to envision resolving certain complaints right within the MyCHIPs community.

This would work by issuing tallies that are also signed by a trusted mediator. The parties would agree in advance that any dispute regarding the issued debt would be resolved by the mediator. Because he is a signatory to the tally itself, he can have the authority to act on behalf of the issuer or any of the assignees, should a dispute be raised.

If either of the parties disputes a particular transaction or chain of transactions, he can file the dispute with the private mediator. A binding decision could be made solely by the mediator. Or in particularly large cases, the mediator could even farm the dispute out to a group of paid jurors, with reputations and experience ratings of their own. In cases where a larger jury is involved, the case could be decided by a majority, or it could even be a pro-rated judgement according to the differing opinions of the jurors. Each of these points could be dealt with in the particular compliance contracts executed at the time of the issuance.

In each case, mediators and jurors would be paid for their time, by one for both of the parties, for example, the loser, as might be defined in the associated contract.

Topics for Further Discussion

  • What transactions need to happen when a person with a MyCHIPs ID dies? This may happen with or without a named heir in the outside world.
  • A similar topic involves what happens when an ID disappears from the network and is no longer responsive. Outstanding CHIPs issued by the disappeared party represent a potential loss to anyone holding them. Outstanding CHIPs that are held by the party, but issued by others, still active on the network pose the reverse problem. The issuer gets, in essence an interest free loan which could go on indefinitely—at least until the holder reappears later to redeem the CHIPs.
  • What transactions need to be supported by servers in order for freelance auditors and other potential types of enforcer agents to effectively do their work? The test case involves a party who successfully issues CHIPs on the network, but refuses to be fully transparent to auditing servers, and refuses to record negative information about itself. This would be easier dealt with in a centralized system where interested parties could go for a more objective opinion of the party’s reputation. In a decentralized system, we must be satisfied with the reputation of any insurers, or be wary because of the lack thereof.
  • What transactions need to be supported to support the idea of a class action case in the real world? For example, a bad actor issues fraudulent CHIPs and there are a number of other entities who have been harmed. How could a willing enforcer successfully contact all holders of the fraudulent CHIPs, without the cooperation of the issuer, and thereby organize a larger group of claimants to take legal action against the fraud? Again, this is a concept more easily dealt with in a centralized system, but much more difficult in a peer-to-peer network.
  • Perhaps various providers of account services would also be willing to keep a database of alerts which individual servers could query at their option. This could include fraud complaints as well as advertisements for services such as auditing, certification and class actions. Interested servers might want to periodically compare their own CHIP holdings against any issuances that might appear on an alert site. Any number of alert sites could exist, and they could even mirror each others’ alerts to provide a form of centralization that is voluntary.
  • What are the implications of one person having accounts with a number of different providers? Can a single person or company legitimately have more than one ID on the network? Or would different providers deal under the same ID, but manage different credit partitions?
  • There is a need to generalize the money market functionality to work for both CHIPs and traditional money currencies. In other words, each node needs to be able to trade its own CHIPs or the CHIPs of its immediate partners for traditional money. Each node needs to be able to publish the exchange rate it is willing to accept for both buy and sell transactions. And there needs to be a portal to Paypal, ACH, or the equivalent to facilitate the actual transfer. This is like a shopping cart that can be checked out automatically without the interaction of the entity, but according to the pricing established by the user.
  • It would be preferable if, when searching for credit exchanges and lifts, knowledge of the network is distributed. In other words, nodes should only really know specifically about what their nearest neighbors have to buy and sell. Beyond that, they should just know which partner to go through to facilitate more distant trades. The exact knowledge of the complete pathway for a credit lift would be distributed among the participating nodes. This would create additional privacy and security. It would also prevent a single node from mining information about other nodes, such as someone’s net CHIPs worth.


So, much of the detail of server functionality has been outlined. Many other details are left to be sorted out.

If you have gotten this far, please make contact and give your constructive feedback. All questions on this page first need to be resolved. Then it is time to go on to a more complete protocol specification. Then the coding can begin.

Thanks for your interest in MyCHIPs. We hope you will join the effort.