via GIPHY

Only a few hours have passed since the incident. After securing Santa, we placed him in the conference room and got our wardens to watch him and started the negotiation.

Santa was only given 2 choices this Christmas:

• We sell him out to Danny for the bounty on his head.
• He gives us the roadmap we asked for.

After a couple of hours negotiating with him back and forth we finally settled on a deal.

Santa gets:

• New drippy Santa clothes
• Freedom
• We pretend we haven’t seen him if Danny asks

HYVE gets:

• Roadmap
• A 10-pack of feastables OG bars
• Santa’s going to be externalising elves on HYVE starting next year (we never threatened him with the elves, haha, who would do that?)
• Santa still comes back next year (right? or you wanna get back in that conference room…)

There’s only one little problem in regards to Santa’s safety though, Feastables doesn’t deliver to Bucharest. That’s bad luck for Santa because he’ll just be watching Danny’s threat on repeat until they do.

via GIPHY

If you want to help Santa escape, get in touch with Mr.Beast and get a 10-pack of Feastables delivered to Bucharest. You have one month. After that we’ll just give him to Danny because he’s kinda talkative and it’ll be hard to work with him around.

Now, let’s see what Santa brought.

1-Year Roadmap

Below, I am going to share some of the things we have planned for 2023. The image below is an actual printscreen from one of our internal documents outlining the next iteration of HYVE we are building, a HYVE2.5 if you will.

Before we get into all that, however, I want to address two things in particular:

• We’ve accomplished a lot this year, yet we wanted to achieve more so to get to where we want to be we’ve built a blueprint for how HYVE should be developed moving forward.
• The industry has seen a lot this past year but I want people to acknowledge that blockchain is still in its infancy. We’re still a year and a half away from the 4th halving event, out of 32.

Bitcoin has undergone just a bit over 10% of its halvings, and ironically enough that’s actually in line with the percentage of internet users holding or using crypto. Even more ironic is that it also coincides with when the internet had its own dotcom bubble; at just a bit below 10% user adoption.

During the dot-com bubble Amazon had been launched for 6 years and trading for 3 of those when they famously dropped from a price of 107$ during the peak to a mere 7$ after (from 5.0 to 0.32 post-split adjusted) or a drop of ±93% in value. Post-split adjusted Amazon’s stock soared from 0.32 to ±10$ within the next 10 years, or double their previous ATH. Now, another 10 years later it’s trading at around 85$ after an almost 50% drop.

To further drive my point, I will only give one more quote and then continue with our clear to-do list:

“Most people overestimate what they can do in one year and underestimate what they can do in ten years.” — Bill Gates

Q1 & Q2: Building

For the first half of next year we will mostly be focused on building out the platform and implementing our vision for how a next iteration of HYVE should look like.

Before we go further, let me please explain why we call the next iteration of HYVE 2.5; in reality, this includes quite a complex and diverse number of changes brought to the platform, however, we continue to build on our existing codebase. We will actually discard some of it but more on that later.

HYVE3.0 is going to be rebuilt from scratch, it is going to be considerably more decentralised and also more robust and since we’re going to build it from scratch it will require some time. Until then, V2.5 is something that we can deliver within a reasonable timeframe and would constitute a good enough building block to grow an audience and have people actually joining the HYVE while we get our hands dirty with V3.

Q3 & Q4: Growing

Once HYVE V2.5 is live and stable, we will be moving most of our efforts towards growing the HYVE Brand, bringing more users to the platform as well as more employers.

This will be done through a combination of mechanics and marketing techniques; ranging from integrating every web3 company to reaching out to every web2 company and getting them to join the revolution.

It includes searching for and getting in touch with all the influencers and micro-influencers we can find that are freelancers or talking about freelancing so that we can get them to join our Ambassador Program.

This will all be done in-tandem and preparation for the release of V3 which will be a complete do-over of HYVE as a product.

