# Modification: Notary random assignment ## Issue Description The current issue is that many notaries are hesitant to perform due diligence or sign on LDN allocation applications from clients they are not acquainted with. This poses a challenge for new clients who are not associated with an existing notary, as they are less likely to have their applications reviewed. At the same time, many notaries are inactive and do not engage with clients. Notaries have reported feeling overwhelmed by the number of client applications they are expected to review and sign. ## Impact - Increase the number of times notaries sign unfamiliar applications - Increase notary engagement (signing/due-dilligence), in turn increasing the overall throughput of datacap - Identify which notaries are: - engaging on all applications - engaging on only familiar applications - inactive - Notaries will not be overwhelmed by the number of applications they see on the registry. - Lower load time for Fil+ registry - Notaries will still be able to sign applications they want to sign ## Proposed Solution(s) - Every x days, notaries will be assigned a set of y random LDN applications. - Instead of a full table of all the applications, this set of random LDN applications will appear on the front page of the Fil plus registry ordered by how long the client has been waiting for DC. The full table of applications will be still available for the notary to navigate to. - Notaries can notify the system when they have done due-dilligence on an assigned application. Possible ways to do this: - A tick box on the the registry - The registry can check if notaries have opened the github link - the notary commented on the application on why they don't want to sign - the notary signed the application - any subset of the above - If in x days, the notary still has not engaged with their assigned applications, then they will be marked down. - Currently, we don't have any way to penalize or reward notaries so initially behavior regarding the random assignments will just be tracked. Proposed values (subject to change if there is good reason): x = 7 days (1 week) y = 5 random client applications ### Timeline week 1-2: finalizing discussion week 3-4: finalizing design internally week 5-6: implementation week 6-7: testing and fixes ### Technical dependencies Tooling for registry and SSA bot will have to change and be redeployed ### End of POC checkpoint (if applicable) week 7 ## Risks and mitigations - Engineering cost ## Related Issues