01THE AMOUNT
Give access.
Keep a limit.
A connection should never mean an open budget. Define the most an application is allowed to spend across a permission.
One permission. One cumulative ceiling.
Loading the scene…
KORDKORD. Your wallet. Your rules.
PERMISSION, WITH BOUNDARIES.A closer look
A CLEARER KIND OF ACCESS
A connection.
Not a blank check.
Your wallet holds value.
Every application should have a boundary.
AMOUNTACTIONDURATION
THE SHAPE OF A PERMISSIONTHREE RULES. ONE POLICY.
Give access.
02THE ACTION
One app.
A specific job.
An application built to swap does not need an invitation to do everything else. Name the operations that belong inside its permission.
Only the operations included in the policy.
03THE DURATION
Access ends.
On your terms.
A task has an end. Its access should have one, too. Choose a window for a permission to stay valid, instead of leaving it open indefinitely.
A defined duration, starting at activation.
DESIGNED TO WORK TOGETHER
Boundaries are stronger
when they agree.
01AmountWithin your budget
+02ActionInside the scope
+03TimeBefore access ends
=One policyEvery boundary defined
KORD brings these constraints into one permission plan.
A working integration must enforce each one together.
04 / PUT IT INTO WORDSMAKE THE BOUNDARY EXPLICIT.
YOUR CONTROL SURFACE
Less open-ended.
More intentional.
Start with an application.
Give it a budget, a task and a time limit.
- Spending ceiling
- 250 USDC
- Operations selected
- 01 / 03
- Permission duration
- 24 hours
This workspace creates an unsigned plan. It does not change wallet approvals.
05 / A CLOSER LOOK
Know what
you allow.
A permission should be understandable
before it becomes a commitment.
KORD is a protocol concept for permissions with explicit boundaries: an application, a spending cap, allowed operations and an expiry. The aim is to let compatible programmable accounts enforce those boundaries.
PERMISSION, WITH INTENTION.