Q1 & Q2: HYVE V2.5

• Integrating POAPs
  Remember verifiable diplomas, course attendance, workshop badges? POAPs.
• Integrating SBTs
  Soulflake is an amazing example. We agree with the philosophy. So we’re creating SBTs to act as resumes for people on HYVE. We’ll make a standard and open-source it so everybody can make us of them!
• Account Types
  Why do I have all these options I don’t need? We’re splitting accounts into seller/buyer.
• Fees
  In the early stages, we can either choose more money or more tasks. Only one of 2 options. We chose the latter. Fees are going down.
• Fiat Onramp
  The small difference of being able to sign up and fund a task immediately with your card. Get the same experience as on Fiverr.
• Easy Escrow & Contract Functions
  We are cutting out the bullshit and going back to first principles. An easy escrow system. That’s it. That’s what should be on-chain.
• Better Chats
  Discuss any details of your collaboration with the freelancer, and your team, without having to leave the platform. Since the fees are almost non-existent, why would you leave anyway?
• User Interface
  Bring the UI up to date, fix the bugs, arrange all details. Simplify the parts and bring them to a cohesive structure. Create a result that caters to more people, while being cleaner.
• Tools
  We’re adding the ability to create invoices, give and receive feedback, sort your tasks in an easier way, import your tasks from other freelance platforms and more.

POAPs

POAPs ( short for “Proof Of Attendance Protocol”) are important in the blockchain business world. They are badges that prove you have a degree, have taken a course, participated in a workshop and other very relevant things for a serious (and reliable) workforce platform.

Most importantly — they are verified, as opposed to a block of text anyone can write in their profile.

Goal

• Add a section for POAPs on your profile page.
• Show POAPs on the offer/job page, both for employees and employers, in the same container where “Bio” and the rest of info is displayed.

Benefits

• Validation of diplomas, courses, workshops and relevant events in one’s professional life.
• Having the academic side that is present in all major competitors, but lacks in HYVE.

Integrating SBTs

SBTs (short for Soulbound NFTs) are a type of non-fungible token that cannot be transferred or traded. They are minted to and can only be owned by a single wallet, making them unique and special. SBTs can be used to represent and manage web3 social identities and relationships in a secure and personal manner, without the risks of centralization or the influence of price speculation.

Above you can see a Soulflake example of an SBT. We’re thinking similar, but instead of greeting cards it will be resumes that people hold onto their wallets. The SBTs will have modifiable metadata so that you can continue to add onto your resume as you progress through your journey.

Goal

• Add a section for SBTs on your profile page.
• Show a link to your most recent resume SBT on the offer/job page, both for employees and employers, in the same container where “Bio” and the rest of info is displayed.

Benefits

• Validation of work experience, previous employers, duration of employment etc
• Can double-serve as on-chain proof-of-work; actual work, not mining blocks, which can then be used in tandem with decentralised lending platforms and such in order to qualify for a loan with a lower collateral rate or similar services.

Account Types

Currently, our website is not user-friendly because it does not prioritize actions such as posting or applying. Instead, it presents a lot of information and buttons.

On a collaboration/freelancing website like ours, it is common to have different account types for freelancers and clients. However, on HYVE, we currently only offer a universal account type.

While this was a quicker implementation and allowed us to launch the product faster, it does not provide the same benefits as having distinct interfaces, functionality, and options based on the purpose of the account. This can cause confusion and hinder user experience.

Goal: Implement Employer/Employee account types.

Benefits

• Faster time to post a task or apply to one.
• Better codebase structure as we add more type-specific features and the complexity increases.
• Less user complexity (not thinking what to press, looking for things).
• Familiarity.

Fees

This one will be a bit shorter. We’ve experimented the entire year of 2022 with various fees to find the best way, and we think we found it.

We’ve even considered having a 0 fee across the board. Some fee, however, is beneficial for a couple of reasons:

