All posts by HAN - HR

000BCH, 09 - Agentic AI & DeFi

Dao Governance

Welcome to the NZRT Wiki Podcast. Today we’re looking at DAO Governance.

So, what is a DAO? The acronym stands for Decentralised Autonomous Organisation. At its core, a DAO is an organisation where the rules are encoded in smart contracts on a blockchain, and decisions are made by token holders through proposals and votes rather than by a traditional board of directors or management team. Your membership and voting power are represented by governance tokens held in your wallet.

To understand how different that is from a traditional company, think about five key properties. Governance in a company sits with a board and shareholders. In a DAO, it sits with token holders through on-chain voting. Execution in a company means a management team carrying out decisions. In a DAO, smart contracts handle that automatically, or a multisig wallet does. Transparency is selective in a company, but in a DAO every proposal and every vote is public on-chain. Membership in a company means appearing in a share registry. In a DAO, it means holding a governance token in your wallet. And finally, jurisdiction. A company operates under registered company law, while a DAO exists in a much more variable legal space, sometimes unregistered, sometimes structured as a Wyoming DAO LLC.

Now, DAOs come in several types. Protocol DAOs govern a DeFi protocol, where token holders vote on things like interest rates, collateral ratios, and fee distribution. Well-known examples include Uniswap, Aave, and Compound. For NZRT, this is relevant because ITSL, the Iteasel token, could potentially adopt protocol DAO governance after mainnet launch. Investment DAOs pool capital from members and collectively vote on where to invest it. For ITSL, investment DAO patterns could apply to collective governance of revenue distribution. Social and membership DAOs gate access by token or NFT holding and govern treasury spending or community direction. Service DAOs are freelancer collectives that pool reputation and distribute income. And then there are AI DAOs, an emerging category where token holders govern which AI models are used, what system prompts are applied, and how outputs are validated.

Moving on to tooling. For proposals and voting, there are four main tools you should know about. Snapshot uses off-chain, gasless voting. It is the most widely used, but votes do not execute automatically. A multisig wallet has to implement the result, which adds a trust layer. Tally uses on-chain voting through Governor contracts, so votes execute automatically, but voters need to pay gas fees. Aragon is a full DAO framework covering voting, treasury, and membership in one platform. And OpenZeppelin Governor, also called Governor Bravo, is the industry-standard on-chain governance contract used by Compound and Uniswap.

The key tradeoff between Snapshot and on-chain voting is cost versus trust. Snapshot is cheaper and more accessible but advisory only. On-chain Governor executes automatically but can reduce participation because of gas costs. For ITSL governance, the NZRT recommendation is to start with Snapshot combined with Gnosis Safe, where the multisig implements approved proposals, then migrate to on-chain Governor when participation and treasury size justify the overhead.

For treasury management, Gnosis Safe is the most common DAO treasury tool, a multisig where appointed signers implement DAO decisions. Llama handles analytics and spending authorisation. Hedgey manages token vesting and distribution for contributors.

On token distribution, there are four common patterns. A fair launch means no pre-mine, tokens distributed via liquidity mining or airdrop from day one. A retroactive airdrop distributes tokens to past users based on a snapshot of on-chain activity. A vesting schedule locks team and investor tokens over two to four years to prevent immediate selling. And contributor grants allocate tokens from the DAO treasury for completed work.

On the legal side, DAOs exist in a grey zone in most jurisdictions. Wyoming was the first US state to legally recognise DAOs, providing members limited liability through a Wyoming DAO LLC. The Marshall Islands DAO LLC is a low-cost offshore option used by many DeFi projects. A foundation plus DAO structure, common in the Cayman Islands or Switzerland, has a foundation holding the IP and contracts while the DAO governs protocol parameters. An unregistered association carries the highest legal risk since members may have unlimited personal liability. And a New Zealand company with a DAO governance layer on top lets the company retain legal personhood while the DAO handles governance.

Now, the most critical NZRT-specific point. ITSL tokens are currently structured as revenue-sharing interests under the New Zealand Financial Markets Conduct Act 2013, using the wholesale investor exemption. If you add on-chain governance voting rights to ITSL, the token could be reclassified as an interest in a managed investment scheme, which requires full registration, a licensed manager, and a supervisor. That is a significantly higher compliance burden. The clear rule here is do not add governance functionality to the ITSL contract without a New Zealand securities lawyer confirming the exemption still applies.

If legal advice does confirm a DAO layer is permissible, the most conservative structure would work like this. At the top, NZRT Network Ltd remains the legal entity holding contracts and intellectual property. Underneath that sits a DAO governance layer built on Snapshot and Gnosis Safe. That layer uses a separate governance token, not ITSL, and its scope is limited to advisory votes on product direction only. Execution flows through Gnosis Safe with existing leadership retained as a required signer, meaning the DAO cannot override the company’s obligations under the Companies Act 1993.

The immediate next step for NZRT is obtaining a New Zealand securities lawyer opinion on whether adding governance rights to ITSL would trigger managed investment scheme requirements under the FMCA. That legal opinion is the prerequisite before any DAO planning moves forward.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000DOL

Dolibarr Beneficiary Records Ncs Charitable Services

Welcome to the NZRT Wiki Podcast. Today we’re looking at Dolibarr Beneficiary Records — NCS Charitable Services.

If you work with the NCS charitable services side of NZRT, you’ll want to understand how beneficiary organisations are tracked inside Dolibarr. This episode walks you through the record schema, how records get created, what delivery notes look like, and how to query those records via the API.

