โš™๏ธDetailed deployment Guide - WIP

If you have deployed on an EVM chain before, here a few additional steps you need to follow to deploy on Haven1 network

Direct link to Developer Tools that you might need to be able to deploy on Haven1

Step 1: Integration of Haven1's Standard Smart Contract for Upgradability and Pausing


Overview: Why Integration of Our Standard Contract is Critical

At Haven1, we aim to protect developers and users from potential risks by providing a secure and standardised smart contract structure. Weโ€™ve built a standard contract that ensures the upgradability of your dApp and allows for emergency actions such as pausing transactions in case of any detected vulnerabilities.

By integrating our standard contract, youโ€™re ensuring:

  1. Easy upgrades: Future upgrades or changes can be made to your smart contract without the need for a redeployment.

  2. Security monitoring: Our network partners (e.g., Hypernative) actively monitor your contracts and can pause transactions in the case of any detected exploit.

  3. Application fees: Integration of Haven1's unique application fee mechanism gives you a new monetisation option. (What is Application Fee?)


What You Need to Do

  1. Inherit Haven1โ€™s Standard Contract:

    • In your smart contracts, you need to inherit from our standard contract, H1DevelopedApplication.sol, which includes functionality for pausing, upgrading, and integrating fees.

    • Here is the link to this contract and here is the link to explainer for this contract

    • This ensures you meet Haven1's requirements for security, while also unlocking the features specific to our network.

  2. Steps to Inherit the Contract: You can integrate the Haven1 standard contract(H1DevelopedApplication.sol) by inheriting it within your own contract as shown below:

    solidityCopy codepragma solidity ^0.8.0;
    
    import "@haven1/contracts/H1DevelopedApplication.sol";
    
    contract MyDApp is H1DevelopedApplication {
        // Your contract code here
    }
  3. Upgradeability and Pausing:

    • Once your contract inherits from H1DevelopedApplication, it allows for automatic pause and upgrade functionality.

    • In case a vulnerability is detected by our monitoring systems (e.g., Hypernative), the contract can be paused to prevent further interactions.

    • Upgrades can be rolled out in a standardized manner, reducing the risk of having to redeploy your entire contract.

  4. Monetisation via Application Fees: Haven1 operates as a gasless chain, but you are offered the flexibility to implement application-specific fees to monetize your dApp. (Read more about Application Fees here)

    • You can configure function-specific fees. This can provide you with new revenue streams directly within your contract.

    • Important to note: 80% of the application fees collected will be transferred to your account, while 20% will go to the Haven1 network for maintaining infrastructure, validators, id verification etc.

    • Your 80% share of fees are passed to devFeeCollector address. This address should have completed KYC/KYB if it is an EOA. If this address is a contract then this contract's DEV_Admin role addresses should have completed KYC

    • Example:

    solidityCopy codefunction exampleFunction() public payable {
        require(msg.value >= applicationFee, "Insufficient fee");
        // Function logic here
    }

  5. When you submit your application to deploy on Haven1, you provide two addresses:

    • developer called out as Developer Wallet Address

      • This address will be assigned the DEV_ADMIN_ROLE

      • This role protects the functions that allow the developer to set function fees (setFee, setFees), along with the function that allows the developer to update the devFeeCollector address (setDevFeeCollector).

      • You can specify multiple addresses on the form in comma separated values

      • This address(/es) should have completed KYC

      • If you want to change the admin roles, you must reach out to us

    • devFeeCollector

      • The address to which earned application fees will be sent.

      • Does not have to be the same address as the developer.

  6. Example Contracts:

    • We have provided sample contracts here that showcase how you can integrate these features seamlessly. This can serve as a reference for developing your own contracts on Haven1.


Application Fee Configuration

  • Application fees integration is mandatory.

  • You can choose to apply 0 fees to some(or all) of your contractโ€™s functions, giving you the flexibility to charge for premium features/services

  • These fees are directed to the address that is declared as the devFeeCollector when the contract is deployed

  • Denomination: While fees are dollarized for users, they are paid in H1 tokens.


Resources for Developers

  1. Standard Contract Documentation:

    • Full documentation is available on how the Haven1Standard contract operates is here. Each function and feature is explained in detail to ensure transparency.

  2. Spotlight Apps:

    • Check out the Spotlight Apps here, where you can see live examples of how developers are using these features for monetisation and upgradeability.