• Protocol incentives
• Fighting spam
• Sustainability without transforming the user into the product (see Facebook)

Without further ado, below you can find the updated fee model, which reduces both developer and user complexity.

Fee Model:

• 2.5% fee for paying in any token (same as OpenSea)
• 0% fee for paying in HYVE (same as Taobao’s model that killed Ebay, which is 0% across the board)

Fiat Onramp

The main difference between HYVE and Upwork is the blockchain integration. But there’s an issue. How do people pay for jobs, if they don’t hold crypto?

We want companies, web2 freelancers, and other professionals to be here. This makes us clearly see how payments on the blockchain brings additional issues related to adoption.

Escrow is NOT mandatory to post a task, but mandatory to start the collaboration with a freelancer (selecting a freelancer). If you trust the platform, there’s no reason not to escrow (unless you’re not serious, lack money, etc).

Goal: Implement Fiat Ramp On

Benefits

• easier to get web2 freelancers and companies using HYVE
• less friction

Easy Escrow & Contract Functions

The blockchain architecture for HYVE is too mangled and complicated, without any benefit. Posting tasks on Ethereum can cost even 50$ or more.

By using this architecture and doing many unnecessary things on the blockchain at this time, we do not receive any of the benefits, and instead only get the disadvantages.

HYVE uses blockchain for payments, that should be it. Right now that’s the only thing that makes sense.

So… We double down on payments, and update the architecture so that it plays nice with the rest of the architecture, not complicate it needlessly.

Changes

2 types of contracts will exist moving forward, Core and Periphery. The latter is a bare bones version of the first, being deployed on periphery (non-main) chains and having only the pay() functionality.

The contracts are controlled by an operator, a microservice that listens to changes on-chain and in the database, and processes transactions accordingly.

Core Contract

• Sits on a main chain (= a chain where you as an employer can deposit funds on)
• Contains different kinds of tokens
• Used to receive deposits
• Used to make payments
• Used to mark a deposit as refundable (refund)
• Used by employers to withdraw a refunded deposit
• Used to swap a token inside the contract to USDT (used when paying in USDT on another chain, different from the one funds were deposited on)

Functions

• pay() — used by the operator to send payment for a finished job
• deposit() — used by an employer for escrow
• swap() — used by the operator to swap a token in the contract to USDT
• refund() — used by the operator to mark a deposit as refundable
• withdraw() — used by an employer to withdraw a refundable deposit

Periphery Contract

• Sits on any chain that is not a main chain
• Contains only USDT
• Used to make payments

Functions

• pay() — used by the operator to send USDT for a finished job

Operator Service

• Calls swap(), pay(), or refund() on the Contracts
• When user requests a withdraw on Optimism, we send USDT to the employee and swap the tokens on the main chain (where they were deposited) to USDT.
• A user can request payment in USDT (on all secondary and main chains), or in the Token of the task (only on the main chain where it is deposited).

Steps (User Perspective)

1. Employer escrows funds on the chain he desires.
2. Employee is paid on the chain he desires from the big pool or USDT pool on that chain.
3. It is HYVE’s duty to bridge tokens around where needed in order to keep the Periphery contracts filled.

But we are only bridging USDT around, so that’s not really complicated compared to the current system.

How do we address current chains?

We can consider the chains that have been already added as “main chains”.

To reiterate, we can have 20+ chains as periphery chains, even non-EVM, we are talking about main chains above. The difference is that a periphery chain only needs a contract deployed, while main chains need backend implementation (1) and clutter the codebase producing no benefit (2).

The difference is that sending a payment requires a single action, and the interface doesn’t need to know anything about any chain. It displays a network selector to pick where you want your USDT sent. If you want the original task token, you select that option.

As an employee, you do not care what chain the task you are joining has been posted on, nor should that be a factor. It’s just a technicality that needs to be removed and abstracted away.

