Technical Documentation
Comprehensive technical specifications for the Kolam Prosper tokenized real estate platform
1.1. The Kolam Prosper Vision
Kolam Prosper is a positive-sum property investment protocol designed to align incentives for all participants—investors, developers, and tenants. The end goal is to acquire apartment buildings for rent-to-own, funded through compliant tokenized construction investment bonds. This model creates a sustainable ecosystem where capital formation and housing accessibility reinforce each other.
1.2. The RAK ONE Project (Example Project)
RAK ONE is the inaugural project, consisting of 10 G+12 residential towers with 120 apartments. Each apartment represents a discrete investment unit valued at $125,000, covering construction costs and development margin. The project is pre-land acquisition, with zero construction completion, making it an early-stage, high-potential investment opportunity.
1.3. Core Principles
- Compliance: Regulatory adherence via ERC-3643 and Haven1's identity primitives.
- Privacy: Opaque identifiers hide property details until post-construction reveal.
- Accessibility: Unified entry for institutional and DeFi investors via fractionalized FNFTs.
- Gamification: Property Ladder raffles to enhance engagement and capital efficiency.
2.1. Two-Phase Tokenization Model
Phase 1 - The Construction Bond
Compliant financial instrument representing a claim on a future property deed. Fully subject to KYC/AML via ERC-3643's Identity Registry.
Oracle Milestone
Chainlink oracle provides a cryptographically signed message upon verification of:
- 32% construction completion
- Legal deed issuance by relevant authorities
Phase 2 - The Property Deed
Transforms the bond into a functional asset with utility for staking, borrowing, and governance.
2.5. Key Contracts
- BondFactory: Deploys ERC-3643 bond tokens per project
- BondContract (ERC-3643): Compliant bond token with enforced transfer restrictions
- FNFTWrapper (ERC-1155): 1:1 wrapper for bonds to enable efficient trading
- DeedFactory: Mints ERC-3525 deed tokens upon bond burning
- DeedContract (ERC-3525): Post-reveal property deed with embedded utility
- OracleVerifier: Validates Chainlink signatures and triggers claimability
3.1. The ERC-3643 Bond Token (kPROP-BOND)
Purpose: Compliant representation of investment in a specific property unit.
- Symbol: kPROP-BOND (project-specific IDs in metadata)
- Decimals: 0 (whole units only)
- Opaque Identifier: kKOL-9A8B7C (offsets property details to secure off-chain DB)
// Key Functions:
batchTransfer([address], [tokenIds]) // For OTC institutional sales
forcedTransfer(from, to, tokenId) // For legal/regulatory recovery
pause() // Emergency stop by multi-sig3.2. The FNFT Wrapper (ERC-1155)
Purpose: 1:1 wrapper for efficient trading of bonds.
Symbol: F-PROP
Mechanism:
- Treasury deposits kPROP-BOND token
- Mints corresponding F-PROP FNFT
- FNFTs traded on OpenSea/etc. with compliance checks enforced by wrapper
- Upon claim, FNFT and underlying bond are burned
3.3. The ERC-3525 Deed Token (kAPT)
The ERC-3525 standard is chosen for its semi-fungible nature, which is perfect for representing property deeds that may later be fractionalized including post-reveal data with functionality.
Key Properties:
- slot (The Property Identifier): A uint256 value that groups tokens representing shares of the same underlying asset. Example: Every token representing a fraction of RAK1, Apartment 501 will have the same slot value (e.g., 5001).
- value (The Ownership Share): A uint256 that represents the quantity of shares the token holds. A full deed has a value of 10^18 (1e18). This high precision allows for extremely granular fractionalization later.
3.4. Oracle & Claim Mechanism
function verifyAndUpdate(
string calldata projectId,
bytes calldata signature
) external onlyAdmin {
require(!isVerified[projectId], "Already verified");
bytes32 hash = keccak256(abi.encodePacked(projectId, STATUS_COMPLETE));
address signer = ECDSA.recover(ECDSA.toEthSignedMessageHash(hash), signature);
require(signer == CHAINLINK_ORACLE, "Invalid signature");
isVerified[projectId] = true;
}Claim Flow:
- User calls claimDeed(fnftId) on wrapper
- Wrapper checks OracleVerifier.isVerified["RAK1"] == true
- Burns F-PROP #fnftId and underlying kPROP-BOND
- DeedFactory.mint(to, bondId) mints ERC-3525 deed with revealed metadata
4.1. For All Investors
Purchase whole F-PROP FNFT representing one $125k unit.
4.2. Institutional OTC
- Treasury uses batchTransfer to send specific kPROP-BOND tokens to whitelisted wallet
- Investor receives tokens directly, can hold or wrap into F-PROP manually
4.3. DeFi/Retail
- Purchase F-PROP FNFTs on secondary markets (e.g., OpenSea)
- No KYC required for purchase, but mandatory for final deed claim
4.4. Claim Process
Unified path:
- Holder must pass KYC check via Haven1's ProofOfIdentityV2
- Initiate claim to burn FNFT and receive ERC-3525 deed
5.1. Non-Liquidating Loans
- LendingContract: Allows deed holders to borrow up to 70% LTV ($87.5k per deed)
- Terms: 1% monthly service fee, no liquidation. Unpaid loans result in deed forfeiture to treasury
- Funds Source: Protocol-owned liquidity pool funded from construction capital
5.2. Fee Sharing & Staking
- StakingContract: Deed holders stake kAPT tokens
- Rewards: 50% of loan service fees distributed pro-rata to stakers
- Treasury: Receives remaining 50% of fees
5.3. Property Ladder Game
- RaffleContract: Users purchase tickets with F-PROP or kAPT
- Mechanics:
- Pool 1: 100 tickets for fractional deed
- Pool 2: 10 tickets for higher-value deed
- VRF-powered random drawing for upgrades
5.4. Rent-to-Own
The end goal is to have a large portfolio of properties under our guardianship to offer a new way for renters to become homeowners.
6.1. Network Details
- Testnet RPC: https://testnet.haven1.org (Chain ID: 112233)
- Mainnet RPC: https://mainnet.haven1.org (Chain ID: 111222)
6.2. Native Identity
- ProofOfIdentityV2: 0x1234...abcd (Testnet)
- ABI: Available in Haven1's dev kit
6.3. Gas Considerations
| Operation | Gas Cost |
|---|---|
| Mint Bond | 150k gas |
| Transfer FNFT | 80k gas |
| Claim Deed | 220k gas |
7.1. Access Control
- Admin Multi-sig: 3-of-5 for treasury and critical operations
- Agent Role: Assigned to legal authority for forcedTransfer
- Oracle Manager: Single secure address for oracle updates
7.2. Audit Considerations
- Critical Functions: claimDeed, forceTransfer, pause
- Potential Risks: Reentrancy in wrapper, oracle signature spoofing
- Recommended: Formal verification for compliance rules
7.3. Legal
- Agreement Storage: Legal PDF stored off-chain (encrypted IPFS)
- Proof of Agreement: SHA-256 hash stored on-chain in DeedFactory
- Jurisdiction: UAE law for RAK ONE, with enforceable forcedTransfer clauses
Proof of Agreement Mechanism
Storing entire legal documents on-chain is prohibitively expensive and exposes sensitive data. The "Proof of Agreement" mechanism provides a cryptographically secure alternative.
- Document Finalization: The legal agreement for a bond offering (PDF) is finalized
- Hash Generation: The protocol calculates a cryptographic hash (keccak256 or SHA-256) of the document's binary content
- Immutable Storage: This hash is stored within the smart contract's state upon deployment
- Secure Distribution: The original PDF document is distributed to investors via a secure, private portal
9.1. Valuation Methodology
The valuation is not arbitrary; it is a bottom-up calculation derived from real-world development costs, ensuring transparency and justifying the investor's return.
| Component | Estimated Cost | Description |
|---|---|---|
| Land Acquisition | Our cost | Cost of the plot is already bought by the protocol |
| Construction | 30% of total | Materials, labour, and direct building expenses per unit |
| Developer Margin | % of apartments | Held for RTO OR equity as required |
9.2. Fee Structures
| Fee Type | Rate | Trigger Event | Destination |
|---|---|---|---|
| Finder's Fee | 0.25% | Initial bond sale | Marketing, sales, legal setup |
| Loan Service Fee | 1% monthly | Outstanding loan balance | 50% to Stakers, 50% to Treasury |
| RTO Management Fee | Variable% | RTO agreement value | Treasury (for managing RTO) |
| Property Ladder Fee | 1% | Prize pool entry | Treasury (for game mechanics) |
9.3. Treasury Management
The Treasury is the custodian of all raised capital, operating under strict, transparent rules to ensure investor security.
- Multi-Sig Governance: All transfers require multiple signatures (3-of-5) from designated executives and advisors
- Milestone-Based Releases: Funds are escrowed with relevant land department and released in tranches upon independent verification
- Initial Capital Allocation: ~30% to development costs, ~70% flows into protocol treasury to fund loan liquidity
9.4. Incentive Analysis
- Why Stake? To earn a share of the protocol's revenue (loan fees) with a predictable, real-yield APY
- Why Take a Loan? To access liquidity without selling your underlying asset. 70% LTV with no liquidation risk
- Why Play the Property Ladder? For a chance to significantly amplify one's investment through a gamified experience
11.1. Jurisdictional Analysis
The primary jurisdiction for the issuance of the kPROP-BOND token is the United Arab Emirates, specifically the Emirate where the property is located (e.g., Ras Al Khaimah). Kolam Prosper will adhere to the securities regulations administered by the Securities and Commodities Authority (SCA) of the UAE.
We do not offer tokens or development within Dubai.
11.2. Security Token Classification
The kPROP-BOND is unequivocally a security token because it:
- Represents an Investment of Money: Investors provide capital
- In a Common Enterprise: Capital is pooled to fund a real estate development project
- With an Expectation of Profit: Profit is derived primarily from the efforts of others (Kolam Prosper's development team)
Steps for Compliance:
- KYC/AML Integration: Mandatory identity verification via Haven1's ProofOfIdentityV2 and our ERC-3643 IdentityRegistry
- Transfer Restrictions: Enforcement of rules that prevent transfers to non-verified wallets
- Transparent Reporting: Regular reporting to investors on construction progress and financials
11.3. Role of the Oracle in Compliance
The oracle is a critical compliance gate. Until the 32% construction milestone and legal deed issuance is verified, the token represents a security (a financial instrument in a development project). After the oracle's verification, the token can legally transform into a digital deed, representing direct ownership of a real-world asset.
11.4. Data Privacy (GDPR & Others)
The protocol is designed for privacy by default:
- Minimal On-Chain Data: Only the hash of the legal agreement and an opaque token ID are stored on-chain
- Zero-Knowledge Proofs (Future): The protocol can integrate zk-proofs to allow users to prove their accredited investor status without revealing identity documents
- Data Custody: Personal data collected during KYC is stored off-chain in secure, compliant custodial systems
Complete Technical Specification
Download the full technical documentation including implementation guides, smart contract specifications, and deployment sequences.