Conor Svensson (csvensson.eth) pfp

Conor Svensson (csvensson.eth)

@csvensson

65 Following
31 Followers
Conor Svensson (csvensson.eth) pfp
It's an uphill battle getting people to care about #smartcontract naming with #ENS. There is no precedent for it, so no-one does it. Yet #Ethereum #UX completely sucks for users if they are shown a hex contract address. @enscribe_ is creating a new category of product for Ethereum — decentralised trust for smart contracts via naming and verifications. Which effectively I want to end up being the equivalent of a #TLS padlock for Ethereum apps. Being first in a category can be great, as you lead the conversation, but it's also hard as most people don't give a shit about what you're trying to do. We're not building something that will make people rich, we're building something that will make Ethereum safer and improve UX. Having, lasting positive impact in Ethereum is what matters to me, not trying to profit as much as I can from it. ctd 👇
1 reply
1 recast
3 reactions
Conor Svensson (csvensson.eth) pfp
Hey everyone, wanted to share @enscribe with the community. With Enscribe, we're addressing a fundamental problem faced by nearly every Ethereum user: confusing and unreadable smart contract addresses. Enscribe makes it easy for developers to name their smart contracts using their #Basenames. Using the Enscribe app, available at https://app.enscribe.xyz, you can deploy new contracts with Basenames set automatically, or locate and name your already deployed contracts with them. For instance, using Enscribe we configured our own contract primary names at - v0.app.enscribe.base.eth - v0.app.enscribe.basetest.eth You can also view information about Basenames in Enscribe with the search, such as @jessepollak's at https://app.enscribe.xyz/explore/8453/0x849151d7D0bF1F34b70d5caD5149D28CC2308bf1 Our mission is to eliminate hex from the user experience, and we’d love to see the Base community using their Basenames to name their contracts!
0 reply
0 recast
1 reaction
Conor Svensson (csvensson.eth) pfp
0 reply
1 recast
2 reactions
Conor Svensson (csvensson.eth) pfp
1 reply
1 recast
1 reaction
Conor Svensson (csvensson.eth) pfp
1 reply
1 recast
2 reactions
Conor Svensson (csvensson.eth) pfp
0 reply
0 recast
0 reaction
Conor Svensson (csvensson.eth) pfp
At @enscribe we believe in establishing a new norm for contract deployments. Currently when #smartcontracts are deployed on #Ethereum, @base, @linea and other networks, they should be verified and audited for the sake of users. But this information is not readily available to users without doing their own research. With Enscribe we want to provide users of smart contract applications with the confidence that what they are interacting with is safe — the check-mark if you will for applications. There are three components to this. The first two, verifying and auditing their are already embraced by teams, but the information is not easy to surface for users. There are three primary platforms for smart contract verifications — @SourcifyEth, @blockscout and Etherscan. If a contract is verified on one of them this should be readily surfaced for users. Hence this is something we now show in the Enscribe app. https://app.enscribe.xyz/explore/1/0xD14360D477EF49182B5141952FE67b007688725A ctd 👇
1 reply
0 recast
1 reaction
Conor Svensson (csvensson.eth) pfp
With @EthCC on the horizon, the @enscribe team is pumped about having loads of IRL conversations with the #Ethereum community. We'll have great new announcements in the run up, but DM me if you want to chat on contract naming with #ENS or how we can make smart contract apps safer for users. We want to ensure that Ethereum is the safest #web3 ecosystem for users, whilst staying true to its decentralised promises. There are 3 core tenants to achieving this for smart contracts following deployment: 1. Name your smart contract with an #ENS name 2. Verify your smart contract with a service such as @SourcifyEth or a block explorer 3. Provide audit data to your users If all smart contract apps can comply with each of these we believe web3 starts to become safer, whilst also improving #UX. It is win/win for us all with technology that is available right now. Enscribe simply pulls it together to make it easier for developers to do. 🫡
0 reply
1 recast
2 reactions
Conor Svensson (csvensson.eth) pfp
All contracts should have have ENS names. This is our thesis at @enscribe. We want to make it as easy as possible for developers and users to name contracts. Any barriers we encounter along the way are: 1. Validation that we're focussing on a problem worth solving. 2. Stretching the team to find ways to address these barriers. Case in point. There are limitations in the ENS protocol with respect to being able to resolve contract names just from their address. We want to see this fixed for @namechain, so we've started engaging with the community on this point specifically. https://discuss.ens.domains/t/approaches-to-support-setting-primary-names-for-all-contracts/20919 #Web3 is still being built, which is what makes it so much fun to be a part of. There's tons of opportunities to find ways to contribute to it. You just need to go deep to find that area. For us its enabling #smartcontract naming with #ENS and increasing trust for users but keeping it decentralised. What do you want to see solved? 🫡
0 reply
1 recast
2 reactions
Conor Svensson (csvensson.eth) pfp
1 reply
1 recast
2 reactions
Conor Svensson (csvensson.eth) pfp
Even obvious solutions to significant problems take a lot of time and effort to build momentum around. Everyone we speak to about @enscribe agrees that getting smart contracts named with #ENS seems like a no-brainer. There are some differences of opinion in the best way to achieve, this. But fundamentally we need a change in behaviour. If we were to incentivise behaviour with a token, I'm sure it would accelerate this process. However, I'd question whether any token economic model around this problem really makes sense. The last thing we want is to create a short-term incentive to address a problem, that ultimately people loose interest in. Contract naming has to become normalised. It's inevitable, but for something inevitable to happen, often it requires a lot of hard work and commitment by a dedicated few. The premise is simple — eliminate hex contract addresses and replace them with ENS names. Improving UX and security for all users of Ethereum. ctd 👇
1 reply
0 recast
0 reaction
Conor Svensson (csvensson.eth) pfp
One of the areas we're currently thinking about is how we can better display information about proxy contracts to users. When users are signing transactions, it is not differentiated if the contract they are interacting with is a proxy or not. This doesn't necessarily matter if you trust the source of the app. However, if the user wants to see additional information about the app, it gets confusing quite quickly if they're looking at it in a blockchain explorer. Explorers do typically differentiate between the various types of proxies (which incidentally we wrote about a little while back https://www.chainlens.com/post/guide-to-proxy-contracts-on-ethereum), but its confusing for users. When someone uses the @enscribe_ contract viewer we want to make it clear if someone is viewing a proxy contract and understand how safe the underlying implementation is for them to look at it. ctd 👇
1 reply
1 recast
3 reactions
Conor Svensson (csvensson.eth) pfp
1 reply
2 recasts
3 reactions
Conor Svensson (csvensson.eth) pfp
There are effectively two types of #ENS name you can have for a smart contract using @ensdomains — a primary name and a forward resolving name. TLDR; you should always set the ENS primary name if you can. To understand why, keep reading.👀 A primary name is what you should have, this is where you have an ENS name that resolves to an address, and the address resolves back to the ENS name. E.g. For our @enscribe #smartcontracts, we have two records: - Forward resolving name: http://v0.app.enscribe.eth -> 0xD14360D477EF49182B5141952FE67b007688725A - Reverse resolving name: 0xD14360D477EF49182B5141952FE67b007688725A -> http://v0.app.enscribe.eth This means that http://v0.app.enscribe.eth is the primary name for 0xD14360D477EF49182B5141952FE67b007688725A, and you can see this in the Enscribe App at https://app.enscribe.xyz/explore/1/0xD14360D477EF49182B5141952FE67b007688725A. ctd 👇
1 reply
1 recast
2 reactions
Conor Svensson (csvensson.eth) pfp
Love the latest feature that has been shipped by the @enscribe team — our #smartcontract and address explorer. You can now enter any #ENS, wallet or contract address and see associated and owned ENS names. If it's a smart contract you can also see where the code has been verified. To the best of my knowledge there is no service for #Ethereum that provides all of this information in one place. It's not only live on Ethereum, but also @base and @linea. Check it out for yourself at https://app.enscribe.xyz/explore/1/0xD14360D477EF49182B5141952FE67b007688725A. What other information would you like to see here that will make Ethereum apps safer for users? Our end goal is that wallet providers start to integrate information from this page into them, to help inform users on the safety of the apps they're using.
0 reply
1 recast
2 reactions
Conor Svensson (csvensson.eth) pfp
1 reply
1 recast
1 reaction
Conor Svensson (csvensson.eth) pfp
0 reply
0 recast
3 reactions
Conor Svensson (csvensson.eth) pfp
The creation of @enscribe started with me asking the simple question, how can we provide something that's more like Heroku that enables developers to name their smart contracts at deployment. I always recall the novelty of when I first tried Heroku 10 odd years ago, seeing "quick-beetle-9451.herokuapp..." being deployed. Something similar for #smartcontract developers on #Ethereum seemed like a fun idea to explore. Our first iteration of Enscribe did exactly this — enabled developers to name their smart contracts at deployment. The thing is, developers already have their toolchains for deploying smart contracts, which made the initial proposition of Enscribe less applicable. Hence we then added the ability to name existing contracts, which enables users to name their already deployed contracts. And of course, along the way we added a Heroku name generator too which you can checkout at https://app.enscribe.xyz/nameContract. ctd 👇
1 reply
1 recast
1 reaction
Conor Svensson (csvensson.eth) pfp
0 reply
1 recast
2 reactions
Conor Svensson (csvensson.eth) pfp
Our mission at Enscribe is to make #Ethereum the safest blockchain for users. Getting #ENS names in front of users instead of hex contract addresses will be a huge step in the right direction for this. It's such an obvious upgrade, that I constantly find myself astounded that more people aren't prioritising this. People put up with the current #Ethereum #UX because they're either technologists, speculators or libertarians. Users outside of this camp will not come to accept hex addresses anywhere in the user experience. Especially as it exposes them to security issues such as address spoofing or poisoning attacks. We must do better. DNS names helped normalise access to web site, ENS will help normalise access to web3 apps. The other option is centralised services which hide smart contract addresses from users, but if we're ok with that, why are we building #web3?
0 reply
1 recast
1 reaction