How can you modify a contract after its creation?


I read "How to make a contract updatable" post but my question is less technical and more general. I hired coders to work on my project and as a non coder I am trying to come up with the system architecture of how my DAO will actually work. I apologize in advance if I am posting in the wrong area or my prerequisite reading is missing a great deal. As an eager enthusiast I am trying to read as much as I can as quickly as I can :) or if this question has already been answered somewhere else please correct me / direct me to some links.

My logic tells me that a contract cannot be modified by its creator after it is created without the risk that a malicious creator could disadvantage the principle participants. How can you be sure that the modifications are provably fair and more beneficial to the participants? If you can't modify a contract after its created how could you fix bugs or mistakes in the contract code?

I would like to create a DAO and this DAO will create a pool of insurance funds. My concept is that there will be the need of several different modules in order to collect premiums and pay out claims. Perhaps any of these modules might need to be tweaked or fixed to improve their function.

My current plan is to create a core contract which appears in the app store that has very few lines of code and is coded as carefully as possible but which calls and relys on other sub contract modules. This is the contract that would hold all the premiums and from which claims would be paid as well as holding the database of participants thus modifying its code after people have started using the DAO / DAPP would be avoided if at all possible. But the subcontract modules which perform various tasks from solving shelling point problems to holding the logic for how claims are paid out I could modify because those contracts are not directly connected to the principle participants.

Perhaps this core contract would allow people to vote upon their participation in a 2.0 upgrade at a future date which would facilitate the migration of participants to a new contract platform. But even if this would facilitate transferring over members individual accounts once premiums are paid they belong to the system not to individual members so if you transfer accounts to an upgraded contract that doesn't contain any premiums you wouldn't be able to successfully pay out claims unless your original contract contained instructions to transfer funds to a future 2.0 upgrade. But if you want to participate in the 1.0 app and see a line of code that will facilitate a future transfer of paid principle funds to a future 2.0 app that hasn't been written yet how can you know for certain the 2.0 upgrade isn't a scam?

Even if I have the freedom to manipulate the sub module contracts that are called upon by the main contract how can people know that these modifications also are provably fair? The contract modules used by the core contract would almost certainly need to be modified many times in an attempt to get everything to function correctly and to provide improved features. But this to me seems to open up doors for malicious entities to do malicious things which is why I am wondering how this can work.

