CollegenZ Rails

Credential Record Structure

Event Record Structure

Events are written to the chain by the application or institution that observed them. An attendance system calls the engagement contract when a student checks in. A quest platform calls it when a milestone is completed. A mentoring app calls it when a session is logged. For events that involve two parties, such as mentoring sessions, the contract supports a confirmation step where the subject confirms the event after the source logs it, and the confirmed flag is set to true only when both parties have signed.

Any engagement event can be connected to an automatic incentive payout through a trigger contract. The trigger watches for events of a specified type, evaluates whether the event meets a defined threshold, and when it does it executes a payout in TUIT or campus tokens. Triggers can be simple like paying a fixed amount for each check-in or cumulative, paying a bonus when a student reaches a streak of 10 consecutive attendances.

The trigger is a separate contract from the event logger, which means the same events can have multiple triggers from different applications watching the same data.

This is the property of the Engagement rail that matters most to builders working across multiple applications. Because engagement events are written to a shared chain rather than stored in a single application's database, any application on CollegenZ can query another application's engagement data and use it in its own logic.

A grant pool on the Money rail can check a student's attendance history from a completely separate campus application before releasing funds. A credential issuance on the Proof rail can reference quest completion data from QuestBoard. A new application that does not yet exist can read the entire engagement history of a student who has been active on the chain for two years.

Example: querying a student's attendance history from a different application

// Any contract on CollegenZ can read engagement data
// from any other application on the chain

EngagementRail rail = EngagementRail(ENGAGEMENT_CONTRACT_ADDRESS);

// Get all attendance events for a student from a specific campus app
Event[] events = rail.getEvents(
    subject:       studentWalletAddress,
    eventType:     EventType.ATTENDANCE,
    source:        campusAppContractAddress,
    fromTimestamp: semesterStartTimestamp
);

// Use the count in a condition check
uint256 attendanceCount = events.length;
bool meetsThreshold = attendanceCount >= requiredAttendance;

All engagement events on CollegenZ are publicly readable with no permissioning layer between applications for read access. This is what makes engagement data function as portable reputation.

Streak tracking is handled at the contract level through dedicated streak contracts that monitor a sequence of engagement events and determine whether they form a consecutive pattern. A streak contract defines what counts as a valid sequence entry, what the required interval is between entries for the streak to remain active, and what rewards or state changes are triggered when a streak reaches a defined length. This is a contract-level mechanism rather than an application-level one, which means that streak logic is verifiable on-chain and consistent across any application that references it.