Hicetnunc microfunding protocol

DApps
, ,
1

This decentralized application implements a micro funding protocol, where open sources of events can take place, working as an DeFi experiment, towards different economical arrangements.

Anyone, whichever community, can connect with it. Within it’s user interface or within the Tezos Blockchain. 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.
  • 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 microservices architectures and DevOps practices, interacting with decentralized infrastructures such IPFS, Infura, Matrix Protocol (Beacon) and Tezos Cloud Providers.

1600×900 19.4 KB

It’s architecture can be seen in the image above. Most of its smart contracts were written in SmartPy, 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, Magic, 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

hicetnunc_protocol: KT1UzXFWhEGD8oGWbt27gaLkUgSb2GW8D51y

hicetnunc_opensource: KT1CLetqvA4p6kt6oVxgfSj9gfhbTNk8eHio

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.

1432×874 8.57 KB
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. Users are able to sync and interact with this decentralized application from AirGap wallet, using sign payload 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.

1442×814 11.1 KB

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 from Tezos Foundation, being in continuous development/research.

Best,

Rafael Lima.

Head Developer.

@hicetnunc2000

hicetnunc2000@protonmail.com

8 Likes
2

The presentation is very abstract and I am having trouble understanding what the end goal of this project is.

A demo or an example would help me understand the project better.

3 Likes
3

Thank you for your concern. It seems to me that this piece is an important guide for developers in the Blockchain context for thinking smart contracts and dapps architectures. Some primitives of DeFi and DAOs were intended to be proposed and discussed, which indeed carries some game theory abstractions. I do agree though that user experience is an important way to grasp an idea, and such concern will be addressed in a near update.

Some points that I could highlight to reduce it’s apparent complexity is that design choices were made so it could offer you familiar tokens functionalities to the ecosystem, exploring their potentialities, resulting in a low cost infra (costing around 2tz to publish a DAO, while FA1.2 and FA2 costs 4tz+). (Such details can be seen on section “Carthagenet sample”), aswell enhancing PoS. It is important to notice that such infrastructure doesn’t charge any fees besides the ones established by the governance of Tezos Public Blockchain.

As such an important objective of this project is to empower users with reliable blockchain infrastructure from the Tezos Ecosystem.

If I still may add, I foresee the following use cases as examples:

  • events can use such system to collect funds and verify tickets
  • live streamers/artists can generate DAOs and establish rewards
  • tourism agents can use such system to book visits
  • funding for projects and governance experiments
  • other credit or token logics
  • potentially marketplaces to support a DAO

I encourage any projects that have such interests in common, and beyond, to engage with what is being documented to help empower such DAOs.

Best,
Rafael.

5 Likes
4

So if the system is extensible, do you envision a situation where the protocol could evolve into a system similar to an opt-in on-chain treasury/ DAO? That’s the first thing that came to mind for me.

This is how I see it happening:

Say you had a large group of XTZ holders coordinate and transfer their XTZ to a single contract that delegates to a baker (virtual, public, or private) with the expectation that the cumulative total of baking rewards earned during a set period of time would fall under ownership of the DAO. After a pre-determined number of cycles pass, all who contributed would be returned their XTZ automatically, and be credited with a token (could be transferrable or non-transferrable) that gives an address holder the right to vote on XTZ distribution contingent on the number of tokens they hold. The original distribution, or permanent distribution if non-transferrable, of tokens would be assessed based on the contributed stake weight during the original time-lock.

Then going forward, these tokens give an individual a proportionate say as to where and for what the XTZ held within the DAO can go towards. (Philanthropic, to support developers, perhaps even putting the XTZ into a CDP like Kolibri whenever it comes out).

What are your thoughts? I feel like this is the way towards an on-chain treasury that the community can govern.

Sort of related reading: https://medium.com/@arthurb/potential-design-for-a-simple-and-evolvable-on-chain-treasury-77cfe2176423

1 Like
5

Thank you for joining the discussion. I have been revisiting the smart contract code and somethings were insightful.

Concerning extensibility I’d like to remark some points: It’s a difficult design decision to have influence on keys which are related to the smart contract administration. I’m tending on leaving it’s existence independent from anyone. To better describe this point: the protocol automates the relationship between DAOs and the FA2 contract, working as a ‘granular administrator’, as a college shared in an impression, which holds control on minting, and that’s it. From that, token owners are able to trade those tokens or give allowances. In such way I believe that this extensibility might be able to be achieved by other means.

As it’s mentioned in the article you shared, a generic architecture is an interesting approach while dealing with public infrastructures on blockchain, it was something that was constantly on my mind while designing it so it could be used by crowdfundings, philanthropy agents etc. It seems that it’s of the nature of smart contracts and tokens to be res signified as it’s pleased, leading to this variety of use cases for such tokenization protocol.

I didn’t knew about Kolibri, but I do think such protocol could be used for educational institutions. For example, if you want to get a seminar, you would need to have some credit for such, being possible to set refunds policies and other verification processes related to such DAO token.