What is the way it really works? What is the proper balance between fixed contract code and malleable contract code? What am I missing? Also I take this project very seriously so although I am working with a team of 2 other individuals to try and get it coded by Feb (we are still learning Python and haven't even started on Serpent yet) I realize almost immediately that even after taking our best stab at this we should seek out members of the Ethereum team for consultant support to make sure we are presenting something to the community which is fair, reliable, and helpful.

So although my question is primarily "how can I code something that can be changed in a provably fair way after people have paid into a contract" a larger question is what is the roadmap for developers who are serious about using this new technology so that they can make sure what they present to users is truly a quality product.

Again I really apologize I am incredibly enthusiastic and I am trying my best to read as much as I can as quickly as I can. haven't spent adequate time before writing this post to really research the forums/documentation as I'm sure this question is answered somewhere.



  • joshuad31joshuad31 Member Posts: 30
    I found this to be incredibly helpful and relevant:

    There are two levels to the DAO code. The immutable code is the contract itself: this is what you see marked up below. The contract also contains mutable code, which is what the DAO does (stored in This code executes when interacted with and, here’s the key thing, can be changed by voting from the members of the DAO. Think of the immutable code as the structure of our government (how judicial, legislative, and executive branches work together) and the mutable code as our laws (what our government actually does, which changes over time as laws change).

    This makes a lot of sense actually and I can see how it would be possible to write the logic to reach consensus regarding changes and upgrades.
  • sdpalleysdpalley Member Posts: 15
    Joshua: I'm an insurance coverage lawyer (U.S. based) -- If you get to a point where input/feedback on terms would be helpful feel free to ping me; I'm glad to connect. As you know, insurance is a heavily regulated business. When you talk about premiums and claim payments you can expect to raise the interest and attention of regulators. Doesn't mean that insurance can't and shouldn't work with a DAO. Not at all. I love the idea of crop micro-insurance, and anything that reduces claim payment friction would be great for my clients (policyholders). But it's an area where the impact of and relationship to external law and regulation require some very careful thought as well. You may already be all over that and if so forgive me for stating something that's obvious to you. Best of luck, regardless!
  • joshuad31joshuad31 Member Posts: 30
    Thanks for the advice but I have already secured funding to obtain consulting services from Ursium for the final stage of this project. If however you are a member of a larger consulting firm that can offer a broad array of services on every aspect needed to bring a DAPP to the Ethereum app store I would consider your offer.
  • sdpalleysdpalley Member Posts: 15
    edited September 2014
    Hey, that's awesome! Glad to hear that you have the resources that you need. Nah, I'm just a simple country lawyer and I happen to focus on insurance. Best of luck to you -- it sounds like a wonderful project. SP.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    @joshuad31 contracts cannot modify their code, but they can have storage that refers to other contracts. So in-effect they can be changed by changing what other contracts it uses to calculate/do stuff.

    DOUG is the first systematic approach to organizing it. Basically each contract is actually a cluster of contracts and you refer to each other via a central contract that identifies each by name. So what the name refers to can be changed. Project Douglas' Eris, and Andreas Olofssons variously named variants followed.

    The requirement for changing the reference can be arbitrary code. The current approach to have those changes not be malignant is basically that the parties basically vote on changes.(Eris has a whole forum system to help discuss it, decentralized on magnet links) If a change can affect a lot, you'd have to really up the ante for the amount of people that have to agree. (If that makes things too hard to change, delegative voting might be a possible, or 'absentees count less') "The parties" are also a thing the contracts have to determine.(in principle it could also depend on the decision being made)
  • joshuad31joshuad31 Member Posts: 30
    edited September 2014
    @Jasper It seems like what you are describing is sort of like DNS. What is this DNS like system that acts as an intermediary between contracts providing for pointers that are like names? Also if what you say is true and a contract can never be modified after it is created then for most cases having a contract suicide and then changing its pointer to a new contract seems like it would work ok. Again I would have to understand how the DNS like system interfaces with a voting platform, can a vote trigger a contract to suicide and for the pointer to change? If so what can I read that will explain this and how do you pay the gasprice to run this in the EVM?

    But this doesn't seem to work for contracts holding substantial funds such as a large pool of insurance premiums. Wouldn't you need to do voting within a contract in order to migrate a pool of insurance premiums to a 2.0 contract upgrade? Same thing if a contract is holding onto some important data/database that needs to be migrated.

    I can see how it would be done in principle. I know many of these things are new but in the coming months I hope peoples hunger to understand this technology will start to lead to an aggregation of information around specific topics and best practices.

    To create an insurance DAO there are several challenges and I am starting to see that many of them are caused by a misunderstanding or misinterpretation of how the blockchain technology is actually applied.

    I could also potentially see how someone might understand certain principles and then foolishly create a Dapp that costs ridiculous amount of gas because you are trying to use the blockchain to perform too much work. Seems like only those who regularly are writing and running contracts would have the discernment to know that certain parts of the program would be better of running off blockchain on a server system that could be publicly audited.

    What options are there for running some code off blockchain to save on gas costs in a way that might still be provably fair? What type of interfaces does the EVM have to mitigate high gas costs?

    I apologize for asking so many unrelated questions. I am certain there is probably a primer out there that I just haven't read (I read the white paper but it speaks about things in a general way).
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Yeah it is like a DNS, sort-of, and contracts can be made to suicide and their links to be replaced. The contracts being replaced having a lot of funds is probably not that big a deal, those can be moved fairly cheaply. But having a lot of storage, moving that storage over to another contract is expensive. Basically, you'd probably want contracts doing storage separated from the ones doing logic(that you might want to replace) around that storage.

    Note that i used the word 'vote' but as i said, the cause for a contract to do something can be some arbitrary code.

    Hanging blocks are a method of basically making 'auditable blocks'. In short you can get statements out from the hanging blocks to interact in ethereum, and getting the statements relating to before and after some incorrect execution of code can be used to show to the contract that it executed incorrectly.(that can also interact with the contract state) Its main weakness is that simply not sharing the data, you can do arbitrary incorrect stuff, a defence is to simply vote on the availability of the block.(and have people able to replace the role of block creator)
  • sdpalleysdpalley Member Posts: 15
    I'm still interested in how this works from a regulatory/legal standpoint. @jasper -- if a (non-technical) regulator in London or Eindhoven or Duluth sees the words "premiums" and "insurance" they will have questions. Where do the funds exist? I'm not sure that the answer "everywhere" or "nowhere" will help.

    Seems like one way to deal with the issue is to specify from which jurisdiction's funds will be accepted and where they will reside. I realize that's a limitation on the potential of the technology but insurance is a heavily regulated industry like banking and it's gotta be addressed. Another way entirely is to ask whether this is "insurance" and the funds are "premium." If they are, they are -- if it walks like a duck and talks like a duck, it's probably a duck. If it's not insurance, however, calling it that raises questions that maybe aren't necessary to answer. It sounds like insurance to me, but . . .
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    edited September 2014
    @sdpalley i didnt really go into that, didnt mean to imply that i did, at least. But yeah that is a tricky question. Where are my funds, are they where i live or at my bank? Does it really matter if my bank is where they put the servers that keep track of the amounts of money? Its more about which organization is responsible for it?

    Of course a DAO isnt an organization to these regulations, i suppose the idea of a more traditional organization that bridges to the DAO is an idea here. They would have people responsible for it on the traditional end of the bridge, but it cant be DAO if the traditional controls every aspect of it. Lets say it goes wrong, a lot of the assets are out of reach.

    What about the argument that Ethereum is just the 'machinery' the software runs on? I am sure that people go like 'matter-a-fact' .. it puts it out of reach.

    On the other hand in some ways the DAO could be easier to regulate, because the rules of the organization are all in the open. Even individual dealings might be, or they might possibly be "provably exposable" if needed. (not entirely sure how, but maybe something like proof of reserve)
  • sdpalleysdpalley Member Posts: 15
    Understood -- I didn't think you'd gone into the legal piece. And I hope I'm not off topic. :) It's just an interesting (and hard) question, and appreciate your thoughts!

    One would distinguish between Ethereum and the "contracts" that run on it, correct? I'm actually not thinking about regulation of Ethereum qua Ethereum. in this particular use case. Ethereum might indeed be like machinery that transmits or computes -- and like a phone company or cloud server not usually liable for transmission or computation that takes place on it. Just because an insurance company uses phones or a remote server, doesn't mean that the telco or server provider are insurance companies. So too, here?

    Separate (?) question is how the transactions themselves are treated by the law. And maybe from a regulatory standpoint a DAO would be an improvement -- in the US, insurers have to provide information about statutory reserves (and other data) to regulators and to rating agencies. And claim handling information is also published, sort of. The organizations are often closely tied to the insurers and also have close relationships. (As a guy from an investment bank that will remain nameless once told me -- "the deal will get an investment grade rating; I summer at the Hamptons [a fancy resort area in New York] with the guy from" the rating agency. I can see regulators liking the transparency perhaps; consumers would definitely benefit. Proof of reserve and reputation would be lovely additions to insurance.

    I'm not sure what the answer is to defining a jurisdictional nexus. My gut tells me that if you call something an insurance contract, some insurance commissioner somewhere will be interested. Not an insoluble problem or unanswerable question, and definitely interesting!
Sign In or Register to comment.