By inheriting this contract, you ensure that your dApp remains secure and upgradable while giving you the opportunity to benefit from application fees. This also helps Haven1 protect against potential hacks or vulnerabilities that could affect the ecosystem.

If for some exceptional reason, you are not able to integrate H1DevelopedApplication contract, such as having a Solidity version as .6X or .7X, then do specify the same while submitting the contract for deployment (in Step 4)

Step 2: Mandatory 2 Audits


Why Audits are Mandatory on Haven1

Security is paramount on Haven1. We've observed that projects audited by reputable auditors experience significantly lower risk of hacks. To maintain the highest level of security on our network, we require all projects to undergo two independent audits before deployment.

This policy is designed to protect users and safeguard the integrity of the network by ensuring vulnerabilities are caught before contracts go live.

What You Need to Do

  1. Submit Existing Audits:

    • If you already have two audits completed on your most updated code, thereโ€™s no need for additional audits

  2. If you donโ€™t Have Audits:

    • You will need to arrange for two audits from recognized auditors.

    • Haven1 has formed an Audit Council to assist ecosystem projects in securing preferential rates and timelines with reputable auditors.

    • We also provide grants in certain cases to help cover audit costs. You can apply for a grant here if needed.

  3. Why Two Audits?:

    • Multiple audits ensure that different auditors assess your contract for potential risks, providing an extra layer of scrutiny.

    • By having two independent audits, we reduce the possibility of overlooked vulnerabilities and improve the overall security of the network.


Once you're ready with these, you can submit your contract and audit reports while submitting the contract for Deployment(Step 4)

Step 3: KYC/KYB Requirement for Developers


Overview: Why KYC/KYB is Essential for Haven1

Haven1 is built with a primary focus on user security and protecting against common risks such as hacks, scams, and rug pulls. A key factor in minimising these risks is ensuring the transparency of developers and applications built on the network. Just as all users must undergo ID verification (KYC) before transacting, developers who wish to deploy contracts on Haven1 must complete KYC (Know Your Customer) or KYB (Know Your Business).

This measure helps create an accountable ecosystem, ensuring that developers behind projects are verified and known entities. We are building trust with this foundation, and itโ€™s our way of fostering a safer network for all participants.

What You Need to Do

  1. Complete signup and KYC/KYB:

    • All developers wishing to deploy on Haven1 need to undergo KYB. In some cases, KYC may be acceptable depending on your situation.

    • Here is the KYC/KYB link where you can initiate and complete the process.

  2. Why Itโ€™s Important:

    • This step helps verify your identity and ensures accountability on the network.

    • Your KYC/KYB verification will be required before we can deploy your contracts on the network.

  3. Your data is safe and you will continue to be anonymous on chain

    • Your data is securely encrypted and stored by ID verification partner Synaps.

      • Synaps is GDPR compliant as well as ISO27001 certified and is using AWS to store user data. They encrypt this data in AES-256bits with a unique encryption key per file. And they store these Encryption keys on hardware security modules offered by Google. The data is kept for a minimum of 5 years according to the KYC/AML directive and can however be deleted at the user's request.

    • Your on chain identity is very much anonymous. Your ID data can not be linked to your wallet address

Step 4: Submitting Your Contract for Deployment by Haven1 Governance


Overview: How Deployment on Haven1 Works

Unlike most EVM chains where developers can deploy contracts directly, Haven1 takes a governance-based approach to ensure maximum security and compliance. This means that once your contract is ready for deployment, it must be submitted to Haven1 for review and will be deployed via our governance process. This ensures that only audited, verified contracts go live on our network, adding an extra layer of protection for users and developers alike.


