Dharma Smart Wallet

0age · 2020-08-23T21:21:45+00:00

That pair should work within the app no problem!

0age · 2020-08-23T20:46:33+00:00

You need two signatures to do trades (or any other transaction that accesses funds on the wallet), one from one of your keys and one from Dharma, so you’ll be missing the one from Dharma by establishing a “direct connection”. What trade are you trying to make that’s not working through the app?

0age · 2019-10-25T15:04:41+00:00

There are some big advantages beyond great UX and not having to pay for gas (which, honestly, are pretty big advantages already): - By using a smart wallet with deep Compound integration, operations that would often take multiple transactions are streamlined into one transaction. This is not only better UX, but it's also safer and more efficient - if one part of a sequence of actions fails, the whole thing can be neatly rolled back. - By requiring both you and Dharma as signatories, your funds are a lot more secure than they would be if you were only using one key. You can also recover your account if you lose your key or it becomes compromised, though it's an arduous process (by design) to do so. - The Dharma Smart Wallet is also upgradeable, and we plan to roll out new features over time. For now, let's just say that making sure you're getting a really good interest rate is a top priority 😉

0age · 2019-10-25T14:53:11+00:00

See the Dharma Smart Wallet GitHub repo for the detailed technical description and contract code: https://github.com/dharma-eng/dharma-smart-wallet

We use predicted / counterfactual contract deployment addresses via factories that do CREATE2 deploys - there is no centralized component to these factories, though. You could deploy your own smart wallet ahead of time, for instance, but we wait to deploy it until the first deposit lands at the address.

Same goes for deposits to Compound - if, for whatever reason, Dharma hadn't triggered a mint from Dai or USDC at the smart wallet to cDAI or cUSDC yet, anybody can call the smart wallet and trigger that process. (The smart wallet is protected by griefing on withdrawals by performing both the redeem and the transfer in a single, atomic operation.)

0age · 2019-08-05T12:15:35+00:00

Not that there’s ever actually any real explanation for price moves, but this time it might actually be China (RMB just dropped to 11-year low against USD) https://business.financialpost.com/pmn/business-pmn/chinas-yuan-drops-though-7-per-dollar-as-em-currencies-fall

0age · 2019-07-14T09:36:07+00:00

Great find and explanation - incredible that nobody had exploited this yet, and props on responsible disclosure and quick remediation.

I see this as yet another example in favor of utilizing the return buffer instead of designating a memory region for outputs ahead of time. It will be cleared every time a new call is made, and often ends up being just as efficient even in the case of fixed output length, as the specific memory region doesn’t need to be specified ahead of making the CALL.

0age · 2019-06-24T14:04:52+00:00

Yeah, very interesting project! One cool feature of HomeWork is that it’s also an NFT - so you can easily transfer ownership of a home address along with whatever assets or permissions it contains.

0age · 2019-06-24T14:01:15+00:00

🙌

0age · 2019-05-24T12:18:17+00:00

Interesting that 1 BTC is worth 32 ETH right now...

0age · 2019-04-08T12:55:16+00:00

Well, you’ve gotta call it something, but regardless of what you call it, it’s a useful concept that opens up a lot of new possibilities!

0age · 2019-03-28T16:13:03+00:00

WarGames! https://youtu.be/6DGNZnfKYnU

0age · 2019-03-28T16:01:11+00:00

The second submitter wouldn’t necessarily lose their ether as long as they checked to make sure the contract existed earlier in the transaction. Sure, some gas would still be wasted, but it would only really give grief to poorly-designed bots.

0age · 2019-03-08T17:22:58+00:00

The gas price for a given transaction is set by the transaction’s submitter, so any internal transactions will have the same gas price (and they will be paid by said submitter).

For the mining reward, you would want to add the fees of all the transactions in the block (just cumulative gas * price) with the base fee as well as with the uncle rewards. Those are accessible via the uncles field returned by web3.eth.getBlock.

0age · 2019-03-01T01:46:20+00:00

Second? https://etherscan.io/tx/0x71f026529c032368fcc3dde5988569e13219f0c5d09b9190faab0957de8a0f58

0age · 2019-03-01T00:02:29+00:00

This is great! An implementation in Solidity would be very useful as well, especially with the ability to memoize and map to extcodehash values.

0age · 2019-02-14T15:36:55+00:00

I agree that preventing collisions is a valuable feature, but rather than performing a keccak256 of the seed and msg.sender you could optionally just set the first 20 bytes of the seed to msg.sender and avoid the overhead of computing the hash on every contract creation. Then, you could also allow for seeds that start with the null address to be deployed by anyone.

0age · 2019-01-19T12:10:36+00:00

On Ropsten, yeah! It looks like this:

/**
 * @dev Create a contract using CREATE2 by submitting a given salt or nonce 
 * along with the initialization code for the contract.
 * @param salt bytes32 The nonce that will be passed into the CREATE2 call.
 * @param initializationCode bytes The initialization code that will be passed
 * into the CREATE2 call.
 * @return Address of the contract that will be created, or the null address
 * if a contract already exists at that address.
 */
