hicetnunc microfunding protocol
hicetnunc.xyz is a decentralized application which implements a micro funding protocol, where open sources of events can take place, working as an DeFi experiment, towards different economical arrangements.
It empowers open sources of will to manifest themselves, intervening in virtual realities. It’s an open source project and all it’s code is available for discussion, contributions and insights.
Novel
Some of its underlying characteristics:
- Users’ are able to publish a micro funding smart contract, query for existing ones, and contribute to them.
- Users’ are able to connect to the application with mobile wallets and/or browser extensions.
- Each contribution to a micro fund generates a hicetnunc#<token_id> in a 1:1000000 ꜩ rate.
- Each hicetnunc#<token_id> can be used as it’s pleased. It can represent reward points, tickets, being possible to exchange them among other token economics abstractions.
- Each opensource generates a unique hicetnunc#<token_id> branch.
- Each micro funding costs 2 ꜩ~ to be published, while optimization strategies is a research theme itself. No additional fees are charged.
- Each micro funding should take at least 45 days before moving funds, being possible to set a goal, while there are no actual limits for contributions. During these 45 days and beyond the amount of ꜩ collected from a microfund is delegated to a baker, contributing to the network’s health.
- Each micro funding should be able to share informations about the project, as title, description and links. Those informations would be stored with IPFS.
- It’s protocol is updatable and interacts with a FA2 Token Standard instance. It’s design strategies is greatly influenced from Interoperability Proposals from the Tezos community (tzip10, tzip12, tzip16 and tzip18).
- The dApp was designed within a set of serverless and micro services architectures and DevOps practices, interacting with decentralized infrastructures such IPFS, Infura, Matrix Protocol (Beacon) and Tezos Cloud Providers.
It’s architecture can be seen in the image above. Most of its smart contracts were written in SmartPy 1, and it’s source code is available here.
Features intended to be implemented in future updates are related to user connectivity from applications such as Thanos Wallet 1, Magic 5, as well supporting a variety of other smart contracts such as multisig wallets and blockchain domain names.
We are also looking forward to developing tools and smart contracts that enable these DAOs to provide services for it’s token holders.
The protocol supports invitations for users which don’t have ꜩ, making it possible for new users to engage with the community.
As it is, the protocol is upgradable in parts, which is something that is open to be discussed with the community. Funds can only be accessed by the administrator of each DAO. Oracle’s entry points might be updated to achieve an automated architecture.
It’s intended to allow interaction with social media from it’s UI, possibly determining a feed based on engagements.
Carthagenet Samples:
FA2: KT1B5RfkR1Vvfmm8pwFVFuL3Gqttwo6TYHtP 1
hicetnunc_protocol: KT1UzXFWhEGD8oGWbt27gaLkUgSb2GW8D51y
hicetnunc_opensource: KT1CLetqvA4p6kt6oVxgfSj9gfhbTNk8eHio 1
Smart Contract and Infrastructural Architecture
There are some other infrastructural thoughts to be shared. Minimal interactions are required from the user, which triggers different states of the application. Meta transactions are forged and sent to an user to be signed in such cases.
Sequence diagram 1 — backend and connectivity
Operations are forged using information such as KT address, address, parameters and network.
This allows one to implement an API which forges different operations for a specific smart contract design.
The user interface code repository can be found on hicetnunc 3. Users are able to sync and interact with this decentralized application from AirGap wallet, using sign payload 2 methods.
The off-chain worker (ungrund) is built with pytezos and it’s a microservice that supports users’ interactions. It forges transactions, interacts with other microservices (hesychasm), retrieving and inserting data from smart contracts.
Sequence Diagram 2 — smart contracts architecture
We are looking into making it as decentralized as possible. A lot of thoughts also came into our mind concerning the possibility of having an upgradable protocol for such dApp (core protocol and smart contract temporalities?). Still, such experiments can serve as a reference and other consequences can be derived from it. Comments are welcome.
This project is a Fourth Cohort Grantee 3 from Tezos Foundation, being in continuous development/research.
twitter: @hicetnunc2000