What You Need to Do

  1. Finalize Your Contract:

    • Ensure your smart contract is finalized, audited, and fully prepared for submission.

    • Double-check that the contract you're submitting is identical to the version that was audited. This is crucial, as discrepancies between the submitted contract and the audited version could lead to security vulnerabilities and delays in deployment.

  2. Submit the Contract for Deployment:

    • Here is the submission link where you can request for contract deployment. You will be asked to fill in

      • Developer Wallet Address - Make sure this wallet has completed KYC

        • This should also be the same address you should have declared as DEV.ADMIN in H1Developed Application contract that allows you manage your contract parameters

        • This is ideally also the same address that is receiving any application fees you might have set on your application

      • Developer Application Fees Receiver Address

        • This wallet can be same or different from Developer Wallet Address

        • If this is different wallet address, make this this wallet as completed KYC

        • If this is the same entity as the developer, you don't need to do KYC again. Simply link this wallet into the KYC of Developer wallet by joining the 2 in Portal Settings here

      • Audit Reports(Optional) - Please provide URL to where audit reports can be accessed if the audits are completed - The contract matches the audited version. Preferably, provide the URL that is hosted on the auditors's website

      • Github repo of the contract

        • Please make sure all required Haven1 contract standards (e.g., application fees, upgradability) are integrated.

      • Email confirmation to

        • Please make sure this email is correct. We will be communicating with you on this email if there are some unresolved issues with your contract or to confirm the successful deployment

  3. Deployment Process (In the future, we plan to automate this process, but currently, deployment is largely manual)

    • Haven1โ€™s deployment process is governance-driven. Once governance team verify that your contract meets all requirements, your contract is ready for deployment

    • The Haven1 association will deploy your contract onto the network and assign the developer and devFeeCollector addresses as well as DEV_ADMIN_ROLE role per your asks

    • Deployment team will communicate to you with logs and contract addresses once deployment is complete


Key Points to Remember

  • Audit Consistency: Ensure the version of the contract you're submitting is the one that was audited. Any discrepancies could lead to delays or rejections.

  • Manual Deployment: Currently, contracts are deployed manually. This is done to ensure the highest level of security and compliance. Weโ€™re working toward automating this process in the future.


Next Steps After Deployment

Once your contract is live on the network:

  • Ensure that your dApp operates as expected and all functions work correctly.

  • Continue to submit any further upgrades or changes through the governance process for future deployments by going here



By following this process, you ensure your contracts are deployed securely and in compliance with Haven1โ€™s best practices. The governance-driven deployment system enhances the trust and security of all applications on the network.

In addition to this, Haven1 team will list your application in our hApp store so that users can discover your application easily

Step 5: Post-Deployment Monitoring and Best Practices


Overview: Managing and Monitoring Your Deployed Contracts

Once your contract has been successfully deployed on Haven1, there are some best practices and tools available to help you monitor and manage your contract to ensure it runs smoothly and securely.


What You Need to Do After Deployment

  1. Monitor Contract Performance:

    • After deployment, itโ€™s crucial to keep an eye on how your contract performs. Haven1 provides tools and dashboards for monitoring contract interactions and events in real-time.

    • You can monitor key metrics such as transaction volume, fee collection, and contract interaction history using our Developer Dashboard.

  2. Ensure Contract Upgradability:

    • Since your contract integrates Haven1โ€™s upgradability feature, make sure to have a plan in place for future upgrades. Any updates should follow the same process as your initial deployment: submitting changes, undergoing audits, and receiving governance approval for redeployment.

    • Having a robust upgrade strategy is crucial for long-term success and security.

  3. Application Fee Collection:

    • If youโ€™ve opted to integrate application fees, youโ€™ll receive 80% of the fees directly through the networkโ€™s fee distribution system.

    • You can monitor the fee collection and payout schedule via the Fee Dashboard, where youโ€™ll see how fees are being distributed between you and the network.

  4. Handle Contract Issues or Hacks:

    • In the rare case of a security issue with your contract, the integrated pausing feature will allow quick action. Should a potential exploit be detected by monitoring services (like HyperNative), your contractโ€™s transactions can be paused temporarily.

    • We advise you to stay vigilant and use our automated alerts system, which will notify you if there is any unusual activity with your contract.


Post-Deployment Support

  • Contact Us: If you encounter any issues post-deployment, our developer relations team is available for support. Reach out to us directly via our Developer Support Channel for help with any concerns or troubleshooting.

  • Ongoing Audits: For large-scale projects, consider scheduling periodic audits to ensure your contracts remain secure as the ecosystem and potential vulnerabilities evolve.


Summary: Key Points to Remember Post-Deployment

  • Monitor your contract regularly via the developer dashboard.

  • Plan for upgrades and ensure future changes are secure and auditable.

  • Leverage application fees for monetization and track payouts.

  • Use the pausing mechanism to protect your contract from potential threats.

Last updated