2

For example, firefly.eth currently resolves to 0xce31f0ad68d9565004bbe351a8677eb74c86866d

Without my software knowing or looking up the specific address "0xce31f0ad68d9565004bbe351a8677eb74c86866d" before it creates the transaction (the way almost all wallet software supporting ENS does/will do), can I sign a transaction which sends funds from my externally owned secp256k1 account directly to "whatever firefly.eth resolves to" without knowing that information at the time the transaction is created? I dont want to send it to some type of custom built contract that first resolves firefly.eth and then forwards my funds to "0xce31..." once it obtains it. I want the funds to go directly from my account to "0xce31..." so that if "0xce31" checked the msg.sender it would consider the funds to have come from my account directly.

Is this possible?

Improve this question

3 Answers 3

Reset to default
1
+50

The answer is "no". You either need to resolve the address outside the chain (via web3 or whatever), or have an on-chain contract do it for you.

If the hard requirement is that msg.sender is your address, then you would need to resolve the address via an off-chain solution.

Improve this answer
1
1

I dont want to send it to a contract that first resolves firefly.eth and then forwards my funds to "0xce31...", I want to send from my account directly to "whatever firefly.eth resolves to".

I think you are misunderstanding how the ENS system operates, because it actually works like you want it to, to the best of my knowledge.

The way the ENS system works, the ENS public resolver doesn't actually forward funds as part of name resolution, the contract only holds the database which off-chain code can use to resolve ENS names. This means that firefly.eth gets converted to 0xce31... before your funds even leave your wallet.

When you send funds from your address to an ENS name, the following happens, as an example:

  1. You type "firefly.eth" into the destination field on your wallet and send 1ETH to it.

  2. Your wallet runs the addr function of the public ENS resolver contract (after hashing the address) to resolve firefly.eth to 0xce31....

  3. Your wallet signs and sends a transaction for 1ETH directly to 0xce31... without any middlemen, forwarding, or any more contract code.

So your funds themselves never go through any contract. The ENS resolver contract is used in resolving the final address, then your funds go there directly.

For more information on how ENS name resolution works, check out the ENS paper.

Improve this answer
7
  • Look, I understand how ENS works. I'm not under the impression that the ENS resolver is a forwarder or anything like that. And I know that right now most wallets simply do the resolving clientside before forming the transaction. That is explicitly not what I want, which is why I clarified that. What I could also do just fine is write my own forwarding contract that does do the lookup and then forward the funds to the resolved address. But I don't want that either, because the call to 0xce31... would be coming from the forwarder instead of from the EOA.
    – Jeff Coleman
    Commented Jun 10, 2017 at 18:08
  • This is a much more technical/lower level question than just about the workings of ENS. Imagine a hardware wallet trying to be sure that a given transaction is going to firefly.eth for example. How can we write a transaction that guarantees this without routing through a forwarding contract which would change the msg.sender? That is my question.
    – Jeff Coleman
    Commented Jun 10, 2017 at 18:20
  • @JeffColeman To the best of my knowledge there is no way to send money from a contract and have the msg.sender show an address other than the contract address. As far as a hardware wallet being sure that a given transaction is going to firefly.eth, the hardware wallet would either need to be a full node itself (to be able to verify the ENS public resolver contract state) or trust the software running on the computer it's plugged into to do the ENS resolution properly. If you have a Trezor/Ledger, I think that you just can't send to an unresolved ENS name and have it be fully trusted.
    – Maximillian Laumeister
    Commented Jun 10, 2017 at 18:20
  • @JeffColeman Other than that you would still need a forwarding contract, if you want the ENS name to be verified on-chain. Edit: Hopefully someone else will prove me wrong.
    – Maximillian Laumeister
    Commented Jun 10, 2017 at 18:21
  • If true, the answer to this question will be no. (which is what I'm thinking, although I asked this question to be sure). And that's quite unfortunate, because from an evidence perspective, there's no reason we can't do this--it's just a technical gap. In fact, more generally being able to attach multiple actions or true/false asserts to a transaction would make things so much better for a variety of needs.
    – Jeff Coleman
    Commented Jun 10, 2017 at 18:24
0

I recently built something that allows you to do exactly this, namely you can resolve ENS names in a single transaction without having to do a read to resolve it yourself https://www.npmjs.com/package/ens-proxy-sdk

Improve this answer
2
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review
    – thefett
    Commented Mar 15, 2022 at 14:42
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Mar 20, 2022 at 9:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.