Payable Contracts – Implementing Sent, Hold, and Sent Back Mechanism

contract-designpayablesolidity

[Q] When following transaction get called: Bank.pay({"from": eth.accounts[0], "value": 1});, who retrieves the money, does the owner of the contract? (Sorry I get lost who actually gains the money). And later on how could that money transfer back to the sender on another function call(this could be viewed as a refund process)?

I would like to carry out following scenario, if possible.

Client A sents some money (lets say 1 wei) to the contract's function, via Client_A calls following: Bank.pay({"from": eth.accounts[0], "value": 1}).
That money should be locked to be used by the gainer until payMeBack() is called. Basically owner of the money is not allowed to spend msg.value => 1 wei.
When Client_A calls following: Bank.payMeBack(): Contract's function will send back the money(imagine is refund process) to Client A, if condition passed. If condition fails, now lock on money should be removed and money is gained by the contract and owner of the money could spent it.

Example contract:

pragma solidity ^0.4.8;

contract Bank{       
    address client;
    uint gainedWei;
    function pay() payable {
       client    = msg.sender;
       gainedWei = msg.value;
    }
    function payMeBack() {
     if(<some condition check>)
        //Some how it has to send back ether to client-A. We know the address we would like to send and the amount. 
    }
}

Thank you for your valuable time and help.

Best Answer

Short answer is Contracts are full participants, so when someone sends funds, then the contract has the funds.

The contract can then decide if/when to send the funds and to whom. In your use-case, it implies keeping track of who is owed funds. You would do that as funds are received.

Very sketchy example to help illustrate the flow.

pragma solidity ^0.4.8;

contract Bank{       

    address public owner;
    uint public receivedWei;
    uint public returnedWei;

    // simple storage pattern descibed here: https://ethereum.stackexchange.com/questions/13167/are-there-well-solved-and-simple-storage-patterns-for-solidity

    struct Client {
        uint received;
        uint returned;
        uint clientListPointer;
    }

    mapping(address => Client) public clientStructs;
    address[] public clientList;

    event LogReceivedFunds(address sender, uint amount);
    event LogReturnedFunds(address recipient, uint amount);

    function Bank() {
        owner = msg.sender;
    }

    function getClientCount()
        public 
        constant
        returns(uint clientCount)
    {
        return clientList.length;
    }

    function isClient(address client)
        public
        constant
        returns(bool isIndeed)
    {
        if(clientList.length==0) return false;
        return clientList[clientStructs[client].clientListPointer]==client;
    }

    function pay() payable 
        public
        returns(bool success)
    {
        // push new client, update existing
        if(!isClient(msg.sender)) {
            clientStructs[msg.sender].clientListPointer = clientList.push(msg.sender)-1;
        }
        // track cumulative receipts per client
        clientStructs[msg.sender].received += msg.value;
        receivedWei += msg.value;
        LogReceivedFunds(msg.sender, msg.value);
        return true;
    }

    function payMeBack(uint amountToWithdraw) 
        public
        returns(bool success)
    {
        // if not a client, then throw;
        if(!isClient(msg.sender)) throw;

        // owed = moneyReceived - moneyAlreadyReturned;
        uint netOwed = clientStructs[msg.sender].received - clientStructs[msg.sender].returned;

        // cannot ask for more than is owed
        if(amountToWithdraw > netOwed) throw;

        // safe-send pattern

        // keep track of money returned
        // to this client (user)
        clientStructs[msg.sender].returned += amountToWithdraw;

        // and overall (contract)
        returnedWei += amountToWithdraw;
        LogReturnedFunds(msg.sender, amountToWithdraw);
        if(!msg.sender.send(amountToWithdraw)) throw;
        return true;
    }
}

Here it is in Remix. 10 deposited, then 9 withdrawn. Running totals and client balances.

Hope it helps.

Related Solutions

Solidity Inheritance – Who Can Call the Parent Function in Function Overwriting

Last question first: overloading concept applies to Solidity but, as for other programming languages supporting overloading functions, i.e. C++, they are not related to each other in any way.

Functions with same name but different parameters are identified by different signatures, so they are actually different functions. If ContractA defines doSomething(), ContractB defines doSomething(string myString), and ContractB inherits from ContractA, final ContractB will have two valid functions that user can call: doSomething() and doSomething(string myString). Visibility also is part of the signature, but it can't be overloaded.

Main question now. From the outside of the contract, you cannot call a base function that has been overridden. This is because what you are calling from the outside is the final contract implementation, no matter how you define the interface on the client to call it.

If you defines

contract EvilDoer{
    function doSomethingEvil{
         A contractB = A(addressOfdeployedB);
         contractB.doSomething();
    }
}

You are simply defining another - and more restrictive - pointer to ContractB and to its implementation of doSomething(). And its implementation is the last one.

But hei, I know default function visibility is public, what if I define explicitly the base function in ContractA as external?

Not much, because you cannot override a function changing its extended signature. Visibility and return parameters are part of the extended function signature, so the compiler throws an error:

TypeError: Override changes extended function signature.

If you want to compile you need to use the same external modifier also in the ContractB function, and then again, the last implementation of function wins in any case.

Please note that changing visibility or return parameters it's not considered an overload neither, because functions are identified by signatures, contracts can't have two functions with the same signature and different extended attributes.

For more information about inheritance topics you can read the official documentation, in particular the information about the super keyword and the final inheritance graph of the contract.

[Ethereum] how to deploy escrow smartcontract and use it with exciting erc20 tokens

I'm having a bit difficulties following your writing, so I'll make this a bit more generalized.

If you are the one who released the token then you have decided how the tokens can be transferred. Most likely you as the contract owner have full power to transfer any amount of tokens to whoever you wish, or maybe even remove tokens from someone (yes, tokens can be removed as they only exist within the same contract, they are never actually 'sent' anywhere).

So if you have full power over the tokens you can just do whatever you want with them - hold some in any sort of escrow for example if your contract supports such functionality.

If you did not create the token contract (but it was created by someone else) you can act as an escrow and get the tokens transferred to your account. When the escrow service is no longer needed, you can either authorize (approve function in ERC20) the transfer back to someone or directly transfer them with the transfer function.

Best Answer

Related Solutions

Solidity Inheritance – Who Can Call the Parent Function in Function Overwriting

[Ethereum] how to deploy escrow smartcontract and use it with exciting erc20 tokens

Related Topic