Address Linking System

​

System Architecture

​

The Challenge

• Ethereum: Via automated campaign vaults
• Neutron: Direct deposits to Supervaults or Amber Protocol

• NTRN Locking: Only available on Neutron
• NFT Collections: Only Superbolt collections on Neutron count

​

Technical Solution

• Deposits: Can occur on Ethereum (vaults) or Neutron (direct protocols)
• Boosts: Only generated on Neutron via NTRN locking or NFT collections
• Boost Pointer Contract: Links Neutron-based boosts to any deposit address
• Pointing Operation: User explicitly connects their boost to their deposit address

​

Core Components

​

Boost Pointer Contract

• Simple staking contract accepting NFT deposits
• Accepts both Ethereum and Neutron address formats
• No unbonding periods - purely accounting mechanism
• Maps boost sources to target deposit addresses

interface IBoostPointer {
    function pointBoost(address target) external;
    function getBoostTarget(address user) external view returns (address);
    function getBoostMultiplier(address user) external view returns (uint256);
    function updateBoostTarget(address newTarget) external;
}

​

Lock Receipt NFTs

• Functional NFTs representing locked NTRN positions
• Store lock duration and amount information
• Transferable on secondary markets (Superbolt)
• Must be staked to Pointer Contract to activate boost

{
  "lock_amount": "1000000000",
  "lock_duration": "126144000",
  "creation_block": "12345678",
  "boost_multiplier": "1.5"
}

​

Address Resolution Logic

​

Single Wallet Connection Scenarios

• Shows Ethereum deposits + any boosts pointed to Ethereum address
• Clean interface, no conflicts

• Shows Neutron deposits + any boosts pointed to Neutron address
• Direct access to boost mechanisms

​

Dual Wallet Connection Scenarios

1. Deposit + Boost info > Deposit or Boost only > No info
2. Displays data from the “dominant network”
3. Shows warnings for conflicting configurations

​

Scenario Matrix for Integrators

​

Error Handling & Resolution

​

Conflict Types

​

1. Conflicting Networks

​

2. Conflicting Balances

​

3. Dominant Network Conflict

​

4. Total Conflict

​

Implementation Examples

// Conflict detection
const detectConflicts = (ethData, neutronData) => {
  const conflicts = [];
  
  if (ethData.deposits && neutronData.deposits) {
    conflicts.push('MULTIPLE_DEPOSITS');
  }
  
  if (ethData.deposits && neutronData.boosts && !ethData.boosts) {
    conflicts.push('CROSS_NETWORK_BOOST');
  }
  
  return conflicts;
};

// Conflict resolution UI
const ConflictResolution = ({ conflicts, onResolve }) => {
  return (
    <div className="conflict-modal">
      <h3>Address Coordination Required</h3>
      <p>Multiple wallets detected with conflicting configurations.</p>
      <button onClick={() => onResolve('disconnect_secondary')}>
        Use Primary Wallet Only
      </button>
      <button onClick={() => onResolve('link_addresses')}>
        Link Addresses
      </button>
    </div>
  );
};

​

Integration Best Practices

​

UI/UX Recommendations

• Clear indication of which address will receive boosts
• Visual confirmation of boost pointing
• Warning for cross-network configurations

• Progressive disclosure of complexity
• Clear action items for resolution
• Fallback to single-wallet mode

• Real-time boost status display
• Clear indication of active/inactive boosts
• Visual confirmation of successful pointing

​

Development Guidelines

• Handle asynchronous wallet connections
• Maintain consistent address state across components
• Implement proper error boundaries

• Cache address resolution results
• Batch API calls for efficiency
• Implement proper loading states

• Validate address formats before API calls
• Implement proper signature verification
• Handle wallet disconnection gracefully

​

Testing Scenarios

​

Comprehensive Test Cases

1. Single Wallet Scenarios:
   • Ethereum only with deposits
   • Neutron only with deposits
   • Each with and without boosts
2. Multi-Wallet Scenarios:
   • Both wallets with deposits (conflict)
   • Cross-network boost pointing (conflict)
   • Proper address linking (success)
3. Edge Cases:
   • Wallet disconnection during boost pointing
   • Address format validation failures
   • Network switching scenarios

​

Test Implementation

// Example test structure for address linking integration
describe('Address Linking Integration', () => {
  test('handles single wallet connection', async () => {
    // Test single wallet scenarios
    // Implementation details will be provided with SDK
  });
  
  test('detects cross-network conflicts', async () => {
    // Test multi-wallet conflict detection  
    // Implementation details will be provided with SDK
  });
});

​

Technical Specifications

​

Boost Pointer Contract Interface

contract BoostPointer {
    mapping(address => address) public boostTargets;
    mapping(address => uint256) public boostMultipliers;
    
    event BoostPointed(address indexed user, address indexed target, uint256 multiplier);
    
    function pointBoost(address target) external {
        require(target != address(0), "Invalid target address");
        boostTargets[msg.sender] = target;
        emit BoostPointed(msg.sender, target, getBoostMultiplier(msg.sender));
    }
    
    function getBoostTarget(address user) external view returns (address) {
        return boostTargets[user];
    }
}

​

Address Format Support

0x742d35Cc6634C0532925a3b8D4e8F0532E7C45 (example format)

neutron1w29vh2hjnjef9e2dujc5j4ear4g5th955vetjrx42m7eedeg8ydq3v9zee (example format)

​

Integration Requirements

​

Minimum Implementation

1. Address detection: Support both Ethereum and Neutron wallets
2. Conflict handling: Basic conflict detection and resolution
3. Boost pointing: Interface for users to point boosts to deposit addresses
4. Status display: Show current boost configuration and conflicts

​

Recommended Implementation

1. Advanced conflict resolution: Sophisticated UI for complex scenarios
2. Real-time validation: Live checking of boost/deposit alignment
3. Multi-network support: Seamless switching between networks
4. Performance optimization: Efficient state management and API usage

​

Full Integration

1. Custom UI components: Branded interface matching partner design
2. Advanced analytics: Detailed reward projections and optimization
3. White-label solutions: Complete campaign interface customization
4. Priority support: Dedicated technical support and consultation

​

Technical Glossary