The development of smart contracts to support those scenarios is something that we are also interested in taking part (:

Concerning staking: the initial timelock was intended to respect a cycle. Now I’ve been thinking of having those locks and some windows for withdraw from this post. the baking rewards you mention could be possible to be achieved by the following path, as I see: the administrator of the DAO should be another smart contract, which should be designed to manage those withdraw windows. You could set such adm while generating the DAO, possibly aswell the baker? Other extensibilities would deal with FA2 tokens. If any bakers have ideas about such subject, it would be great to hear about it.

Technologies for upgrading a smartcontract is something that are actually really complex (thinking about hicetnunc protocol). It seems possible to export an storage, or a bigmap, for another contract, with other smart contract logic. There might be other ways of achieving this on chain. I’ve thought sometimes of releasing it and cloning it’s storage by offchain means (references on that would be interesting), for update scenarios, but as I commented earlier, I’m tending to leave this responsability to DAO administrators, possibly allowing them to update this role aswell and other data in their scope only.

1 Like
6

Thanks for the reply.

Could you elaborate a bit on your comment about leaving admin keys independent? Not sure I follow but I’m interpreting it as after the formation of the DAO, no one can edit the contract underlying it. Which, I tend to agree is the best course of action from a decentralization standpoint. If those participating in the DAO decide they want to upgrade to a new contract later, they could always vote to move funds into the new DAO and begin anew without the risk of administration keys.

I’m also maybe misunderstanding what you’re talking about in regards to mint functionality. With hicetnunc the goal is to work together to form a DAO that can issue tokens? Then these tokens are used for whatever the DAO wants them to be used for? In the example I’ve described, I imagine that any transferrable token that the DAO would emit would represent a stake-weighted proportional voting right for disbursement of the funds. This would allow new participants to govern the DAO, but could also end up being a way for the DAO to dissolve and disperse held funds. A cool thought experiment.

Cool to know that you intend for the time-lock to be variable. The way I think about it is that those participating in the DAO would rather the DAO be well capitalized otherwise what’s the point? So an extended time-lock would result in more baking inflation reward XTZ donation to the DAO’s holdings.

So long as there’s a module in place to change delegations via vote, I don’t think that it particularly matters if a/ which Baker were the one to instantiate the DAO, but it would probably help them bolster their bakery’s delegated XTZ numbers. They’d probably make it so delegation can’t be changed, which is within their right as DAO launcher. Could be cool if it happened and then there was also a community started DAO that could switch baker and then they compete.

Kolibri isn’t out yet but the developers said it will be out soon. It will function similar to Maker’s Single Collateral Dai except that it has the ability to retain delegation rights built in. Its a cool project.

Reason why I mentioned it is because it could give a lot of financial power to the DAO provided it has significant enough collateral held within. They wouldn’t need to send off their XTZ, only kUSD (the Kolibri stablecoin), and with baking rewards constantly coming in they can keep their vault within a safe range of liquidation. Plus if XTZ were to go up in value, the DAO could sell off XTZ for kUSD directly and close out its loan position.

To summarize, the aspects of the hicetnunc protocol that I think will see a lot of use, are its ability to do time-lock based inflation donations to the DAO, and its ability to distribute a token to DAO participants. In regards the token it should somehow come with governance capabilities regarding the DAO’s XTZ treasury distribution, and a way to automatically distribute these funds in a transaction based on passing a threshold during an in protocol vote (examples of a vote = send 1,000 XTZ to tz12345… if greater than 50% of holders agree, or execute transaction to create kUSD vault under DAO’s ownership).

Features like this would allow it to be super flexible in terms of use case whether its philanthropic, capitalistic, whatever.

7

I’d like to share some updates on the project. It’s currently live (on mainnet) but as an unstable version at hicetnunc.xyz

It first came to live at nov 12. At nov 26 we’ve activated the update metadata entrypoint, where the administrator can update an IPFS cid hash. We have a simple template for it holding informations as DAO name, DAO description and a linktree. Other sorts of contents could be added with other template versions.

on nov 28 we’ve activated our staking oracle, which is an update from the previous version I believe.

A DAO administrator can set a baker for it’s funds or an oracle can set those in case one doesn’t assign it. We’ve not yet received staking rewards from it, and I believe it’s important to discuss a proper pattern for KT contracts receive transfers or staking rewards in such case.

We’ve thought of designs that would include, still, the possibility of minting NFTs from a DAO, or rather exchange DAO tokens with NFTs etc. We have a basic infrastructure for minting NFTs but we’re tending to consider it separately. As it’s well know NFTs can represent assets, and in our specific case we’ve been looking into experimenting with some media formats powered by IPFS infra (as it supports audio/video/sound/pdfs etc). hicetnunc.xyz/ipfs supports it already with a 10mb limit. Such has many use cases, as composing items/scenarios in games or even composing documents.

We’ll address a last report in January 2021.