It is required to update the naming contract in order to support the referral system. Unfortunately I couldn't upgrade the new naming contract correctly.

Enhance the naming contract as part of the upgrade to Cairo 2 from Cairo 0, focusing on code optimization and comprehensive testing.

• Remove braavos functons
• Fix duration overflow
• Fix booking if possible?

Add affiliation tracking feature

If you have auto renewal enabled on a domain, you should be able to renew it for free for 3 months.

Check https://app.skiff.com/drive/file/d38b961b-24a7-4016-a869-aed62cedae69 for more details

The goal of this contract is to allow users to opt in an automatic renewal process. They will give an infinite ETH allowance to the contract. This contract can be called by anyone to renew the domain of someone who opted in and use his funds to do so. It should ensure that the domain is expiring soon and the renewal would be of maximum one year.

Is your feature request related to a problem? Please describe.

We want to add a domain resolving hook/script to all the starknet libraries out there. We already worked on starknet.js, Starknet React and Starknet-rs.

It's now the time to do it in starknet.py.

These hooks permit to easily access a .starkdomain with the address and conversely.

Describe the solution you'd like

Make a PR in the https://github.com/software-mansion/starknet.py repo following their repo rules and recommendations.

Add a domain_to_address function and a address_to_domain

• Verify recent updates to naming_contract
• Disable small renew
• Disable small purchase
• Check if expired to see if a starknetid contains a domain
• Remove whitelist related code
• Try to upgrade on testnet
• Upgrade on mainnet

Code the pricing contract in cairo 1 and change the prices

Problem

https://github.com/starknet-id/naming_contract/blob/8d7f4b7a06b895df1d612e9ae739d09502e1dd80/src/naming/registration.cairo#L60

Here, you execute transferFrom on ERC20 without checking for balance. So if the balance is not enough, it throws error on wallets when estimateFee is called by the wallets. OZ's ERC20 contracts doesn't show errors properly. So it becomes very difficult for the wallets to handle it and users to know what the actual error is.

This is what the error looks like:

Error in the called contract (0x6ac597f8116f886fa1c97a23fa4e08299975ecaf6b598873ca6792b9bbfb678):
Error at pc=0:15:
Got an exception while executing a hint.
Cairo traceback (most recent call last):
Unknown location (pc=0:214)
Unknown location (pc=0:200)

Error in the called contract (0x6ac597f8116f886fa1c97a23fa4e08299975ecaf6b598873ca6792b9bbfb678):
Error at pc=0:178:
Got an exception while executing a hint.
Cairo traceback (most recent call last):
Unknown location (pc=0:2822)
Unknown location (pc=0:2800)
Unknown location (pc=0:1712)
Unknown location (pc=0:1380)

Error in the called contract (0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7):
Error at pc=0:104:
Got an exception while executing a hint.
Cairo traceback (most recent call last):
Unknown location (pc=0:1678)
Unknown location (pc=0:1664)

Error in the called contract (0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7):
Error at pc=0:9:
Got an exception while executing a hint.
Cairo traceback (most recent call last):
Unknown location (pc=0:1434)
Unknown location (pc=0:1395)
Unknown location (pc=0:915)

Traceback (most recent call last):
  File "<hint1>", line 3, in <module>
AssertionError: assert_not_zero failed: 0 = 0.

Possible Solution

I would suggest to check for balance before doing this transferFrom and use an assert statement with with_attr error_message to display correct message.

purchased

Create a contract that will help our partners project for subdomain delegation (Speak with gabin and Iris about it to make sure the contract fill their needs).

UPDATES :

Here is what the templates should have:

Front-end ==> A cool Front end that is easy to replicate for almost every branding (one image + Three colors) + an Next.js API that permits to verify whitelist easily (It's centralized but after all the whole processus of whitelisting is centralized so that's not a problem to me).

Contract ==> Two contracts, one that enables everyone to mint and one that is a WL. The contract will be tested in testnet but no unite tests needed cause the complexity is in the naming contract, not in the delegation contract.

Test the Mint from L1 contract and make sure it's ok !