We only use blockchain to get the user’s address and for the deposit() contract call. Otherwise, as far as the user is concerned, HYVE behaves like a web2 platform that sends the payout to their wallet address instead of their bank card.

Goal: Remove redundant/unneeded blockchain stuff and use a simpler architecture.

Benefits

• Immensely improve the experience of users.
• Removes the chaos on both sides in relation to: what is handled through blockchain, what isn’t, what should I care about as a user, where does that bug come from and how hard it is for me as a developer to recreate it.
• Reduce the complexity of our codebase.

Better Chats

Missing a good chat feature means people have no way of communicating about the job.

How can you trust someone to do a good job, if you could not communicate and make sure they’re right? How can you update the freelancer or the employer, or simply ask a question, if you can not achieve consensus with all parties involved?

Why would anyone use a platform like HYVE, except for the usability and comfort it should provide. In practice, this means the user must do as little actions as possible.

How does our chat change?

• Chats between users will be treated per task/offer/listing. This is how they will show up in the messages list/section.
• The task will be the primary (main) entity in the chat architecture, not the participants.
• A new “group chat” is created for each task => task chat. The users in the chat are decoupled from the chat itself. This ensures that any of the involved parties can invite another participant in the chat (manager, designer, etc).
• If you want to send a message to a user without a theme (= gig/task), you can do that from their Profile page. Sending a message from any task/listing page results in a “task chat”.
• All chats are unified in the user’s inbox and look the same for both types. You could have 4 different chats with the same person, but for different listings. These chats do not mix together and have no relation whatsoever.

User Interface Changes

Below I will outline some of the changes we will be doing to the platform in terms of UI. This is a non-exhaustive list and I don’t go into every little detail but it should give a general idea.

General

1. Hide Intercom on mobile
2. Make Login / Sign-up easier
3. Switch URLs to slugs instead of UUIDs
4. Add Notifications section
5. Fix broken navigation
6. Add validation checks when posting Offers, Tasks
7. Fix critical UI bugs
8. Remove the concept of chains

Job/Offer

1. Hide Uncompleted Profile Data
2. Add Footer
3. Add Info in Job Page
4. Add Info in Offer Page
5. Format Description

Index

1. Remove some deprecated Filters
2. Combine “Remote” with “Locations”
3. Remove Infinite Scroll
4. Remove some Card Fields
5. Show “Featured” Listings by Default (split website into Featured/All)
6. Open Listing in Current Tab
7. Enable right click -> open in new tab for listings
8. Header + Page Structure Changes

Why all these changes?

If done correctly, this modularizes the application and lets us implement potentially hundreds of task “directories” that each function differently and have increased separation.

Examples: Tasks, Jobs, Offers, Bounties, Contests, and more.

Each type builds on the same baseline visual aspect as the rest of the app and types, but further customizes the experience to fulfill the usecase better (different card dimension, different data inside the cards etc).

In short, it helps us thoughtfully build HYVE into a protocol rather than a hardcoded product, one step at a time.

Q3 & Q4: Getting to 100,000 active users

I’ve already set an unrealistic goal once before, on camera actually, and I like to learn from mistakes; so let’s try this one more time.

For the entire year of 2023 we only have 2 goals:

1. Building a product that doesn’t suck.

2. Getting 100,000 people to use that product regularly.

That’s it. That’s the tweet.

The first we’ve covered above, while for the 2nd we’re already preparing a comprehensive battle-plan that will be ready and will start being put into motion by early Q2, just in time for V2.5. In addition to that, it’s also a bit unwise of us to just share the exact marketing battle-plan we have on our blog, since it is both boring as well as a bad business practice.

What’s Next?

For a couple days, a lot of people are on holidays, but next year is just around the corner and we’re ready to get down to work as soon as the year starts so that we can build HYVE into what it was always supposed to be: light-years away from competition.

This is Part 1 of a 2-part series of articles. Part 2 will outline the 10-year outlook for HYVE and will be published next year.