Let’s start with the basics. In Dolibarr, beneficiary organisations are stored as Third Parties — the same entity type used for commercial customers. The key difference is that these records are flagged as customer type, not supplier, and importantly, no invoicing ever happens against them.

Here’s how the record fields break down. There are seven main fields to know about. The name field holds the organisation’s name, taken directly from their application email. The client field is set to one, which marks this as a customer or beneficiary type. The supplier field is set to zero, because these organisations are not suppliers. The email field holds the applicant’s email address as the primary contact. The status field is set to one, meaning active, and that’s applied at the time of creation. The organisation type field is left as the Dolibarr default, depending on whether New Zealand organisation types are configured in your instance. And finally, there’s a private note field — this is where you record what services were delivered and when, either manually or via an agent note.

Now, how do these records actually get created? For most NCS workflows, you don’t have to do this by hand. Records are created automatically by the CAS agent when it processes an approved application through the charitable delivery workflow. But if you ever need to create one manually through the Dolibarr user interface, here’s the process. You navigate to Third Parties, then New Third Party. You set the name, the email, and make sure the client flag is set to one. You save the record and note the ID Dolibarr assigns. Then you add a private note documenting the delivery.

Speaking of delivery records — this is an important one. Because NCS charitable delivery is at no cost, you never raise an invoice for these. Instead, the delivery is documented in that private note field. A typical note would say something like: NCS delivery on the 27th of April 2026, listing the services delivered — for example Knowledge Systems and Claude Code AI Agent Setup — noting that delivery was made via automated email from the NZRT sales address, and recording which email address the GitHub zip files were sent to. That’s essentially a plain-language delivery receipt sitting right inside the record.

Now, if you ever need a more formal paper trail — say for charitable registration evidence or reporting purposes — there is an option to create a zero-dollar commercial proposal. You’d set the beneficiary organisation as the third party, add one line per service delivered with a unit price of zero, then validate and close it. This gives you a proper document record without creating any payment obligation. It’s purely for audit and reporting.

Finally, let’s talk about querying beneficiary records. If you’re pulling data via the Dolibarr REST API using the CAS API key, you send a request to the thirdparties endpoint asking for up to one hundred results and filtering by client type one. In plain terms, that means you’re asking Dolibarr to return all third parties that are flagged as customer or beneficiary type. From there you can filter further by organisation name or by keywords in the private note to zero in on NCS-specific records.

So to recap: beneficiaries live in Dolibarr as Third Parties, flagged as client type with no invoicing, delivery is documented in the private note, and the CAS agent handles creation automatically in most cases. When formal records are needed, a zero-dollar proposal is your tool of choice.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000DOL, 06 - Human Resources

Human Resources Management

Script below. ~620 words, fits 3-6 min.

—

Welcome to the NZRT Wiki Podcast. Today we’re looking at Human Resources Management.

If you work with the NZRT systems, Human Resources Management is the part of the platform that covers the full employee lifecycle. That means everything from bringing someone on board right through to tracking their time, managing their leave, and handling their expenses. Think of it as your central hub for everything people-related.

Let’s walk through what’s actually inside this module, because there are five distinct sub-modules that each handle a different part of the HR picture.

The first is Employee and Staff Management. This is your foundation. It’s where you keep records on each person in the organisation — their details, their role, their employment information. Before anything else in HR can work properly, you need your employee records set up here. If you’re onboarding someone new, this is where you start.

Next up is Employee Leave Management. This is exactly what it sounds like — it’s the module that handles requests for time off, whether that’s annual leave, sick leave, or any other type your organisation recognises. You can track who has requested leave, what’s been approved, and how much entitlement each employee has available. If you’re a manager reviewing leave requests, this is your go-to area. And if you’re an employee wanting to check your remaining leave balance, this is where you’d look too.

The third sub-module is Expense Reports. This one is particularly useful for anyone in the team who spends money on behalf of the company — whether that’s travel, supplies, client entertainment, or anything else that needs to be reimbursed. You submit your expenses here, attach your receipts, and the report flows through for approval. It connects directly with the Finance side of the platform, so once an expense report is approved, the reimbursement process can move forward without you having to chase anyone down separately.

Fourth is Recruitment Management. If you’re hiring, this module gives you a place to manage that process from within the same system you use for everything else. You can track candidates, manage job openings, and move applicants through the stages of your recruitment pipeline. It keeps everything in one place so that when someone is hired, transitioning them into the Employee and Staff Management module is a natural next step.

And the fifth sub-module is Timesheets. This one is about tracking time — specifically, who worked on what and for how long. What makes this particularly powerful in the NZRT setup is that timesheets connect directly to the Projects module. So if your team is logging hours against specific tasks in a project, that time data flows through from timesheets into the project records. It means your project reporting stays accurate, and you have a clear picture of where time is actually being spent across the organisation.

Now, a quick note on how HR connects to the rest of the platform. You’ve already heard that timesheets link to Projects — that’s a key one, especially if your organisation bills clients by time or tracks project budgets carefully. The other major connection is between Expense Reports and Finance. When someone submits an expense report and it gets approved, that feeds into the Finance module so that reimbursements can be processed through the normal financial workflow. You don’t need to duplicate the information anywhere — the two modules talk to each other.

So to pull it all together: Human Resources Management covers five areas. You have Employee and Staff Management for your core people records. Employee Leave Management for tracking time off. Expense Reports for reimbursements. Recruitment Management for your hiring process. And Timesheets for logging time, which ties back into your project tracking. The whole module sits at the intersection of your people processes and your financial and project workflows, which is what makes it worth understanding even if you only actively use one or two of those sub-modules day to day.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.