# Portaldot Hacker House 2026 | Judges & Voting Demo Post (Portion: Share what an asset earns, with a record everyone can check on Portaldot) **URL:** \ **Category:** Hackathon\ **Created:** [2026 年11 月 7 日 12:25 UTC](https://portaldot.discourse.group/t/topic/139 "2026-11-07T12:25:35Z")\ **Posts on this page:** 1\ **Page:** 1
作者： ![Sukuna](https://sea1.discourse-cdn.com/flex015/user_avatar/portaldot.discourse.group/sukuna/32/75_2.png) [@Sukuna](https://portaldot.discourse.group/u/Sukuna)\ 发布日期： [2026 年11 月 7 日 12:25 UTC](https://portaldot.discourse.group/t/topic/139/1 "2026-11-07T12:25:35Z")
### Demo video (2:56): [https://youtu.be/rPeJY-nuwrI](https://youtu.be/rPeJY-nuwrI) · What Portion does 1. An operator publishes hashed terms, a share count, a deposit schedule and a bond. 2. Backers read the terms and risks, buy shares and stake them. 3. The operator deposits revenue. After a 0.5% fee, it is split by staked shares. 4. Each holder claims their own part. 5. All are recorded on Portaldot blockchain - no longer just trusting number but verifiable ones. Portion doesn’t create revenue or guarantee returns. Holders receive only money the operator actually deposits.\*\* Links.\*\* App: [https://portion-one.vercel.app](https://portion-one.vercel.app) · Sandbox: [Portion — share what an asset earns](https://portion-one.vercel.app/sandbox) · Code: [GitHub - Nailer/portion: Funding and revenue-sharing workflows for productive assets on Portaldot V3. Interactive hackathon prototype. · GitHub](https://github.com/Nailer/portion) · Pitch deck: [docs/portion-pitch-deck.pdf](https://github.com/Nailer/portion/blob/main/docs/portion-pitch-deck.pdf) ### The problem People who run earning equipment, such as solar canopies, vehicles or machinery, often share income with the people who backed them. Whereby most of these transactions and earnings happen on spreadsheet, bank transfers and emailed statements, so the investors just take the numbers based on unverifiable trust. This is not just an assumption, that is how most companies under this category operate. This lack of verification has been commonly complained and we decided to fix that on Portaldot. ### ### Why Portaldot With one signature, a single all-or-nothing batch mints a native NFT deed, stores the terms hash on it, fractionalizes it into shares, sets approvals and calls the Solidity contract through Revive. Native assets reach Solidity as ERC-20 tokens through precompiles, so no separate token contracts are needed. TransactionStorage holds the documents. A plain database could run the admin; Portaldot matters when backers must check the record themselves. ### What you can check **Live on the Portaldot testnet (Core v1).** The contract is deployed, and a full create, buy, deposit, claim and unstake cycle has finalized. Open them in the public explorer: [deployment](https://scanner-testnet-v3.portaldot.dev/#/extrinsics/160455-1), [asset created](https://scanner-testnet-v3.portaldot.dev/#/extrinsics/165551-1), [buy, deposit, claim and unstake](https://scanner-testnet-v3.portaldot.dev/#/extrinsics/165573-1). The test asset, 585886, is listed and sold out at [Portion — share what an asset earns](https://portion-one.vercel.app/listing/585886) . One development account played both roles, signed by a script, so separate-user browser signing is not yet proven. **Browser sandbox (Core v2).** Listing 585886 is sold out, and Core v2 is not deployed. So [Portion — share what an asset earns](https://portion-one.vercel.app/sandbox) runs the compiled Core v2 bytecode in a browser EVM, with fictional roles and pretend money. Anyone can try it without a wallet: create an offer, fund it, see the contract refuse an unapproved release, approve, release, deposit, claim, default, slash, refund and pause. Nothing in the sandbox reaches Portaldot. **Check the chain yourself.** `npm run verify:chain` needs no wallet or keys. It compares the deployed contract with the compiled source byte for byte, then replays the contract’s events and checks that the recomputed accounting equals what the chain reports. **Engineering.** 356 automated tests pass in CI (149 contract, 56 SDK, 111 web, 40 server), with the full commit history public. Invariant tests run random call sequences against both contract versions; results, coverage and static analysis are in `docs/VERIFICATION-EVIDENCE.md`. These tests found a rounding issue, which is disclosed there. None of this is an audit. ### What changes in Core v2 Our own review found nine loopholes in the live contract. Core v2 closes or narrows them. Purchase money is held by the contract and released in tranches. A named reviewer must attest before a sale opens. Buyers are refunded if a raise misses its target, and unreleased money is refunded if the operator fails. A guardian can pause new money for at most seven days, and claims and refunds keep working. Core v2 is not deployed or audited; deploying it needs about 800–1,110 tPOT of storage deposit. ### What is not protected Nothing verifies that equipment exists or that all income was reported. On the live contract, purchase money goes straight to the operator, and the bond is limited recovery, not insurance. This is unaudited testnet software, and test tokens have no value. ### Business and next steps The proposed customer is the operator, paying a subscription for less allocation admin and clearer records. Our cost model shows contract fees alone would not pay for the service, and no customer, pilot or price has been agreed. Next, in order: discovery with a real operator, a pilot scope with a stated price, a separate-user browser test, Core v2 on testnet with an external review, then named reviewers and a legal view before any real money. ### Credits Built during the Hacker House window. Third-party dependencies are listed in the README. AI coding tools, including Claude Code, were used throughout. Demo video narration generated with Kokoro-82M (Apache-2.0). Telegram: @emmaaje