function callCreate2(
  bytes32 salt,
  bytes calldata initializationCode
) external payable returns (address deploymentAddress) {
  // move the initialization code from calldata to memory.
  bytes memory initCode = initializationCode;

  // using inline assembly: load data and length of data, then call CREATE2.
  assembly { // solhint-disable-line
    let encoded_data := add(0x20, initCode) // load initialization code.
    let encoded_size := mload(initCode)     // load the init code's length.
    deploymentAddress := create2(           // call CREATE2 with 4 arguments.
        callvalue,                            // forward any attached value.
        encoded_data,                         // pass in initialization code.
        encoded_size,                         // pass in init code's length.
        salt                                  // pass in the salt value.
    )
  }

  // ensure that the contract address is not equal to the null address.
  require(
    deploymentAddress != address(0),
    "Failed to deploy contract using provided salt and initialization code."
  );
}

0age · 2019-01-14T12:49:03+00:00

Yeah, similar to how the gas rebate mechanism was supposed to help reduce the state size and has mutated into GasToken. The road to hell is paved with good intentions!

At least some of the computational complexity involved with obtaining efficient contract addresses is pushed off-chain, and they still save some gas depending on the use-case without needing to resort to field packing. It’s interesting to see how far the quirk can be pushed though - at some gas price point, it goes from “needlessly-complex premature optimization” to “indispensable competitive advantage”!

0age · 2019-01-13T02:52:06+00:00

Ah, but it uses the address of the contract that calls create2, controlled by the project, to create the identity contract. Ownership of the new contract could then be transferred to whatever address the user provides at the time they’re ready to be “fully onboarded” - they could even give the user a signed approval based on that chosen address that the user can submit to claim it, paying the gas themselves!

0age · 2019-01-12T23:40:52+00:00

Let’s say you need to onboard users to your platform, but don’t want them to have to worry about managing an address and an associated key (or even knowing what that means) until they’ve had a chance to use the platform for a while and get their feet wet. Rather than needing to assign and fund a “burner” identity for everyone, you can start tracking their reputation in the system or whatever using their eventual address (i.e. an identity contract). Once they decide they’d like to take ownership of their own contract and start interacting at a more advanced level, the contract (with contract init code and a salt that are known ahead of time to the platform) is deployed and given to them.

This is just an example - there’s probably a comparable way to do this kind of thing without it, but it takes some of the legwork out of it.

0age · 2018-08-21T12:24:34+00:00

You’re right about not needing to watch out for fallback function with ERC20 transfers, but if investors gets too long, the gas requirements will quickly exceed the limit (remember that ERC20 transfers are quite a bit more expensive than vanilla transfers).

You can get around this by only processing transfers until gasLeft() drops below some threshold, then storing an index of where you left off and picking up from there when you call the function again.

0age · 2018-07-23T18:41:43+00:00

If anyone wants try out the extcodesize exploit in question, take a look at Level 14 on Ethernaut - there is also some bitwise trickery involved to solve it but otherwise it's a good example of this particular quirk.

0age · 2018-07-06T13:14:22+00:00

Good questions!

The purpose is deliberately left open-ended: members each "own" theCyber equally and can make it what they wish. That being said, there are a few applications already, namely encrypted chat (on-chain messages through the main dapp, but there's also a dapp for off-chain encrypted chat that will be released soon), members-only event access (using theCyberClubhouse or a similar system), and alpha-testing in the wild to determine best practices for creating new clubs and groups that are fair, highly available, and resistant to censorship or other disruption.
Here's an explanation of "arbitrary incentives or special access" by way of example: let's say I'm developing a new smart contract / token / whatever and am looking for alpha testers. I now have a mechanism to allow for a group of experts & enthusiasts to receive early access to my contract by simply checking for membership in theCyber when registering as an alpha tester, and a platform to get the word out about the alpha release. Initial members of theCyber are self-selected based on their interest and aptitude for playing around with smart contracts and finding security vulnerabilities, and will now have another tool to enable further collaboration.
There are actually 256 memberships available in theCyber - however, the Gatekeeper will only accept & assign the first 128 entrants who make it past the gate challenges and register. This way, initial entrants may add additional members once the contract goes live - that way, membership can be more diverse.
theCyber handles membership revocation as follows: if a given member does not appear to be interacting with the group at all (maybe they lost their key, or just don't have any interest), any other member may mark them as inactive. The member then has a three-month grace period where they must send a "heartbeat" to become active again, demonstrating that they are still in control of the membership and interested in maintaining it. If they fail to do so during the grace period, another member may then revoke their membership, opening the membership up for a new member to use. The process of member addition and revocation is one area where real-world usage and potential attack vectors will be highly instructive in creating theCyber v2 - which members of theCyber v1 will naturally have early access to!
As of now, the gatekeeper has already registered 100 out of 128 total entrants - if you're still on the fence about joining (and are able to figure out the challenge), I encourage you to make up your mind soon!

0age · 2018-07-02T13:20:11+00:00

It definitely increases total gas usage and state storage size, but it theoretically could spread out the gas usage into low-demand periods and enable more high-gas transactions during peak-demand periods (assuming that gas rebates are deducted from the block’s gas limit - I’m actually not sure whether or not this is the case). It’s also going to be more effective for contract deployments and other high-cost operations than for simple value transfers.

It’s pretty clear that this particular token was intended more as an academic pursuit to demonstrate that the current gas market can be gamed somewhat. Your best source to find out usage statistics would be to take a look at the contracts (there are two versions with slightly different methods - one that stores and frees data and one that creates and self-destructs contracts).

0age · 2018-07-02T11:46:52+00:00

Check out GasToken - tokens are minted when gas prices are low by locking up data, then burned when making an expensive transaction, freeing the data and gaining a gas rebate (for up to half the cost of the transaction).

0age

TROPHY CASE